I’m not so sure waterfall will ever go away, but I do agree that companies which adopt agile will have more efficient IT departments. It all comes down to communication amongst stakeholders. Good post Thomas.

Of course most Waterfall have a period of feedback and adjustment at the end. They have to. Because complete, true, Waterfall can never exist since development is exploration of possibilities and the world around a project is never static. But the time elapsing before you get this feedback is driving your development costs up and the first point of return on your investment into the future.

I truly believe that there are so much business value benefit in taking the “Agile” viewpoint that companies adopting it will outlive companies that doesn’t. Agile isn’t a single thing and definitely not a silver bullet. So I’m not really talking about the Waterfall/Agile religious war.

It will be the viewpoint that ensuring early, continuos and concrete feedback, and continuously adjusting to it with the lowest possible cost, that will be the competitive advantage.

I tend to think about this as one case where lack of communication of vision and direction also sometimes puts decisions “in the wrong hands”. Of course there are different levels of decisions, but agile and lean puts much of the decision making in the team since that is where the best knowledge of the issue tend to be available. What I often see is that teams have not been given the mandate to take improvement decisions except on a very small scale.

Let’s talk about the decision to invest in development of an automated testing framework. This might be a large investment, and in many cases this decision will be delegated upwards. It would then be prioritized according to business value, which with all probability put it a fair bit down the backlog, because in the context of cost/benefit analysis, particularly in the lifespan of a project, it will be hard to present “admissible evidence”. Such evidence could also risk putting unnecessary need of detailed knowledge of technical details on managers.

Sometimes a team will cause this because they think an automated testing framework is only valuable if it is “complete”. So they calculate the cost as one (big) cost. As they are sure that this is outside their mandate they will push the decision upwards. I strongly believe that excellence, and any improvement at all, need to be based in teams and team members. And if the team was truly expected to deliver quality, tested, valuable software, they should have the mandate to take this type of decision. Of course they could not choose implement this in a way that prevented them to deliver quality, tested, valuable software for a long period. So they need to learn to do this kind of improvement in a gradual fashion.

But improvement is a gradual thing. There are no quantum leaps, but you can always make a small improvement over the current state. And this is continuous improvement.

Of course then the team need to be aware of some important visions, such as the expected lifespan of the product they are working on. If the product is expected to live just another year, this is a different scenario that if this was the next generation of their cash-cow.