✄﹣﹣﹣﹣﹣﹣﹣﹣﹣
This article has been removed. An edited version appears in the book, The People’s Scrum, published by Dymaxicon, May 2013.
✄﹣﹣﹣﹣﹣﹣﹣﹣﹣
Read original comments…
“Doing Scrum” is as meaningless (and impossible) as creating an instance of an abstract class. Scrum is a framework for surfacing organizational dysfunction. It is not a process and it is not prescriptive. The core framework of Scrum, as described (e.g.) here and here does not actually do anything. It is, in a sense a contract we put in place between those seeking value and those building it. But a contract doesn’t produce anything. An interface is passive. We need an implementation.
Scrum begins to work when people understand it well enough to create a concrete implementation, to emerge a process that is their own. Understanding and respecting the Scrum framework and the set of rules allows you to become aligned with others, to have a common set of values and principles from which to operate.
Scrum itself can be thought of as similar to a set of game rules. Think chess, think soccer. The rules are easy to learn, and knowing them means you can play the game with others. The rules are the ties that bind us together. But just knowing the rules means nothing in terms of deriving pleasure from the game. You need to play, to be involved. It is doing, not knowing that brings about results. To play well you need to develop strategy, and in team games you need to develop relationships, and trustful interactions.
In any game, once you start breaking the rules everything falls apart, and no one will want to play with you. It is the same with Scrum.
So respecting the contract, the rules, or in software parlance, respecting the interface, allows you to create a process that suits your context — and your context is many things… people, industry, business, market place, product, location, language, physical environment, culture, people. It starts and ends with people. Scrum doesn’t actually do anything, people do things. The Scrum process will emerge through the interaction of the people, and it will be different for each organization or team. And this is where people trip up; too many think that creating their own process starts with breaking the rules. It doesn’t. Do that, and you have failed before you begin.
The Scrum process being created must operate within the agreed parameters, must be bounded by the rules. All methods of the abstract class must be implemented, or the class won’t compile, won’t run. Try to move your bishop in a straight line in a game of chess, and your opponent will leave the table. Pick up the soccer ball and throw it and you’ll be red carded.
The framework of Scrum is a powerful mechanism for surfacing organizational and personal dysfunction. It is that very power that causes people to try to circumnavigate the rules, to take shortcuts. They don’t want to look. But not looking doesn’t cause problems to go away or broken things to mend, it just delays the inevitable giant crash. We don’t call out the value of courage in Scrum for nothing.
Comparing Scrum then to implementation practices such as XP or software craftsmanship makes little sense. Each of these movements offers excellent tools for implementing a solid Scrum practice, for making the abstract concrete. Scrum offers a strong framework and a relentless rhythm to shake out the dust of years.
You cannot “do Scrum” but you can certainly embrace it, and the more courageously you do so the stronger will be your emergent process.
click to subscribe
Agile Anarchy 
Tobias, Brilliant post! You really got to the heart of what Scrum is about – first post i’ve seen that really does that.
AndrewWoody
Pingback: Twitter Trackbacks on Topsy.com
“Scrum is a framework for surfacing organizational dysfunction” – Tobias, while you and others have been saying this for a long time, what people _hear_ is different. Scrum is being bought (and is also very often, though not always, being sold) as a way of improving management of software product development. It’s hard to get an organization to change if they believe all they’ve adopted is a way of getting “more productivity” out of their developers.
Hi David, so then we need to keep saying it, right? And those that are selling Scrum in the way you describe also need re-educating. Just because people behave in a certain way doesn’t mean we sit back and say “well, that’s just the way it is”. I don’t believe for a minute you are saying that, but you describe a problem here and no suggested solution. I’d like to hear how you handle this misconception. Thanks.
Scrum is a framework for sure!
But processes based on Scrum are instantiations AND extensions. Implementations that give flesh to the roles and context to the product.
So people DO scrum and they often do it terribly! To say they don’t DO scrum because they are effectively doing their own implementation is (IMHO) a cop out.
Also, Scrum is a framework for building new software products – that is all it is. Along the way it may uncover organisational dysfunction (but doesn’t have to!) and it may improve productivity (doesn’t have to do that either).
If the experience of DOING Scrum makes its participants better human beings, that is an awesome side effect- not a primary goal.
I don’t think management buy in to Scrum is based on them accepting it uncovers dysfunction – who signs up for something they know its going to show their crappy side? – most people in the organisation know they are dysfunctional but have become educated in the helplessness of it.
MikeMy brain dump…
Pingback: Le Touilleur Express » Scrum ne fait rien par Tobias Mayer
Tobias – yes indeed – we need to keep saying it. But we also need to be very aware of how we’re saying it, and who we’re saying it to. Preaching to the choir is both easy and satisfying to many, but I know you (and I hope I) have ambitions beyond that.
I don’t have any simple answers, because there aren’t any. In situations like this, I fall back on congruent behaviour (because I’ll then at least be able to live with myself).
I have mixed feelings about this post. On one hand I think it’s a great post for anyone not familiar with what Scrum is, but OTOH saying “scrum doesn’t do anything unless you stick to the rules and actually use it” is like saying your car doesn’t do anything unless you sit in it, start it up and drive somewhere.
Scrum is a framework yes, but it IS also a process IMO. Scrum can be used to run your household if you really want to.
Use Scrum to help get people working together instead of against each other, then adopt better software development practices if you need to.
Scrum is a project management methodology, i don’t see anything more abstract there than in the waterfall model. The problem is just that people find it difficult to plan and think in iterations. Most clients or product owners want to have the whole thing in one peace and have first to learn that the way to the right result is is a process of continuous communication, that you cannot order custom software just like a pizza
I have to take issue with this. Scrum is absolutely not a project management methodology. The terms “project manager” and “methodology” are not in the Scrum vocabulary. Scrum is simply a framework, allowing teams to build their own process. There is nothing much methodical about it, it is more like (to quote Michael James) chaos in a box.
Then what is there a ScrumMaster for 🙂 ? it is just a fancy name for a project manager, who watches over the flow of the project.
The quote “chaos in a box” reminds me of what Einstein once said: “If you can’t explain it simply, you don’t understand it well enough”
Scrum might seem chaosish, because it is created for agility.
But it actually has a simple structure that is based on 3 pillars any project management methodology has: Planning, Control and Communication
1. Planning: You do not have a detailed plan for the whole project, but you got a list of prioritized (no chaos here) features of interest. Then you take the first bunch of features for the next sprint and make a detailed plan for these features only. So there we have a method for planning
2. Control: You’ve got a short meeting every morning, so the right hand knows what the left hand does, and if there is a problem, then corrective actions can be taken right away. Therefore again Scrum enables you bring the project from the path of chaos, to the path of working SW as early as possible.
3.Communication: it is the most important part of Scrum. A team can be agile only if it can communicate in an effective manner. That is why scrum teams are usually kept small, because large organizations are slow in decision making, but a small group of people can take action swiftly. And also that is why there is a single Product owner responsible for directing the project. If anybody has questions about the scope or the meaning of a feature, he knows who can be asked.
The problem with Scrum is not a lack of structure, but rather that people in business are used to long term plans with clear goals, and find it difficult to understand how can one start doing something without knowing what will be the result
Control is one of the last things what Scrum is about. The ScrumMaster does NOT control anything. The team manages its own work. In a way you can say the team controls it own destiny. But that isn’t the classic definition of project management control. Scrum is more than just moving from long term to short term planning. It is a totally different mindset and mentality.
Hello,
I’ve arrived to your post through a Spanish translation in http://www.dosideas.com/metodologias/750-scrum-no-hace-nada.html and I am curious about where Scrum asks for courage. I have ever thought it was a value asked for XP as appears in http://en.wikipedia.org/wiki/Extreme_Programming#Values
Thanks and best regards,
Jose Manuel Beas
The Scrum values, from Ken Schwaber’s first book are Openness, Courage, Respect, Focus and Commitment. I’d argue that Focus is not really a value, rather an activity, or perhaps a principle. But maybe that is just playing with words. Scrum is as powerful as it is exactly because of Focus, which gets us to prioritize, commit realistically and minimize work in progress. I’d add to the list of values Trust, Integrity (honesty) and Congruency. But I didn’t write the book 🙂
So to answer your actual question, yes Courage has always been a Scrum value.
Perfect! Thank you for the ref!
Very well written article, and it clearly lays out the basic tenets of Scrum. Over the years, I have worked in so many projects run using Scrum; some successful and some failures. In all the failed projects, including the most recent one, a common thread is the lack of discipline in the implementation to align with the scrum framework. To put it metaphorically, as Tobias did it, the concrete implementation did not look anything like the abstract interface – and no wonder it failed to compile (or the project failed). Some of the scrum implementation blunders I can look back:
– failure to take the product backlog seriously both by the PO and the team
– randomly taking up sprint tasks without proper association with the product backlog that is prioritized by the PO
– team members taking up too many tasks for the sprint without a realistic estimation of efforts to complete within the sprint duration
– too many sprint backlog items were included without a proper definition of ‘completed’ for those
Another point I would make is this: many professionals who are new to Scrum may not like the ‘visibility’ that it brings. They don’t enjoy becoming the focal point of a project that lost velocity. And, they would do their best to blame it on Scrum. That is the time, a truly functional organization must come forward and encourage the team. But in reality, we see the opposite, that the organization ends up blaming the project problems on Scrum too.
Pingback: Best Links of the Week – Dec 18th 2009 : Agile PM Scrum
Tobias,
I agree with the idea of Scrum as a framework, but many people have problems with this because they are used to looking for tools and cookbooks.
Your game analogy is very rich. Take Monopoly – it started as a geme with some set rules, but with a twist – the makers actually encoraged players to experiment with alternate rules and styles of play. Recently, the makers incorporated many of these alternate rules and playing styles into the game manual and related books. The core ideas behind Monopoly as a gaming framework did not change, but they gave birth to a host of other games that are fun in theiw own right.
To me, the essential Scrum is very much like that. We can be successful and comfortable using the basic framework, and as we gain experience, we will modify our approach to answer the demands of our environment. Scrum will not change, but we will change the mix of tools and other frameworks that we use with it.
People looking for tools and rules will not be comfortable with Scrum, and will inevitably try to use their existing tools to do something more like Scrum. Some will fail and blame Scrum, others will fail and realize that their approach was at fault.
I agree totally with you !