Even if you only have limited experience with Agile, or are only minimally familiar with its methods and terminology, you probably have asked yourself some of the following questions:
1) What is it about user stories, story points, sprints, backlogs, and burndown charts that really drive improvements in speed, reliability, and customer satisfaction?
2) Why does Agile seem to work great on some projects, and not so great on others, even when we use the same scrum teams?
3) Why do there seem to be many Agile successes at the project level, but so few at the program or portfolio level?
The short answer to Question #1 is…not much. In other words, the work being done within a given sprint might well be just as fast and reliable if it were done under another management approach, and the emphasis on customer engagement and transparency might well be just as strong. One thing that might make the work faster and more reliable, however, is the focused execution that time-boxed sprints encourage. I say “might” because just time-boxing work into sprints does nothing, by itself, to ensure focused execution. For that, we need an organizational commitment to single-tasking—the execution and completion of one task at a time by a given individual (see my previous blog post on this here). If the scrum team lacks single-tasking discipline, or if the organization around it has a culture that promotes constant task-switching (multi-tasking), then any attempts to improve speed via Agile (or any other method) will be severely hampered at best.
Another thing that might make the work in an Agile sprint faster and more reliable is the fact that the team commits to accomplishing a given volume of work, as opposed to individual task owners committing to due dates on their individual tasks. This results in an “insurance policy” effect, such that the risk of any given individual incurring a delay is more easily absorbed by the team, than by the individual alone. Consequently, the team is better positioned to commit to a more aggressive workload, and better equipped to manage the risk that any given individual on the team runs into issues during execution that slow down the whole team.
But if it’s the risk of failing to meet a sprint-level commitment that encourages less aggressive commitments—and therefore a slower, more cautious pace of execution—then what if we eliminated the cause of such caution altogether? I’m talking about eliminating the sprint-level commitment outright. After all, it’s unlikely that the customer really cares whether a given sprint delivers above or below what was promised, as long as the project-level commitment remains secure, right? As an example, imagine that your goal is to arrive at the beach by, say, 11am, and you leave at 8am. You estimate the drive to take 2 hours, so you’ve left yourself an hour of buffer for any unexpected traffic congestion or other surprises. Five minutes after you leave, you realize that you forgot your bathing suit, and turn around to go back and get it. You’ve now eaten into 10 minutes of your 60-minute buffer, and have gotten nowhere, but you still have 50 minutes of buffer, with possible options for making up some time as you go. The fact that your first “sprint” suffered from poor performance may be of some concern, but it’s only the 11am goal that matters, and the probability of achieving that goal is still high. (See my previous blog post here for more on how sprint-level commitments encourage slower execution.)
If you’re with me so far, you can see that time-boxing work into sprints and executing work in scrum teams will only drive faster, more reliable work if they focus execution and aggregate risk. And if it’s focused execution and aggregated risk that make projects faster and more reliable, then any technique or approach you use to focus execution and aggregate risk should suffice, right?
This now gives us some insight into the answer to Question #2: Why does Agile seem to work great on some projects, and not so great on others? Chances are that improvements in speed and reliability experienced on an Agile project had a lot more to do with focused execution and aggregated risk than, say, what time-box was selected for sprint durations. Similarly, if the same scrum team works the next project amidst constant interruptions and with cautious sprint-level commitments, chances are that project will show little, if any, improvement in speed or reliability.
Another big reason some Agile projects are much faster and more reliable than others has to do with whether Agile’s scope-buffering approach is well-aligned with the customer’s project objectives. For example, if a customer’s project objective is to meet a hard regulatory requirement by a hard deadline (i.e., scope and schedule are fixed), then Agile’s built-in preference for a flexible scope would be in conflict with this project’s objective, thus lowering the probability of success.
Let’s use another “drive to the beach” example to examine why Agile’s scope buffering can raise the risk of failure on some types of projects. Say my goal this time is to arrive at the beach absolutely no later than 9pm on a Friday night, because that’s when my favorite seafood restaurant closes down its kitchen. Because the usual drive time is two hours, and I want a full hour of schedule buffer, I leave at 6pm. However, about 10 miles from the beach, there is a single bridge that I must cross, and unbeknownst to me, it often gets quite backed up on Friday evenings, almost always causing a delay of at least an hour. So even though I’ve given myself what usually would be a reasonable schedule buffer, it’s highly likely that Friday night traffic will consume all of it. Under an Agile approach, if I can’t quite finish the final story points during a given sprint, I take care of them during the next sprint. But if I’m still stuck on the bridge at 9pm, I will fail to achieve my objective. Taking care of those last 10 miles “on the next sprint” doesn’t really help me in this case. What would have helped is some additional schedule buffer (leaving earlier).
Finally, let’s turn to Question #3: Why do there seem to be many Agile successes at the project level, but so few at the program or portfolio level? The short answer is that Agile was originally designed to improve speed, reliability, and customer satisfaction at the project level. Portfolio-level challenges, such as maximizing the portfolio’s project throughput and reliability, are only addressed by the effective application of portfolio-level techniques (see my previous post on this here). The most effective such techniques for this have proved to be Project Staggering, Project Buffering, and shifting project buffers from one project to another to balance risk. These are not Agile techniques, but core elements of an approach called Critical Chain Project Management (CCPM), which supports any project-level execution method—including Agile—as long as the discipline of good planning is upheld.
So, if you are happy with the speed, reliability, and customer satisfaction you get from Agile on scope-buffered projects, then by all means, stick with it. Just make sure your Agile projects are vigilant about focusing execution, and smart about aggregating risk. And if you are looking for a disciplined portfolio-level approach designed to maximize throughput and reliability across a mix of Agile and non-Agile projects, go with CCPM.
You must log in to post a comment. Log in now.