In February, 2002, Donald Rumsfeld, then Secretary of Defense under George W. Bush, uttered an oft-maligned and usually ridiculed statement in a Department of Defense news briefing:
Reports that say that something hasn’t happened are always interesting to me, because as we know, there are known knowns; there are things we know we know. We also know there are known unknowns; that is to say we know there are some things we do not know. But there are also unknown unknowns – the ones we don’t know we don’t know. And if one looks throughout the history of our country and other free countries, it is the latter category that tend to be the difficult ones.
The language may be convoluted, but it’s impeccably true. We can be aware of our own ignorance: the “known unknowns,” according to Rumsfeld.
However, it’s the things that we are yet unaware that we are ignorant of that are likely to bite us in the ass.
Software development has two major components. First, and most simply, is the active design, development, and testing of the code. Secondly, however, is the planning and coordination of the delivery of that code.
Generally speaking, the larger the first part is, the more difficult the second one. A single programmer working alone can often easily predict how long it will take him or her to complete a specified unit of work. The more people that get involved in a project however, the more uncertain things become.
The ability to predict software deliveries is important (well, it’s important to companies that sell software or services based on software). For example, it’s quite possible that a software product might take so long to develop that the company will never recoup its investment (hence the huge amount of interest in early or first providers of software services). And, like military operations, it’s the “unknown unknowns” that are impossible to plan for and difficult to handle when they occur.
Scrum and related “agile” development practices tend to focus on iterative development and planning in an attempt to mitigate these sorts of unexpected changes.
They’re not, as some people might suspect, intended to let the product stakeholders change their mind on a whim. The central idea is that, by breaking development up into discrete chunks (where each chunk is fully functional and working), it gives the development team opportunities at regular intervals to change direction or adapt to new circumstances.
Teams that are new to scrum often have misperceptions of the practice, ranging from a misunderstanding of the various components (stories, tasks, standups) to a reluctance to move away from personal responsibility to team-based management. One of the scrum fundamentals, however, should remain at the core focus of the team: scrum is focused on delivering working software, and not on time tracking, management reporting, or a plethora of other benefits (perceived or real) that might come out of it.
When you’re faced with an uncertainty in the scrum practice, ask yourself: How can I best deliver working software in a predictable manner? If the process doesn’t support that, then get rid of it.
Unexpected events happen: for example, you might start on a feature, only to discover that it’s much more difficult than you originally anticipated. While that points to a need to improve your planning (and that’s an ancillary fact that needs to come out at the retrospective), you need to ask yourself what you can do to deliver some working software. If you can reduce the scope and only deliver a small part of the larger feature, then do that. If you can bring in someone else to help, then do that. There’s no right answer.
By resynchronizing at the end of every sprint cycle, scrum lets a team handle not only the “known unknowns,” but also the “unknown unknowns” that inevitably attack the software development process.