I recently received a diagram that illustrated the integration of the Scrum framework in a government software development plan. It was well put together, but I noticed a peculiar item: The diagram showed six-week sprints. Six-week sprints are well outside the established and accepted four-week max timebox for a Scrum sprint. Everyone familiar with Scrum knows that. What was interesting to me was why an otherwise good Scrum diagram showed such an obvious violation of Scrum principles.
I realize that the four-week sprint maximum is somewhat arbitrary. There is really no invisible four-week wall out there that will cause a Scrum project to self-destroy if it goes longer. The reality, however, is that Scrum, like all other Agile frameworks, has as a goal the delivery of working products in short intervals. So what is a short interval, and why do people resist them?
Agile derived its principles, its ethos, from Lean manufacturing processes. Agile is the non-manufacturing project version of Lean manufacturing processes. Scrum, meanwhile, is a form of -- a flavor of -- Agile. Now, in this article when I refer to Lean I am talking about the Lean manufacturing processes as applied by companies such as Toyota and Boeing Aircraft, to name a few. I am not referring to the Lean software framework, which is another framework under Agile. In my opinion it is unfortunate that they use the same name -- but I digress.
So, going back to my point, Scrum is a framework that complies -- or should comply -- with Agile methods. Agile has 12 principles
, and two are basic:
The "highest priority is to satisfy the customer through early and continuous delivery of valuable software."
We should "deliver working software frequently . . . with a preference to the shorter timescale."
As you can see, Agile principles - as well as Lean principles -- strive for short intervals to deliver working products, and the shorter the better.
In Scrum, the shorter the sprint (plan/do/check cycle, in Lean manufacturing terms), the more effective the process control. Long sprints are counter to the Agile ethos. Waiting six weeks to realize you are on the wrong track or that your timeline is off can put the project in jeopardy. Checking progress and establishing backlog items as completed, or not completed, every two weeks is much better. Short sprints eliminate surprises and eliminate waste -- which is one of the main goals of Scrum. Short sprints also allow the team to deliver quality, working, tested, and documented functionality to the customer more quickly. And that is the main measure of success in Agile.
I realize a lot of new Scrum teams are reluctant to tackle two-week sprints. If you are new to Scrum, the natural tendency when given a timeline is to pressure yourself to complete the entire project within that timeline. The sprint timebox should not be viewed as a deadline to finish something. A sprint should be viewed as a simple time span
of opportunity for the team to deliver some functionality. The team should decide what they can accomplish within this time span. That is an essential element of Scrum. We should not say, "We have a two-week sprint to finish the module," but instead we should ask the team, "How much of this module can we get done in a two-week sprint?" Once the "how much" is answered -- by the team -- we have our sprint backlog items set.
This is a total paradigm shift from traditional project management and from Waterfall. But it works. What you will get is a team that produces quality, tested, documented functionality that meets the customer's expectations, every two weeks. We need to keep in mind that the success of Scrum and other Agile frameworks is their ability to achieve customer satisfaction quickly. Customer satisfaction can be reached if we frequently deliver quality, working software that meets the need. Scrum presents us with an excellent framework to achieve that. We just need to keep all the principles in mind as we apply the framework.