There is one majorly overlooked aspect to agile software: The software itself. We’re always worried about the speed of implementing, not the speed of maintenance. But it is actually the speed of future maintenance that is the essence of agile technology. We simply cannot be agile unless we focus on the technology.
Implementing agile frameworks like: Scrum or Kanban can help us deliver software. But agility is not about the process itself. Agility is a state of mind. The only metric for measuring agility is how fast we can change our software. Not how fast we deliver, on-board, story points etc. Only how fast we change our software. That is our competitive advantage.
Unfortunately though, most teams get caught up in optimising only on the surface. On the superficial parts like process and burn-downs. These feel easy to manage. So we keep an eye on those metrics. Not on the ones that actually count, like how fast can the software change in future.
Agility is not only the ability to deliver in small parts – it is the ability to change direction in future as well.
But most teams make the tragic mistake of valuing “How can we make this ship faster!” over “How easy will this be to change later?”. In fact, we only seem to ask the latter question after we’ve delivered. This is where our recency bias and innate lack of ability to see longer term lets us down.
The benchmark of agile is not how quick can we ship, but how quick can we change in future.
Question: What’s been the biggest obstacle for your teams to embrace and create agility? You can leave a comment by clicking here.