Scrum on One Page

This drawing is part of a Leanpub book: https://leanpub.com/agileplanet. If you like it, you might want to have a look at the book, too.

References:

• The official Scrum Guide
• "Agile Project Management with Scrum" - Ken Schwaber
• Agile Atlas on Scrum (Scrum Alliance)
• Jeff Sutherland's blog

Trivia from the Scrum Guide

I just re-read the current Scrum Guide and I always wonder how things, that are very clearly expressed in this simple document are still frequently discussed, or not known...

I tweeted some of those trivial items and will bundle them here:

#Trivia from the #Scrum Guide: "For the Product Owner to succeed, the entire organization must respect his or her decisions."

— Fabian Schiller (@fabianschiller) October 20, 2013

#Trivia from #Scrum Guide: "No one tells the Development Team how to turn Product Backlog into […] potentially releasable functionality."

— Fabian Schiller (@fabianschiller) October 20, 2013

#Trivia from #Scrum Guide: "The number of items selected from the Product Backlog is solely up to the Development Team."

— Fabian Schiller (@fabianschiller) October 20, 2013

"The Product Backlog is an ordered list of everything that might be needed in the product and is the single source of requirements […]"

— Fabian Schiller (@fabianschiller) October 20, 2013

#Trivia from #Scrum Guide: "When a Product Backlog item […] is described as 'Done', everybody must understand what 'Done' means."

— Fabian Schiller (@fabianschiller) October 20, 2013

#Trivia from #Scrum Guide: "[…] what 'Done' means […] varies significantly per Scrum Team […]"

— Fabian Schiller (@fabianschiller) October 20, 2013

#Scrum Guide: "If there are multiple Scrum Teams working on the system […] development teams must mutually define the definition of 'Done'."

— Fabian Schiller (@fabianschiller) October 20, 2013

Business Value Estimation

This interview is translated from german. You can find the original version on Sven's blog.

Some weeks ago, Sven Schäfer started to estimate business value with his team. They are using the regular planning poker cards to put a value on the story cards indicating how much the customer will profit from this story. I asked Sven to answer me some questions on how this is helpful for them:

You are now estimating business value in your team for some weeks. How did you get to the idea of estimating value in the team?

Sven: Business value - or the answer to why I am doing something - is something that is not discussed very frequently within our team. It is not an essential part of our requirements, too. But deep inside myself I do feel the need to know why I am doing things. I want to do something useful, at last. And I want to know this value is represented adequately somewhere. I do not want to believe only that something is useful, I want to see it somehow. Estimating the value is one option to make this visible for me.

What benefit do you see in estimating business value in your team?

Sven: Most important is the fact, that we are now talking about it frequently. That is, I am talking to other colleagues about what is in for the customer with a certain topic and what the topic contains. I do often not understand, why certain people are doing things, the way they do. I believe, that the discussion helps me to understand that. Speaking about the "why" just helps to understand other people better.

What exactly does "business value" mean to you?

Sven: First of all, I am thinking about money. If I am working for a company, then value always means, that a little more money comes out of an action than you put into it. That is value creation.

What do you do, if your customer does not understand how you estimated the value of a story?

Sven: If the customer tells us, that an estimate is not correct, she will probably have a good reason for that. She will be encouraged to inform us about the reason and give us a better estimate. We will then use this better estimate. Our estimation is only a first shot. If the customer tells us something better or more correct, then we are glad to learn.

Do you observe any positive or negative effects on the team from this value estimation?

Sven: I cannot say this from the perspectives of my team mates. For me personally it is helpful, because I do understand others in the team much better now.

The topic was mentioned positively twice in your teams retrospectives, already. So it seems, you are not the only person, to like this estimation.

Sven: I believe, that it is a big help for our product owner when he tries to prioritize the backlog. I think it is much easier for him, now that he has concrete estimates of the business value.

So the estimation of value seems to work well and to be helpful for your team. What do you think, whould be the next step for your team to advance a little?

Sven: We will definitely have to try to make this estimates more transparent to outsiders. Our customer must realize, that we are doing and working with value estimates and we will have to end up in a discussion with our customer. This will probably be a little bit unconvenient at first, but that is probably necessary to get talking.

Do you see a value for your customer in your team internal value estimation?

Sven: Of course, our costomer has not only one view about the importance and value of specific requirements, too. Every customer team has its own problems and priorities and they somehow have to decide on what is the most important thing for all of them and the whole company. Our value estimation and the discussion that is linked to it, could be a good foundation for the customer to be able to prioritize requirements better.

One last question: What do you think would be a huge step forward for your team?

Sven: I think, it would be exactly this discussion about business value with our customers.

Great! Thank you very much for this interview.

Scrum as a Diagnostic Tool

Use the Scrum lens for inspection

What is Scrum? If you ask this question, you might hear a rich variety of answers. Reaching from „a method to process tasks“ over „a project management framework“ to „an instrument for organizational change“.

But this is not Scrum. These are different applications of the Scrum framework. Scrum is essentially just a collection of useful and proven to be succesful rules and practices. It is a theoretically close to ideal state for product development.

If you assume the Scrum framework to be a close to ideal state, then you can use it to find problems in different contexts – even without applying  it immediately. Let me give an example: Some years ago I was in trouble with a classically led project. At the same time I learned about the Scrum framework and thought: „How would it be, if we wanted to practice Scrum tomorrow?“. After asking myself this question, several issues why this would not work came to my mind, immediately. E.g. we would find no Product Owner, the customer would never work with us on a daily basis and we could never deliver software every two weeks. Thinking for a while I realized, that these issues where just the problems the project suffered from. Thus, trying to imagine using Scrum in my current situation helped me to consciously realize what the real problems were.

This idea is scalable: If you want to know what the real top five problems of an organization are, just go to a diverse set of people in this organization, explain shortly what Scrum is and ask them if this would work for them. Then carefully listen and note the reasons mentioned for the impossibility of using Scrum. After several interviews try to cluster and prioritize the issues you found and I bet you will have a very close picture of what the central and demanding problems of the respective organization are.

Just try it. This is much cheaper than hiring a consultancy and will – probably – deliver very similar results ;-)

Build Flexible Organizations!

It is said, that one of the huge challanges of our time is the great volatility of end customer markets. To face this fact, many companies debate, how to cope with this new market reality. Not surprisingly there are thousands of solutions out there, eagerly sold by consultancy companies:

• You need a flexible and highly adaptive IT ecosystem (see SOA)
• You need to be flexible in handling your requirements (see, Agile, Scrum)
• You need flexibility in your high level planning processes (see Beyond Budgeting, Beta-Codex)
• You need flexibility everywhere. Google for "flexible it solutions" and you will find more than 60.000.000 hits...

But having implemented this "solutions", lots of companies find themselves in situations where they are not really satisfied with the flexibility they gained. Why?

It is just not sufficient, to demand all your processes, tools and people to be flexible. After all it is not your processes, tools or people reacting to the market - it is your entire organization as a system, reacting.

Thus, if you want to stay competitive your first priority should probably be to design or redesign your organization in a way that the resulting system is capable to cope with change as a whole. In other words - you should try to build an organization that avoids organizational dept. 

One of the major challanges of our time might therefore be, to build a sustainable organization where management, leadership and structure are much more situational and much less permanent.

Promote Your Teams

Promote your teams!

Last year I wrote a blog post about self-organization. During the last weeks I talked, read and thought a lot about this topic and my (not so groundbreaking) conclusion so far is, that self-organization describes a great variety of possibilities to organize yourself.

An interesting and fundamental model of levels of self-organization can be found in Hackman's book "Leading Teams". He describes four such levels:

1. Manager-led teams (team executes team tasks)
2. Self-managing teams (team monitores and manages work process)
3. Self-designing teams (team designes itself and the organizational context)
4. Self-governing teams (team sets its own overall direction)

Hackman writes, that well functioning teams are mostly on levels 2 and 3. But even on those two levels you can certainly find more distinct levels of self-organization and team responsibility.

After all I read and saw so far, the effectiveness of a team correlates strongly with its ability to self-organize. The more a team is able to work on level 3, the more effective it can be. But sadly not every team is able and/or willing to take the responsiblities necessary to function well on level 3 without damaging its context or parts of the team.

After this being said - this sounds very much like a classical career path to me. Not for individuals, but for whole teams. If your goal is to develop effective teams in your organization and you believe, that a high level of responsibility and self-organization is necessary to become effective as a team - then why don't you make this explicit by having a team career path? This might be one way, to empower your teams step by step. Of course it must be clear which levels exist, and what preconditions and responsibilities are bound to what level. Additionally you will surely need some expert coaching for your teams to guide them on their way up the team career ladder.

Don't get me wrong - I do not say that you should abolish individual career paths. I just suggest to have an additional career path for teams, too. Furthermore the rewards for climbing up this career ladder must not be financial ones, but just giving a team more freedom and rights in its actions if it has proven to be able and willing to take more responsibility.

What do you think about the idea of team careers? Do you have any experiences with concepts like this?

Empower! Your! Teams!

Empower the Team!

I have seen it time and again: Teams that would probably be able to be high performaning, but are not able to live up to their potential. Why? Because they are used, seen and organized as efficient task processing units.

Most teams could deliver a much greater performance and experience, if they would only be given serious challenges and the freedom to act.

Unleash the potential of your teams and

• compose them in a way that they are able to resolve real holistic challenges (you might call it cross-functional)
• let them use their creative potential by not giving them only tasks - but challenges (maybe a Product Owner that writes some demanding and sufficiently unclear User Stories)
• let them really self-organize and find the best local process to resolve those challenges
• let them evolve as a team (and not only a bunch of individuals) - e.g. have carreer paths for teams
• tell them clearly what they are responsible for and what not
• give them some useful coaching (e.g. a ScrumMaster)

You might now say: Hey, that sounds like I should do Scrum with my teams. But the bad news is: Scrum is only a process and might probably help you to identify the problem of an underperforming team. But it will not solve your problems. Besides this, Scrum has the disadvantage to introduce the roles ScrumMaster and Product Owner, which empirically draw to much attention away from the teams.

So - don't wait! Not for Scrum and not for any other useful or useless framework. Start tomorrow and seek ways to EMPOWER YOUR TEAMS!


Disclaimer: I love Scrum! It is the best framework for software development I have seen so far. The roles Product Owner and ScrumMaster are very essential and useful roles and in my opinion absolutely necessary. Nevertheless you should never forget, that the ultimate goal should always be to deliver a great product - which lays in the hands of the team in great parts!

The Limited Backlog - Addendum

In an earlier post I argued to limit the size of your product backlog. Some days ago, I met a co-worker who told me that some agile experts told him, that product backlogs always have to be limited in size. Superficially, this looks like the very same statement, I made in this former blog post. You might eventually be surprised to read, that I disagreed with the statement, my co-worker made.

Why? Because it is very important to understand why and when limiting the size of your backlog makes sense! The main argument for limiting the size is to avoid the maintenance costs of many backlog items. Especially, if there is a probability, that they will never be implemented at all or the items are deteriorating fastly (what a waste!).

Now comes the pitfall: If limiting the size of your backlog leads to emerging "backlogs" in other places (e.g. at your customer!) you might eventually even increase the overall costs of maintaining the items, if the maintenance costs at the other spots are even higher than they would be in your backlog. This is definitely not what you wanted to achieve in the first place, when you limited your own backlog.

So if you do indeed limit your backlog (which is still extremely valuable), watch out and have a careful look, if the discarded items do indeed vanish, or are only cultivated elsewhere.

So --- What Exactly is "Self-Organized"?

One of the fundamental concepts in the context of Agile and Scrum is the self-organizing team. Despite the fact, that this concept is rooted so deep in the core, the perception of self-organization is controversial - at least in an organizational environment.

Self-Organization and Anarchy

I do often hear that self-organization does not work, since anarchy will rise if no individual controlls the actions of a group. Obviously I am not the only one who hears such concerns frequently. You can read about some frequent misconceptions about self-organizing teams here.

Indeed parts of the definition of self-organization sound very much like anarchy. But there are two important points to be made here:

1. Anarchy is not under all circumstances a bad thing by definition.
2. The main reason for the negative reception of the term anarchy in this context does not come from the definition of anarchy, but from the fact, that "unmanaged systems can behave in a way that the stakeholders don't value".

We are getting closer to the core question, which - to me - is: "If self-organization is good and similar to anarchy and anarchy might behave in a way I cannot accept. What are the borders I have to draw to get a properly working overall system? How do I work with self-organized teams?"

The Theory Behind Self-Organization

Let's dive a bit into the theory of self-organization. The concept of self-organization stems from systems theory. In systems theory (complex) systems and their interactions are observed and described. A special case of complex systems are complex adaptive systems (CAS).

A complex adaptive system is a system that is:

1. complex because of its multiple, diverse connected elements
2. adaptive because it is able to learn from experience and react to circumstances

This matches well with the definition of self-organization of Scott Barton where "self-organization [is a] process by which structure or pattern emerges in an open system without specifications from the outside environment". (Barton, S. "Chaos, self-organization and psychology" (pp. 111-138). San Diego, CA: Academic Press)

Some Facts About Complex Adaptive Systems (CAS)

Therefore if we want to learn about the term self-organization it pays off to have a look into the literature and research in the field of systems theory and complex adaptive systems. A valuable source in this hindsight is Roy J. Eidelsons paper "Complex Adaptive Systems in the Behavioural and Social Sciences".

I will just quote some parts of this paper in the following:

"... some complex systems may not exist in a particular form because the parts simply cannot be assembled that way." (p. 47)

What we might learn from this is, that if you try to construct a complex adaptive system (or self-organizing team) from the outside, chances are, that your system (team) is non-viable. It therefore will not behave like a team for a long time. If you intervene in a living team - you might kill it.

"The course of self-organization in complex adaptive systems is often influenced by positive feedback." (p. 49)

To me, this means that it is important to detect damaging positive feedback loops (e.g. increasing distrust) and it might be a chance to find positive feedback loops (e.g. fast feedback) the team benefits from.

"A common instance of positive feedback is the competency trap [where] successful learning drives an individual, organization or society to a stable but suboptimal solution." (p. 49)

One should look out to avoid the competency trap, which is getting stuck at a local optimum where much better global optimums are possible but not reachable by the team without influence from the outside.

"It should be kept in mind, however, that successful self-organization for a particular system as a whole can produce undesireable consequences for some of its individual parts and for other CAS." (p. 49)

Self-organized teams might behave in a harmful way. Thus we have to set boundaries to avoid a self-organizing team to damage other teams or systems (by intent or accident). Furthermore we should be careful that no individuals in a team become aggrieved.

It might be tempting idea to try to find a "stable" state for a team. But stability might not be the best thing for a team. J A. Scott Kelso writes about the human brain (one example of a CAS) in  "Dynamic patterns: The self-organization of brain and behaviour":

"By living near criticality, the brain is able to anticipate the future, not simply react to the present."

Thus, a state that looks close to chaos  (from the outside) might be a perfectly reasonable way for a CAS to exist and adapt.

Learnings

To me the key learnings from this in working with self-organizing teams are the following:

1. Ideally seek the right positive feedback mechanisms. Look out for side effects and alignment with the organizations goals/vision/mission.
2. Set out your expectations clearly and let the self-organizing team find solutions to fulfil them. Communicate clearly the responsibility of the self-organizing team and ask what they need to take this responsibility.
3. Think hardly about what boundaries are needed to avoid damage that could possible done by a self-organizing system.
4. Try to identify competency traps and find ways out of them (use items 1 and 2 to do that)

Mary Poppendieck summarizes most of this points in Implementing Lean Software Development: "Respecting people means that teams are given general plans and reasonable goals and are trusted to self-organize to meet the goals."

Even easier stated by Jurgen Appelo: "Change the Environment, Not the People".

Update: Uploaded slides from a presentation at Agile Monday Nuremberg.

The Backlog - Keep it Short!

A problem faced by many Scrum teams is an overcrowded Product Backlog. But the even bigger problem is that many of those teams do not even see, that this is a problem! Why is it not a good idea to have a very large pool of work to do? It might even look like a positive message in the first place.

The problem with overloaded backlogs are manyfold:

• A backlog must be maintained and communicated. The longer the backlog, the more work this is.
• A long backlog often contains items, that will never be implemented - bringing those to the backlog and maintaining them is a waste of time and resources.
• A long backlog has a frustrating and demotivating effect. Nobody wants to feel like Sisyphos all the time.
• A long backlog is nothing more than a long queue. You might read "Flow" by D. Reinertsen and let you convince, that long queues are one of the worst things that can happen to you in product development.
• ...

But what is the solution to this problem?

An obvious and easy solution would be to limit the work pooled in the Product Backlog (i.e. applying a WIP constraint on the Backlog). You can do this either by limiting the number of Stories in the Backlog or by limiting the number of Story Points. Two questions emerge immediately from this approach:

1. What will I do with the work, the customer wants me to do that does not fit into my product backlog?
2. What might be a reasonable upper limit for the amount of work in the Backlog (maximum queue size)?

My first answers would be:

1. If the customer has work to do that is more important than work currently in the backlog - let him replace some items. If the customer asks for less important features tell him to come back later. This approach adresses many of the problems with long backlogs and makes transparent to the customer that he is working with a bottleneck (your Backlog!). You can then work on problems causing this bottleneck.
2. Inspect and Adapt on this number! A good first shot would probably be to limit the backlog to the work that is possibly achievable in three month. This depends largely on your context and how stable requirements or User Stories are.

If this solution seems to be to mild for you and you need more radical solutions this article might be a valueable source for you :-)

Update 1: Some further remarks on this topic.

Organizational Dept

In the field of software development, there is a metaphor called "technical dept".  In short, this metaphor says that while you are programming you almost always build up dept. Dept in this case means that your code base decreases in quality over time. You will have to invest time and work to amortize this dept. If you do not amortize your dept, interests will take effect. Thus, as with regular dept, you will always be better off to amortize the dept as soon as possible. Otherwise compound interest will be the effect and at the end you will pay heavily - if you are able to pay back at all anymore.

Speaking about Agile transformations there is another kind of dept. I would call it "organizational dept". It is based on the same concept as technical dept but on an organizational level. As your organization grows, you will take hundreds of decisions. Not all of them will be perfect and thus, you will (with every decision) increase the organizational dept. How does organizational dept look like?

There are multiple instances of organizational dept. Just to mention a few:

• People in the "wrong" position (on jobs they are not suitable for)
• A wide gap between the culture wanted and the culture existing
• Unresolved conflicts between people
• ... and many more ...

As with technical dept, if you do not regularly and fastly cope with organizational dept, interests will occure and over time compound interests will make your dept almost unbearable. At some point you might not be able to pay back at all anymore! Speaking of technical dept, the consequence for a software system is then to be displaced by a new system. What do you think will be the consequence for a company if you get into this state with organizational dept...? I think, we all know!

This is one point why Agile is so successful. Agile folks generally reject living with dept and always try to pay back as soon as possible. The incarnation of this attitude is e.g. the retrospective in Scrum and the focus on continuous improvement and impediments in all Agile methodologies.

Update: Sven Winkler picked up the idea of organizational dept on Boris Glogers Blog and adds some interesing points of view.

It's not the Culture, Stupid!

In many Agile transformations there seems to be an issue with corporate culture. People in the company often think and say, that the current culture is not compatible with Agile and the culture would have to change.

Values often mentioned in this context are the Scrum values:

• Commitment
• Openness
• Focus
• Respect
• Courage

I do only have one issue with this. Try the following: Take this values and present them to some randomly selected persons in your company. Ask everybody the following question: "How important are these values to you and are they part of your set of values?". I made the experience, that every single person will find these values to be important and most consider them part of their individual set of values. How then is it possible, that the corporate culture seems to be a problem?

To answer this question try another exercise: Again take the above mentioned values and show them to some persons and ask them the following question: "How much do you think do people in your close environment live these values?". You might be supprised, that the results will now be much worse than the results of the first question.

Find the explanation for the observed gap and you will probably be a huge step further in your Agile transformation. You can probably do this just by making the gap transparent and asking the people for an explanation. Eventually a retrospective may be a good place to do this.

When is Scrum applicable?

Over the years, I was oftened asked the question: "Is Scrum applicable in this context?" or alternatively "When or under which circumstances can I apply Scrum?". I gave (and read) lots of more or less sophisticated answers to that question, but have a very simple approach to answer this now.

You are able to (and probably should) do Scrum if:

1. You are able to fill a Product Backlog
2. You have - or can establish - a Team (which means team - not group!)
3. You have - or can establish - a Product Owner
4. You have - or can establish - a Scrum Master

That's it.

Of course you can still use several single practices and tools of the Scrum framework if these conditions are not fullfillable - which is not a sin. But you should not call it "Scrum" then!

The Thing Missing in Scrum

I am working with Scrum very successfully for several years now. And it is by far the best methodology crossing my way in software development. Yet, I think there is one thing, missing in Scrum - its slack time.

Most Scrum coaches would probably say: "No, no, no... Slack is not missing. It is ...

1. ... automatically emerging, because the team is self-organized. It is in the responsibility of the team to take whatever slack is needed to accomplish their work."  
2. ... an optional add-on to Scrum. You can just implement some slack additionally as you like. But Scrum does not lack slack. Slack is not missing more in Scrum than it is in traditional work environments."

I personally think, those arguments are not valid. 

Argument 1 is questionable: Nobody knows when he "needs" some slack, to be creative and thoughtful. Slack happens to help sometimes and does not help on other occasions. Thus, slack must just be there from time to time (for every single individual - not the team as a whole), so you get a chance to let your brain defocus and accidentially stumble over some very good ideas and thoughts. The tricky thing about slack is, that you will not "miss" it at a specific point. The need for slack ist not foreseeable. Thus a even a self-organized team cannot be expected to know when to take some slack time.


Argument 2 has its flaw, too: You could similarly say that Scrum has no need to contain the role of a Product Owner, but one should implement it as an add-on to Scrum. But this is obviously wrong, since you need somebody giving input to the team, having a more global vision, and beeing responsible for creating business value. Scrum needs to define this role, since it removes the role of the project manager (who was responsible for this tasks earlier).
I think the same is true for slack: Scrum is much about focus and productivity. This is not wrong, but it lacks a necessary concept of slack. Even more, it squeezes some natural amount of - often healthy - slack out of the team that occurs in most classically organized companies from time to time. The point is: Because you are working so much more focused on creating value for the customer (which naturally comes with Scrum) and achieving Sprint goals, a certain amount of slack should be built in, too. This is why I personally think that slack is the missing thing in Scrum.

I guess it would be of great value to Scrum if the framework contained some slack space for every individual in the team (e.g. everybody has one "free" day, where he is not expected to contribute explicitly to the sprint goals).

What do you think? Is there the necessity for slack time in Scrum or are there indeed mechanisms in place substituting this need? What are good mechanisms to build slack into a Scrum team?

Priority Race - A Game for Effective Retrospectives

I will introduce a game I invented for facilitating effective and active retrospectives. As every experienced ScrumMaster knows, it is not only important to prioritize (or more correctly: order) your product backlog, but it is also important to prioritize your impediments. This game can help you, making retrospectives more active and fun while obtaining a good order for your impediments.

Material: Non-transparent tape, Scotch tape, flashcards or sticky notes (red and green), flipchart marker, wall or big table

Preparation: Before the retrospective begins, you will have to search for a wall, where you can draw some vertical lanes with your tape. You can alternatively use a large table, which is the second best option. Mark the lanes as follows:

Initial setting: Draw some vertical lanes on a wall (this is the "race track")

It often helps, to put numbers at the top of every column (you can do this easily, using post-its).

How the game works

Step 1: Split your team into several groups of approximately four people. The groups then collect positive and negative feedback on cards (you can alternatively let everybody bring his own feedback, but I like having initial conversations in small groups).

Step 2: Let the groups explain their feedback and put the cards on the wall/table. At the same time, group the feedback cards to clusters of equivalent topics.

Step 3: Put all card clusters to the starting line of your race track, that is position 0, as depicted below.

Put the impediments and things that work fine in the first column (column 0)

Step 4: Now everybody has to execute two moves with green and two moves with red cards. I.e. advance one card two columns to the right or two cards one column with every color. Everybody should try to get her favourite feedback cards as far as possible to the right (but at most two steps). Do this until everybody executed four moves. You can either let the participants do their moves one after another or at the same time (which saves time).

Player 1 advances two green cards one column and a red card two columns

Player 2 moves two green cards one column to the right, and so does he with two red cards

Done: The result will be, that all cards are distributed on the racing track. The distribution is not arbitrary, but reflects the prioritization of the issues in the team.

All Players moved four steps: Prioritization is done.

 
You are now free, to continue with your retrospective, going through the feedback from the right to the left. You can also take a fixed number of green and red cards to focus on in the remainder of your retrospective or take the order as input for your impediment backlog.

You could now focus on the top three cards for further discussion

Hint: You should do some computation before starting the game: Depending on the number of participants you should adapt the number of columns or/and the number of allowed card moves to do for every participant.

You can also use this mechanism for prioritizing any other kind of material (even your backlog) with a larger group of people. I used this game with up to 20 people, prioritizing up to 20 items.

Real world example: Initial setting

Real world example: Result

The great advantage over prioritization with dots or other markers on the cards is, that the result is immediately clear and much more intuitive and visible. No counting - just looking!

Just try it - and if you have any ideas for improvements, different applications, variations, or positive or negative experiences I will be deeply grateful for any comments.

Why Agile is Doomed to Succeed - If Done Wholeheartedly

and why Scrum implementations sometimes fail - or do not deliver what they promised


I recently read the book "Drive - The Surprising Truth About What Motivates Us" by Daniel H. Pink, which is much about motivation in the 21st century workplace. There is a tight connection between the ideas expressed there and the thinking and principles behind the Agile movement (e.g. Stoos-Network, Scrum, XP, etc.). I want to try to work out this connection, so you can understand one of the key success factors of Agile. If one understands these, one has - as a byproduct - immediately a good understanding at hand, why Scrum implementations do sometimes either fail or not deliver what was expected of them.
I will at first try to explain the core drivers and levels of motivation Pink describes in his book. He destinguishes three levels of Motivation:

• Motivation 1.0: This is what essentialy motivates every kind of mammal to do whatever it does. It's about the basic necessities for survival: eating, drinking, reproducing, security, etc. In essence Maslow's hierarchy stages 1-3. This was probably fine for humans in stone-age and earlier times.
• Motivation 2.0: Essentially based on rewards and punishment (or as Pink states it - carrots and sticks). This was one of the main drivers of the industrialization era where thinkers and managers where broadly influenced by the theories of Frederick W. Taylor and his "scientific management". It is all about command & control and extrinsic motivation. Work in this times was in huge parts not very complex and consistet much of simple repetitive tasks, that are done by computers and robots nowadays.
• Motivation 3.0: There is strong evidence from scientific research of the last five decades, that Motivation 2.0 (rewards & punishment, extrinsic motivation) are very unreliable and weak motivators in our current social and industrial environment (but still relevant for some very specific settings). If you want to read about and understand this hints - read the book! Following the book there is a better motivation scheme than Motivation 2.0, wich is based on intrinsic motivation. This motivation scheme has three core drivers:
• Autonomy: Not to confuse with independence! Autonomy means the need and ambition to have as much as possible autonomy over the work to do. It means having the opportunity of acting with choice (e.g. choice over how to do the work and when to do it best). "Control leads to compliance; autonomy leads to engagement".
• Mastery: The willingness, to strive for excellence. It is about continuous improvement and perfection of the personal skills. Which is not the willingness to be the best of the best, but more the drive, to make the most out of the talents and abilities one has (which is the most you can expect!).
• Purpose: Everybody wants to see the work he does in a greater, meaningful context. The work one is doing from day to day should have some greater sense, which is indeed almost always the case, since most of all work is done for some customers.

So far - so good. But where is the connection to Agile?

It is essentially very simple. Agile is in big parts build exactly around the core drivers of Motivation 3.0. Let me explain this shortly:

• Autonomy: Starting with XP, continued with Scrum and now discussed in the Stoos-Network is the central idea of the self-organizing team. The idea is to give a team as much as possible autonomy over the work to do.
• Mastery: Here craftmanship (XP) and continuous self-improvement (Scrum, Stoos-Network) are the keywords. These postulations and processes are inseparably connected to agile processes and ideas.
• Purpose: Agile frameworks generally build upon integration of the customer. The tighter - the better. Direct feedback and collaboration with the customer is probably the best way of getting sense and meaning to your work. This is because you immediatly see, who benefits and get direct feedback.

OK, I understood that, but where is the point of failing Scrum implementations? How does this motivation stuff help me understanding the why of failure? It is not hard:

Scrum works out well, if you encourage these points, since motivation of your teams is very likely to increase. Increased motivation leads to increased productivity and - by the way - to increased satisfaction.
If you do only use the mechanics of Scrum, but do not really let the teams self-organize (giving them the freedom to make their own decisions!) or do not cultivate craftmanship (invest in education, encourage and set the stage for self-education) or do not bring the customer as close as possible to the team, motivation will not flourish. Thus, you are very likely not to improve very much - and be doomed with another process corset. Which I would just call failure.

Making the Case for Story Points

Or: Why Story Points Outperform Man-Days easily

I introduced Scrum to a number of teams now. There was always big discussion whether estimation in Story Points is of any use. I think estimating in Story Points is one of the really great inventions of the Scrum framework and I want to draw out the reasons for this believe in this post.

Estimating in Story Points has great advantages in multiple aspects:

Team Advantages

• Story Points are a team metric. They are always estimated by the whole team. In my experience those estimates clearly outperform man-day estimates, since they depend not so much on who actually carries out the estimated task. Thus Story Point estimates are more reliable.
• Since everybody in the team participated in the estimation most people feel more accountable for the work behind the Story. This is often not the case with man-day estimates which are in many cases given by experts and carried out by someone else.
• Since the whole team estimates, much more information is shared among team members. This supports reducing islands of knowledge.
• In emerging discussions during estimation open questions and risks are discovered very early.

Abstract Number Advantages

• There is no immediate connection between Story Points and real working hours. This makes estimation often much easier and removes useless points from the discussion agenda in estimation meetings.
• Estimating in Story Points makes you almost immediately think a little more abstract during the estimation. You often do not loose yourself in the details of the implementation which makes estimation faster but still accurate enough.
• Story Points are usually estimated in fixed and fastly growing steps (e.g. the Fibonacci Numbers). Therefore the amount of uncertainty and risk is simply expressed in the resulting number. The bigger the number - the higher risk and uncertainty. This is clearly expressed by not having numbers like 427 available (which would suggest high accuracy for outside observers).
• You can estimate earlier in Story Points than in man-days. The reason is that you can much earlier say how big a task is relative to other tasks, than to determine exactly how many days you would need to implement it. Relative estimation seems to be easier to accomplish for human beings than absolute estimations.
• Estimations in Story Points are often more honest than estimates in man-days. The reason is, that you do not have the feeling to "promise" to be done in X days.
• Since the Story Point number is abstract you do not have the temptation to build in buffers. Thus you have much better control about the real state of work.

Efficiency Advantages

• Estimation in Story Points is often much faster than classical estimation in man-days. Many of the reasons for this point are still mentioned above. Additionally, there are methods to get those estimates really fast (e.g. Planning Poker or Magic Estimation).
• By estimating in Story Points you avoid unnecessary discussion and justification for the time needed ("Why can't you do this in three days? Five really seems a little to much...").
• You additionally avoid useless discussions about teams performance ("you are three guys working five days a week - why did you only finish work estimated for six man-days last week?"). To be clear: discussions about teams performance (positiv or negative) are legal and often good hints for impediments, but not in the indicated tone. Thus Story Points can switch your attention from justifying to solving problems.

Self-Improving Mechanism

• In my experience you get an excellent predictability for your projects progress with Story Points in early project stages. This is because Story Points contain a self correcting mechanism. Slow or fast progress will show up early in the project.
• If you made some errors during your estimations the errors are very likely to be averaged out. Thus you do not have to care so much about the correctness of your estimates, which saves you good amounts of time.
• The estimates in Story Points are self adapting. If a team changes, the mechanism adjusts itself immediatly. If the teams performance increases or decreases you do not have to re-estimate. All estimations stay valid and you can still easily predict progress.

I do not love to say this, but there are two disadvantages at hand with Story Points from my point of view:

Shortcommings

• Firstly, they are hard to explain. Almost everybody is familiar with some estimation in man-days. The concept of relative and abstract estimates are difficult in the first place. But this vanishes after only a few weeks.
• The second point is that in our times and organisations you often have to do some recalculation from Story Points to man-days for financial reasons. This is easy, but is work that generates only limited value.

If you have any other arguments on estimations in Story Points - feel free to comment on this post.

In essence, the central goal of estimations is to get the necessary metrics and information to make progress transparent. This is obviously possible with both, man-days and Story Points. But considering the huge amount of advantages of Story Points this - at least to me - seems to be the better and more efficient way to achieve this.

But after all - it's an estimation technique and the only thing you can be certain about is that it's to some degree uncertain.