As I’ve advised a few teams this year who are making the switch to agile, I’ve found myself advocating more and more heavily for Kanban or “continuous flow” styles. I thought I’d take some time and write down what I think are the reasons I’m moving in that direction. Of course, Kanban is a frequent topic on DZone. I won’t waste your time by describing it, but hopefully I can find a fresh insight or two, or at least say something stupid enough to make people want to comment.
The first reason I want to discuss comes from how I’ve seen agile done, at least on some large teams (over 50 people). As an employee of a large organization, I’ve always been interested in how agile methods work at scale, including how they interact with the broader organization.
Large organizations tend to be very interested in managing risk, and the primary risk in engineering (at least during development) is that whatever we’re doing will not work out the way we’ve planned. For this reason, a lot of energy is expended on figuring out if everything is going the way it was originally planned to go. Note that this isn’t just a concern about costing too much or taking too long, although of course that’s bad, but a concern that the plan is wrong. A status report that indicates that the planned work was done for half the cost or in half the time gets a great deal of attention, for two main reasons. First, it raises the possibility that the work was not done to the right standard, or that it does not do all the things it needs to do. Second, it raises the possibility that we don’t really understand the work we’re doing as well as we thought. This could mean that our estimates of the future work are also suspect.
Of course, in practice, we generally don’t understand the work we’re doing as well as we thought. As nice as it would be, we don’t get to build the same thing more than once in engineering. But if it were possible, the program manager would prefer to have a well-understood, consistent approach to the work, where the line graph shows us steadily moving upward toward completion, tracking exactly to the line that shows our initial plan.
Agile methodologies come into this way of thinking and, at first, they appear to disrupt it. Teams start talking about self-organization, and about embracing change, and program managers get concerned, because they conclude that this means that teams aren’t going to be doing things the same way week after week, and that in any case, the program is going to be changing what “completion” means all the time, so there’s no way to track progress against “completion”.
But program managers are smart, and they soon get over this initial concern. They notice that the agile teams keep performing these “sprints”. At the beginning of each one, the team plans out the work they will do during the sprint, and at the end, they see how they did against the plan. This is catnip to a program manager. As long as we allocate a certain amount of the overall work to each sprint, and we keep meeting our sprint plans, they conclude, we will be on plan for the whole program.
The mental process I’m attributing to program managers may be unconscious, but I’m convinced that something like it must be going on, because I’ve witnessed multiple agile programs where sprint goals were presented to the team ahead of time, and daily standup meetings turned into an “encouragement” session of why it’s really important to meet the sprint goals so we can stay on track for the overall program. And, honestly, as long as the sprint goals are reasonable, this isn’t the worst way to run the program. At least you get a regular pulse as to whether the team is on track. It’s just that I can’t see any way to call this an agile methodology just because it’s agile terminology.
So where do we go from here? Well, one thing we might notice is that these sprints are artificial deadlines. There might be value to the customer of getting certain features sooner rather than later, but there’s nothing that says we have to break things up into fixed-length iterations in order to do continuous incremental delivery of value. Maybe a methodology that doesn’t have sprints would avoid this particular problem.
Of course, not every team has this particular problem. If you’re on a team where sprint content is determined by the team, and the discipline of sprints helps the team to stay focused on necessary work and maintain high productivity, then there’s no reason to change. But if you’re on a team where sprints have become counter-productive and are a source of pain to the team rather than value, then the most agile thing to do might be to get rid of them.
In upcoming articles I’ll talk to other reasons I find myself advocating for Kanban, and hopefully illuminate what I think are some of its key features.