Doing agile but not being agile
Stop if you’ve experienced this before. You read about Scrum. You decided to attend a workshop about it. You feel inspired. You promoted the idea to your higher ups. You got the buy in. You applied it to your team. 1 year in and you’re left with pile of untouched backlog, the end product doesn’t feel any much improved and worst, your team doesn’t feel inspired. What happened to the ever promised land of Agile?
And that was exactly the thing that Dave Thomas mentioned in his talk “The Dead of Agile”. But the thing that interests me is the fact that the talk was given back in 2015, 7 years ago. Yet here we are, 2022 and I can still find people talk about “agile” as noun, as opposed to an adjective.
That last sentence, is probably why we’re (still) here. The daily practice becomes a race to follow a prescriptive route of an agile framework, hence the statement “yes, I’m doing agile at work”. But if you’re in that state, do ask yourself and your team to check your collective pulses:
- Are you regularly produce working software?
- Can the team constantly evaluate the resulting software?
- How well does the team responds to uncertainties, both business and technical wise?
- Are the users and stakeholders able to continuously see and feel the software’s value?
In the end, the value of agile is acknowledging that producing software is full of uncertainties that stems from the malleable yet evolutionary behavior of the software itself. The best way to respond to that is to continuously build and evaluate a working software, so the team can collectively learn and direct the next best step of evolution. As a consequence, the practice of actually building the software will involve plenty of iteration over an agreed cadence, repeat as necessary (or allowed).
What’s harmful is you follow the prescribed process of an agile framework, aim to adhere to it 100%, but forgot the context of your organization. Software development is a team sport. It’s a collective effort. Thus the human and social factor needs to always be counted in order to reach that level of agility. An agile framework may take you to a step to understand what does being agile mean. But just like the software that it helps build, the process needs to be constantly evaluated as well. Because you know your environment way better than the framework author. And in this context, sticking to the aforementioned value of agile is better than trying to comply to a framework’s rule.
Ultimately, you want to continuously provide values through software, in a productive flow for the team that builds it. That’s the agile state that you’re looking for.
