A recent conversation with a friend got me thinking of the reason why many organizations are choosing to adopt agile, and how they may be setting themselves up disappointment. When organizations approach me for help adopting agile software development, one of the first things I do is ask “Why?” The usual answer is that they want their IT work to be “better, cheaper, and faster”.
Truth be told, if you work on the delivery aspect suggested by many agile approaches you will get part of the way to better, cheaper faster. The better happens if you utilize the various engineering practices that integrate development and testing much tighter together and put a bigger focus on not sending crappy code to production.
The cheaper and faster will come about, to a small extent, if your current software development process has a lot of waste in it and you are able to remove that waste by adopting an agile approach. Many organizations have realized some gains through:
- An iterative or flow based delivery approach
- A highly collaborative team working on one effort at a time
- A focus on delivering value for your stakeholders
- Measuring progress based on value delivery rather than on how many intermediate tasks you complete or deliverables and artifacts you produce.
But that only takes you so far. There’s only so much waste in your software development practices that can be removed by improving your delivery processes, and software development does have a speed limit.
You can only get real cheaper and faster if you actually change what (and how much of it) you are working on in the first place, and only do those things that have a true impact. That, of course means NOT working on those things that don’t have impact. This is not something your delivery team can accomplish alone. You’ll need to understand what your stakeholders are trying to accomplish and figure out how to allow them to do that with the least amount of work possible.
This means that you’ll need to have some open and honest discussions about what options the delivery team can provide, and what decisions your stakeholders have to make. These may be some difficult discussions, especially if your stakeholders are used to your delivery team performing what appear to be miracles. This is what the authors of the agile manifesto meant when they said “customer collaboration over contract negotiation”. This is why people in the agile community talk about transparency. You can’t truly collaborate with your stakeholders if you aren’t willing to be up front about your delivery teams capabilities and yes your limitations. You also can’t truly collaborate with your stakeholders if you are not willing to openly talk about the need for them to make hard decisions, and why they need to do so.
Failure to have those open conversations will put you in the position of iteratively producing things that no one really needs. Is that really better, faster, cheaper?