Tumblelight

Scrum is not another rugby term*; it is both a rugby term and the name of one of the hottest project management processes to come off the assembly lines. Yes, it actually draws its heritage from Toyota and lean production! Most of it is just common sense though.

A scrum is when the teams pack in a special formation in rugby, head to head, in order to gain possession of the ball.
Here is the opening explanation from Wikipedia, assuming someone didn’t change it after printing.

“Scrum is an agile method for project management, first implemented by a team led by Jeff Sutherland at Easel Corporation in 1993. It has been called a ”hyper-productivity tool”, and has been documented to dramatically improve productivity in teams previously paralyzed by heavier methodologies.”

That sounds too good to be true! What is this?

* A scrum is when the teams pack in a special formation in rugby, heads to heads, in order to gain possession of the ball.

The short story

Scrum is an agile, iterative process where small self-organizing teams focus on producing a working demo of the system at the end of each sprint, iteration. One such sprint is typically four weeks.
The product owner handles the product backlog. This is a list of prioritised features or activities. At the start of a sprint, the team and product owner collaboratively select a goal for the coming sprint. They then select the product backlog items that best support that goal. These backlog items are then decomposed into the necessary tasks. This is known as the sprint backlog. While the team may add or remove items on the sprint backlog during the sprint, the sprint goal remains unchanged.
Through 15-minute daily meetings the team shares status information and the Scrum master removes any obstacles (impediments). The Scrum master controls the process, but the team is totally in control of the implementation.
An executable is presented at the end of the sprint. After this demo, a new sprint starts and a sprint backlog is created.

An overview of the Scrum process.

What is the problem anyway?

Several methodologies assume that building a system is something you can define or specify up front. The struggle to attain this level of confidence is often a difficult up hill marathon or just plain futile. Even small projects need to adapt during their implementation. Scrum, on the other hand, recognizes
that IT is so complex that the only way to control it is through an empirical process. Watch the process. Constantly monitor it in order to get the desired output. The complexity, or our inability to fully understand the problem, has become a dogma.

Who’s who?

The roles in Scrum are actually quite few – Product Owner, Scrum Master and the Team Members.

The Product Owner

First we have the product owner, and this perhaps is the easiest role to understand. This person handles the product backlog and is responsible for setting the priorities for the product.

The Scrum Master

The Scrum master is not far from being a project leader if it wasn’t for the many things he/she does not do. The Scrum master protects the group during the sprint, removes impediments that hinder development and guards the process itself. He or she does not hand out assignments, dictate a solution or even make decisions for the team.

The Team Members

This cross-functional team is made up of around seven people with different background – programmers, testers, etc. They self-organize and structure their work. This means they alone decide on how to form a working group that can implement a solution to reach the sprint goal. This is important and slightly terrifying. Scrum seeks to unleash the group’s potential to strive for a goal as effectively as possible. The group therefore not only has the normal burden of obligations, but more importantly the right to decide how it should be done. This means the group could decide to use its cousin XP (extreme programming) as a base for their development model or perhaps RUP.

Why so few people? In order to get a closely-knit development with fewer overheads, as is typical in agile projects, the group cannot be too big. Even the physical distance will affect the outcome. Going further than a ”coffee cup walk” could be a problem.

Why so many people? I’ve heard people say that a group should not extend beyond 3-4 people in order to stay tight and focused. Scrum, on the other hand, seeks to reach hyper productivity where the group is drastically more effective at cranking out solutions. Call it synergies. Call it direct coupling of brains. Whatever the name, people can be a lot more effective when interacting without obstacles. You get too little of this if the group is too small.

The Process

Scrum is built up around the sprint, or the iteration. Though before we can start, we need a Product Backlog. This list contains everything that needs to be done on the project – stories, activities and so on. The product owner prioritizes every item.

The Sprint Planning Meeting

The sprint planning meeting sets off the iteration and produces a sprint goal and a Sprint Backlog. The goal and this list is the sole target for the team during the sprint. Tasks may by adjusted or split during its course, but no new no product backlog items can be added to the sprint. No boss sidetracking the Scrum master, no desperate plea from the salespeople can alter the backlog. This produces a box of calm that lets the group do real work instead of endless switching between tasks and trying to hit a target that is constantly moving.
Is there no way to change the list? Well, there’s the simple case when tasks are completed faster than planned. The group can then decide to take on more tasks. In some cases, the product owner can OK changes to tasks in order to meet the deadline.
And of course there is the ultimate change the sprint is cancelled; but that is a rather drastic measure.

The Daily Scrum Meeting

How do the team steer the work effort? How does the Scrum master know that all’s well? The answer is the daily Scrum meeting. This meeting lasts roughly 15 minutes and each team member is responsible for answering three questions:

• What have you done since the last Scrum meeting?
• What is preventing you from doing your work?
• What will you do until the next daily Scrum meeting?

The Scrum master will pay close attention to what is said and how it is delivered. Are the team members doing what they should be doing? Is work progressing as it should be? Is the group functional or is something hindering it from performing?

Tracking

To track progress the team uses a Sprint Burn Down Chart. In this graph we can find the number of hours left to do and the number of days available. Hitting deadline is then a question of making sure the line reaches the x-axis by the last day.
In the example graph above we can see that the group’s remaining hours actually increased around day five. The level of complexity was fully understood at this point in time. On day six a meeting with the product owner resulted in a change in ambition and made it possible to reach the sprint goal, albeit with a reduced ambition.

The Sprint Burn Down Chart. Each Scrum team tends to have a ”signature” on how the remaining hours de- crease. Note the bump around day five.

The Sprint Review Meeting

The sprint’s final meeting is the review where the most important piece of artifact is shown to the product owner and others who might be interested – the executable. This piece of code should be something that is actually running. It might be small, it might just do one of the many things it will do in the end, but it is real. This means that there are no mockups, no PowerPoint slides and no dummies – just real stuff.
This concludes the sprint where we’ve done all the designing, coding and testing that is needed to get the executable part of our system to do a demo.
One more thing; the artifacts we need are marked in bold above, not a lot and very focused.

Scale? Control?

Having come this far you might be saying:
”This all sounds all well and good for the programmers, but it can’t scale.”
Actually, it can. By setting up a Scrum of Scrums – the Scrum masters from different projects form a Scrum of their own – you can scale up, as Jeff Sutherland has, to more than 500 people.
I asked Sutherland whether Scrum doesn’t fail sometimes:
”A high estimate would be that 5% fail, but they do so in two weeks.”
There are a lot of projects that take a lot longer to implode than a mere two weeks.
Scrum accommodates the complexity of IT and can increase efficiency drastically. It’s all about common sense and daring to live close to chaos. You let the team free and then check progress. Set free and monitor. Let go in order to gain control – a true paradox.

In conclusion

The process, the artifacts and hopefully even this article are easy to understand. However, Scrum is more, it is also a mindset. Without a deeper understanding of the process, the desired effects might not just appear. It’s a bit like mimicking Rembrandt, armed only with the angle and speed
of the master’s stroke. This is the only project management method that I’ve found I can relate to. So my final question has to
be… You wanna Scrum?

Originally published in JayView.