Strange title isn’t it? Don’t worry, I’ll explain.
No matter how committed we are for lean and agile principles and methods, there are environments and situations where it is required that the project in fact operates, from a certain point of view, in a waterfall style.
I’m speaking more of the higher granularity of work packages, like a release plan, or a commitment for delivering a fixed set of features in several months’ time for a fixed deadline. There can be various reasons to this, mostly product management related:
- Contractual obligations (typical in consulting or outsourcing type of projects)
- Sales people pushing to make longer term commitments to customers
- Upper management wishing to do quarterly or yearly planning of expected revenues from new software
- Competitive pressure to deliver X, Y, Z functionality by a certain date for either catching up with competitors or getting competitive advantage
We kind-of all know that this is a wrong approach, as a steady flow and frequent, agile delivery of new features is more efficient in the long term. However, especially in large organizations, it is either impossible to get the buy-in of all the stakeholders (like sales people, upper management, shareholders etc.) into this way of thinking, or even if all of this is given, there are situations where it is simply too tempting to say things like “in the next year we’ll create a much better, redesigned version of our software product”.
So what can we do in such situations?
My theory is that Scrum does not fit this kind of environments well. If you have, let’s say, a big release of 6 months involving multiple teams, the temptation is too big to have procrastination (regarding specifications, architecture and design, figuring out all the dependencies across sub-teams) at the beginning of the release cycle, and a big hurry (“all hands on deck”) towards the end. Especially in the end-game, things are changing so fast (when all the pieces have to fit together) that it is a luxury to change the plan only every 2 or 4 weeks, and many times it is simply impossible to plan a sprint when you know that tomorrow or the day after you get a new drop of another team’s work or a last minute design change that will screw up half of what you are doing.
Therefore, I believe, and experience has shown during my team’s work in the recent months as well, that Kanban serves agile projects under a waterfall-type umbrella much better. You don’t have the frustration of “I can’t do proper sprint planning under these circumstances” and “Impossible to estimate tasks when there are too many unknowns” and “Why do you want to change my sprint backlog every day?”, but have a method that just works.
Tasks coming and going every day, no problem.