This post is a part of our series on rationale for choosing Scrum as our process framework.
You will never achieve perfection. (You will never achieve perfection. You will never achieve perfection!) Thus you should avoid it. Understanding that your strive for total perfection is actually hurting your overall goals of closing in on it, is important to maximize the value of your efforts. Scrum realizes, and addresses this.
Scrum helps you avoid perfection — in order to reach it
The explanation to this obvious paradox lies somewhere crammed in between the Pareto principle and the limitations of the human mind. Yes, that includes your mind *). Don’t be offended by this fact.
The Pareto principle is a general principle, it’s a rule of thumb, not a definite rule. Typical statements based on the Pareto principle are :
- 80% of the software value comes from 20% of the requirements
- Of the time spent with your friends, 80% of it is with 20% of them.
- 80% perfection is reached in 20% of the time.
- … etcetera, etcetera.
None of these statements are probably entirely true, but we’re onto something important. The principle can easily be represented by a graph.
Value being the Y-axis, you easily see that the most value is generated during approximately the first 20% of the time spent. Applying statement #3 above on software project, you might conclude that 80% of a software project’s perfection is reached in 20% of the time. This is not necessarily so. I’ll explain why.
Let’s break the project into Sprint Backlog and apply Pareto principle to each one of the tasks too see this more clearly
Let’s say that these are the first four tasks we’ve committed to during the next sprint. To extract value efficiently from the project, it will be hurting the overall perfection of the project to engage in a work-flow such as this.
It this time, project is due, and your strive for the ultimate perfection in Task #1 has been wasted. Chances are that task #1 has no value without the other three.
Consider this work-flow.
In this example we have reached close to perfection on all tasks reaching Pareto perfection on the project as a whole spending the same, or less, time. It’s important not to use this focusing of efforts as an excuse for compromising quality. This is applying it wrong, and probably the most common misconception of this principle. Quite the opposite, applying the Pareto principle, you’ll have more time tending to overall quality of what you working on.
Think of it this way. You’re going to move water from one bucket to another using only a sponge. You wouldn’t want to stand there for several minutes trying to wring the last drops out of the sponge before soaking it again (Illustration #3). You’ll intuitively wring until only drops come out, then dip it again (Illustration #4). Repeat this process until all the water has been moved.
The question of what happens if we add more time and follow the strategy of Illustration #3 is also a tempting one to ask. This will not add more perfection to your efforts. The answer lies in iterations, but I’ll leave the deduction of this for any later posts on the topic.
The art of software engineering is to identify when the sponge is only dripping. It’s not as easy as in the art of sponge-wringing, an activity where the feedback is quite obvious to anyone engaging in it. We’ll have to simplify and identify some mechanisms to get the most out of the sponge in the case of software engineering.
How Scrum wring the most out of the sponge
It’s not as easy as it seems to identify the dripping in software engineering. As it is hard to spot, we’ll have to use some ninja techniques. The time-boxing principle of Scrum helps us get the most out of our wet sponges.
Attempts to add more time to achieve perfection, turns the blind eye to the sacrifices this implies. Thus we loose out on achieving the perfection we desire so strongly. Scrum uses time-boxing principles to overcome this.
You have only a total of 4 hours to plan the next monthly sprint. If you’re spending more than 4 hours, you’re wringing the sponge when only drops come out. At this time you’re better off jumping into it. Embarking on work and soaking the sponge; water will flow from the sponge once again as you gain insight and momentum.
The Sprint is time-boxed to one month, a “Sprint-box”. This is the maximum of time that can be allocated without The Team doing so much work that it requires artifacts and documentation to support its thought processes.
Into the Sprint-box The Team adds tasks. To see how many tasks fits into the Sprint-box, we’ll have to know the tasks size. This is what estimation is all about. Estimation creates time-boxes for each task.
*) It’s a normal misconception that great achievers are those who defy the limitations of the human mind, and thrive on complexity. It is not so. The great minds who achieve great results are those who work in harmony with the limitations of the human minds, aiming for simplicity. Several quotes from great achievers underlines this fact.
- “Simplicity is the ultimate sophistication” – Leonardo da Vinci
- “Everything should be made as simple as possible, but not simpler.” – Einstein