A Rumsfeldian Approach to Sprint Planning
UPDATE: A disclaimer to calm some readers who were worried: this post is by no means an endorsement of Rumsfeld. I’m just taking a peculiar statement of his and using it as a way to think about scrum (and I just thought it was funny).
“There are known knowns. These are things we know that we know. There are known unknowns. That is to say, there are things that we now know we don’t know. But there are also unknown unknowns. These are things we do not know we don’t know.”
– United States Secretary of Defense Donald Rumsfeld, February 12, 2002
It’s not an accident the name of my department at U Penn’s School of Medicine is Information Services, not Information Technology. We develop software, and for that we are adopting scrum, as I mentioned in an earlier post. But we also provide services, such as meeting various ad hoc reporting needs for our clients. Until now we have tended to be more reactive than proactive, in that we typically wait for service requests to come to us (and they often come on short notice) and then we scramble to fulfill them. Our current workflow is all about multi-tasking and being interrupt-driven, both of which are productivity killers. In a certain sense we are extremely far out on the agile spectrum, in that the idea of locking down requirements and schedules for even as short a duration as a 2 week sprint will be introducing a lot more workflow structure than we’re accustomed to.
To make the change, we need to become more proactive than reactive. Do all those ad hoc requests really need to be quite so ad hoc? Can we do more to anticipate service needs and plan better? This is where Rumsfeld’s seemingly mystifying statement has relevance:
- A known known is the work we are planning for a sprint. We prioritize user stories, estimate them, etc. and plan our sprint. This is the work we know we will be doing.
- A known unknown is work we know is out there, but we lack good information on when and/or what exactly it entails. An example is a complex, crucial report we know needs to be run on a certain date, but we don’t know what kind of data issues might come up. The report might turn out just fine and only require a few minutes of effort to run, or the data may contain very subtle errors that take hours to investigate.
- An unknown unknown is work that cannot be anticipated: a newly exposed bug on an essential system that urgently needs to be corrected; the Dean asking for some new report that no one knew he would ask for (and asking the Dean to get in line is generally not an option…), etc.
A notion we’ll be testing as we move to scrum is whether we can move a lot of our current known unknowns into the known knowns column. To continue with the report example, if we know when it will be run, we could put some slack around it in the schedule, since it’s an important report. We also could do a test run of the report ahead of schedule and review it with the client to see if the numbers add up as expected, to minimize the risk of a last minute surprise. This will require us to be more proactive with our clients, in that we’ll need to seek out and identify upcoming service needs and incorporate them into our sprint planning. We also need to involve our clients more in the overall quality equation, such as asking (and expecting) them to test and review important reports ahead of their due dates. This calls for a culture change for some of our clients, which I expect will be the most significant challenge for us in adopting scrum.
With unknown unknowns such as the Dean asking for unexpected work, we may never be able to control them entirely, but with the tools scrum gives us (such as burndown charts) we can at least more clearly illustrate for our clients how ad hoc requests are impacting their project schedules. It’s also my belief that work requests that are truly impossible to anticipate don’t actually happen very often. The harder cases are bugs that take hours to unwind, or code changes in one place that have unexpected consequences somewhere else. We can reduce these over time by introducing technical practices such as test driven development and regression testing. Both of these will require training and the development of a testing infrastructure, so it will take a while to get there, but we can get there. In the meantime, I’m planning to not have our scrum teams completely fill their sprint time in their sprint planning. We’ll leave some time in the schedule for handling unexpected work.
You might be wondering about unknown knowns – things we don’t know we know. That gets us into the realm of repressed childhood memories and past lives, and I’m hoping that such things won’t impact our sprint planning…
In your environment, I believe even coding bugs are technically in the realm of unknown unknowns. Some teams control for that by accepting only work based on certain parameters. Most teams do not have the luxury of being so selective.
Another approach to controlling for unknown unknowns is to map environments / situations where success is proven so that in new situations a team can identify variables that may inject unknowns into the work. More generally, what exactly is the team’s experience?
In my environment of business and product development, much of the landscape is made up of “We don’t know what we don’t know.” The secret is to at least map that with scenario analysis.
Rumsfeld was not the originator of this concept, but I was intrigued when I heard him mention it. In an incredibly complex world (‘complex’ in the theory definition), unknown unknowns are more common than any professional likes to admit. It is what makes the ‘social sciences’ an oxymoron IMHO, and the principle reason economics for the most part failed us in predicting the Great Recession.