This article is part one of a two-part series discussing how Scrum employs the empirical process to help manage the uncertainty and unpredictability when creating software products.
If you have ever taken the Certified Scrum Master (CSM) course or read the Scrum Guide, one very important concept you undoubtedly reviewed was that Scrum employs an empirical process control. When taking my first steps into the world of Scrum many years ago, empirical process control didn’t make too much of an impression on me. I remember learning the three pillars of scrum (transparency, inspection, and adaptation) as the means to embrace empirical process control, but they took a backseat to me being more focused on concepts like the product backlog, burndown charts, and retrospectives. As my experience with Scrum grew, so did my appreciation for understanding the importance of empiricism and how intimately related it is to the lightweight rules and roles the Scrum framework provides.
Control Freak
In the early days of software product development, controlling the process (i.e. the process of building a software product), assumed the process itself was defined. That is, building software could and should be managed and controlled in a step-by-step manner. The assumption was that the ability to build the product was readily repeatable (with little to no variation in output) and information about doing so was already known and predictable. Thus, controlling the process should be straightforward. Simply do what you always do and the expected results should be pretty much the same. However, there is a flaw in this thinking. When little to no variation in output is expected, software development has shown to be anything but repeatable. And if software development is anything but repeatable, employing mechanisms that treat it in a defined manner will be inaccurate, frustrating, and lead to a winding and uncertain path.
Take Back Control
It makes more sense to embrace the notion that we don’t know everything about the product, that it cannot be fully understood or defined upfront, that uncertainty and change are inevitable, and that we are dealing with a complex process that requires research, creativity, and experimentation to understand it better. Further, it helps to recognize that software creation requires the transfer of not just explicit knowledge (i.e. things we can write down or verbalize) but also an appreciation for the abilities, thoughts, and experiences in people’s minds (i.e. tacit knowledge) which is more difficult to transfer.
If things are so uncertain, unpredictable, and difficult to explicitly share, does that mean they cannot be controlled? Not necessarily. But it does mean we need to think differently about the mechanisms we use to measure the control. And this is where the beauty of empirical process comes to play. Scrum is a framework that embraces this unpredictability and it does so by employing the three pillars of Inspection, Adaptation, and Transparency.
In my followup blog post, I’ll explain how Scrum manages control in an unpredictable environment with the support of the three pillars mentioned above.