Posts

I’m not particularly fond of the term “sprint”. The word “sprint” often gives the impression that the team needs to prioritize on working as fast as possible. And inadvertently creates pressure to complete every user story before the end of the sprint, sometimes at the expense of quality, or by allowing technical debt to build up. In reality, agile development is more like a marathon, where we maintain a healthy, steady, sustainable pace. It’s not a relay race where teams sprint as fast as they can, trying not to drop the baton at the end of each leg. ...

Agile works well for projects that have: A low cost of change Problems that are discovered along the way. Informally specified goals, that could alter. A more traditional approach might be a better option when: The cost of change is high. The complete set of problems are known up-front. The goals are very specific and fully understood from the start.

You may have heard of the “Iron Cross”. Have you heard of the “Iron Triangle”? Quality (Deliver what’s expected. And account for all of the exceptional scenarios flows) Scope (How much stuff is delivered) Resources (Time, brains, tools, dollars, etc.) Pick any two, and the third is a variable. Inevitably, we will want “Quality” to be maxed out. So, we can only focus on “Scope” or “Resources.” If we want a larger scope of work completed, we need to increase the resources. Alternatively, if resources are fixed, we must accept and define how much scope of work we can realistically complete. ...

You may have heard of the “Iron Cross”. Good (Quality) (Delivered) Fast Cheap (Under budget) (Everything) Done Focus on any three you like, but you can’t have the fourth. You can have a project that is good quality, delivered on time fast, and within budget and cheap. But! not everything will get done. Or, you can have a project that is all done, cheap, and fast, but it won’t be good quality. ...

It’s important to not assume that the software your team is working is compatible with an agile workflow. Agile is about embracing change. And for that to happen, the software itself needs to be intentionally designed with adaptability in mind. I’ve joined many teams where the management and scrum master were on-board with following an agile approach, but they were completely oblivious to the fact that the software being built wasn’t compatible with an agile workflow. ...