Skip to content
July 22, 2011 / KaTe

The Evolution of Scrum

The new Scrum Guide. Released on Wednesday with new looks, wording and some things missing – but missing on purpose. And not quite even missing – moved to “Good Practices” bucket.
Scrum has been evolving constantly from the early ages – but these are the most significant changes that I have witnessed in my not-so-long-but-quite-intensive Scrum career. In the beginning Scrum did not even have a Scrum Master – this role appeared with time. Same applies to the chicken and pig concept. Especially the good practices have been altered and added over time to accommodate different styles of software development, different technologies and cultures. So let’s take a closer look at what has changed.

First glance
Scrum Guide looks cleaner. Divided into clear chapters and sections, with no tips, clearly supporting Scrum’s 3 roles, 3 artifacts, a handful of events and the Definition of Done. Starting off with some theory and principles, explaining the purpose with clear conclusion in the end, sprinkled with some history and credits. What I especially like in the beginning of it is underlining the three pillars of Transparency, Inspection and Adaptation.

The Development Team
This is the part I am most concerned about. The Team is now called The Development Team with strong stress on no titles – everyone is now called a developer. In my opinion this might reinforce the misconception of a cross-functional team, which is twisted enough already. Let me explain what I have in mind. Lots of people think that a cross-functional team is the team on which everyone knows exactly the same – all team members have unified expert-level knowledge about everything in the product they are responsible for. People are scared of the idea that they will not be able to reach mastery in everything needed to act as a cross-functional team. So now, explaining that there still can be BAs, testers, DBAs, architects and others on the team (but they all will be called Developers) will be harder than before. Especially due to equality between the words “Developer” and “Programmer” when translating to other languages. I can see why this change has been made – there is a trend in some companies towards building BA-teams, Dev-teams, Test-teams and this change is trying to stop it. For US market I view this change as very positive, but for international – not as much.

I love to see that go. Although the fact that commitment is not equal to contract has been underlined many times in many ways, it’s still something especially management cannot understand. After the team committed to a sprint or a release management would expect for them to sit at work for 13 hours a day only to meet that “commitment”. Of course this does not mean that scrum world is now commitment –free. You can commit to a person, you can still commit to a task, but what is that thing that estimates work inside the sprint is a forecast. It’s now easier to perceive that it can be wrong. And the longer in your forecast you are trying to stretch, the more inaccurate it becomes. By this change we are introducing the cone of uncertainty inside of the Sprint, not only for a release, preparing stakeholders for a possible forecast mismatch even inside of the sprint.

Burndowns used to be the most commonly recognized Scrum artifacts. This feels like an era is ending – not every team needs to have this nice slope-like thingy on the wall anymore. The burndown idea is still supported as a very good practice. But some teams came up with other ideas of tracking progress – like for example a burnup or summing up the failing and passing tests every day. Teams are not limited to a certain kind of chart anymore. Freedom – here we come.

Release Planning
There has been some confusion over release planning included in the Scrum Guide, so I am very pleased to see that removed from it. Release planning is essential for every team, but some of them only need planning and grooming to accommodate all of their needs. This is moved to the good practices section.

The Plan
The Plan aka Sprint Backlog. The Sprint Backlog used to be referred to as a decomposition of Product Backlog items. Now, you don’t need to break them down – as long as you have a plan. I think that this is a smart move, having in mind that some teams might have their Product Backlog items small enough that they might not need to be broken down. Hello freedom – once again.

This is a part that does stir the Scrum world a little. Coaches and trainers were explaining on and on what does it mean to be prioritized in Scrum way. But all this time, in the back of our heads we have that model of high-medium-low lingering. If you think of something ordered, you automatically switch into thinking that two elements should not be equal in order, while as far as priority is concerned, multiple issues might be of priority zero. But this is just the “soft” reason behind this. The real problem is that backlogs should be ordered by business value, risk and/or priority. Depending on circumstances you will have different things that matter more. So the backlog can still be ordered by priority, but we are now distinguishing one from the other.
Why are we changing this word – coaches might ask – weren’t we achieving the goal already by explaining that two items cannot be of the same priority? Yes, I would say. Although look at this problem from our students’ standpoint – priority is never equal, because that’s what we are teaching for years. Anyone else will have a different, more natural perception of the difference between order and priority – I encourage you to observe your environment.

Team Size
Last big, and very important change is the change of the definition of the team size. Previous guide used 7±2 for determining the perfect number. This one expanded it to 3-9. I am glad to see that. This is what I have been teaching, that the minimum size of a team recognized by me is 3. But a 3-person team is very unstable. Not only might it not have all the skills needed to perform the job, but also any disruption blows the Sprint away. This is now clearly stated in the Scrum Guide and I believe that to be very true. One of the teams I used to work with were comfortable working in teams of four, and that was off limits from the previous guide.

As you can see there are many major changes to the guide. There are lots of small ones too – I especially like the stress on the Definition of Done, which I view as the heart of Scrum. Many elements have been explained better, are clearer now to someone that is touching scrum for the first time. We only have to remember that the Scrum Guide is only the “rules of play”, not everything there is about Scrum – just like chess, you cannot learn to play well without observing senior players and grasping the spirit of the game. So, supporting this, let’s put one of the pillars of Scrum into action – inspect and adapt.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: