Hierarchical Scrum – How to Introduce Scrum Step by Step

How to introduce Scrum? Not all practices are created equal, I'd say. That became clear to me again while reading "Scrum: The Art of Doing Twice the Work in Half the Time" by Jeff Sutherland.

Even though I've grown somewhat skeptical of the Agile silver bullet Scrum and find some of what Jeff Sutherland wrote an exaggeration and a bit heavy on the side of self-praise, I still like the book. I can recommend it, especially to non-developer people of all trades.

What the book made me think of was a kind of hierarchy of Scrum practices. Some of it to me simply is more important than the other.

How to Introduce Scrum - A Roadmap

1. Reflection

Scrum is about becoming better and better at what you're doing. So the first thing you need to do is check. Check how you're doing: What's already working? What's missing, what can be improved?

For this you have to stop your daily business for a moment. Pause - and reflect. That's what retrospectives are for.

Do them periodically. I recommend once a week when you start; later you can switch down to maybe once every month.

Each team needs to reflect periodically. But if there is more than one team, then all teams should reflect together once in a while. Create a hierarchy of reflective groups. Maybe you want to check out sociocracy as an additonal model for how to organize a business.

Retrospectives are where all involved put together their views, analyze what is, and plan how to move forward. It's the engine of a Deming cycle of Plan-Do-Check-Act.

2. Demand

Retrospectives form the team. A team's fundamental purpose is to serve the environment. The environment is where demand is located. Customers, users, stakeholders of all sorts want a million things from a team.

Of course that's most obvious to the team. But more often than not it's not tangible. Sure there is some manager or customer who wants this new piece of functionality – but how badly do they really want it? They are hardly to be seen near the team.

If Scrum does not deliver on its promises, my first guess is, there is a lack of tangible demand. There is no one really, really excerting pull on the team.

So after a team has been formed in general the most important role has to be filled: who's going to be the product owner? The product owner is the one who impersonates the "will for success". Without an empowered and motivated product owner Scrum will stay flaccid.

In fact the product owner is the most important role on a Scrum team, I'd say (see here for a more elaborate explanation in German). And his/her most important activity is approve what has been done. Yes, approval is more important than specification. Because without prompt approval too much waste will be produced.

Approval always has to be impending. It should not be further away than tomorrow.

Sure, approval in the end needs to be given on several levels. But the product owner is the first one to approve of what has been done. And that should be very, very soon. Whenever a task is started it should be clear when today or tomorrow the product owner is going to come by and check the result.

From this pulling force then other practices follow. They are simply necessary to fulfill this powerful demand.

3. Coherence

Retrospectives define the overall framework for what a team wants to achieve. They are a tool of leadership in self-organization. One of their purposes is to define a common goal. Demand further makes it clear, what's needed next.

But then, after a retrospective is over, how does an organization (e.g. team) keep heading towards the goal? By constantly checking. It needs to stay together and adjust its course - each and every day. Remember: there is tangible demand to be met.

That's what daily standups are for. Whether you ask the three notorious questions – What did you do? What do you do next? What is impeding you? – or do it differently: the purpose of the daily standup is to keep the team aligned towards the goal and energize it.

Daily scrums easily deteriorate to mindless mandatory meetings in the morning.That's because they are misunderstood. They are not about reporting – which nobody likes. Reporting would be about transparency. But despite the three questions which sound like reporting, daily standups are about focus and energy.

Think about a 60W lightbulb versus a 60W laser. The same amount of energy, but differently focused. Daily standups are supposed to bundle the enery of a team, to make all members work in coherence.

Do whatever you need to do for that. Ask the three questions or sing a song or jump up and down together :-) Unless you feel the energy, the motivation rise through a daily standup you're doing it wrong.

4. Transparency

What to do with all the energy in a team? Focus it on what needs to get done to reach the goal. Sure, but what is that? What are the current problems to solve? Make that transparent and for everyone to see. At all times. That's what a  scrum board is for.

The board shows at least what still needs to be done, what's in progress, and what has been finished. So whoever has free capacity can pick from what needs to be done and start progressing on it. Or check with others who are trying to progress and help them if they are stuck. It's all there on the board.

The scrum board is an information radiator. It fosters non-planned flow of activities and communication. It thus is a tool to introduce complexity into the production process. Yes, it cranks up complexity deliberately, because it has to be on par with the complexity of the problems of the outside world.

Many organizations are under-complex. They are less complex than the stuff they need to deal with. Rules and regulations and policies – any form of bureaucracy for that matter – strives for reducing complexity. That's good, because it can increase efficiency – until it gets bad.

Scrum fights the widespread tendency of aging and growing organizations to plan and regulate. One of the tools for that is the scrum board. It provides transparency to allow the team to decide in autonomy what to do next. Less or even no managerial input or control needed. The main task master is tangible demand.

5. Focus

What is it that needs to be accomplished to meet the demand? That's tasks or stories or whatever you want to call it. Stuff which needs to be done. There should constantly be a list of such tasks for the team to pick from. Work should never run out.

Which work to do is a matter of the product owner to decide. He/She analyses the requirements and writes up what to do. This should be done in consultation with other team members as needed. Because tasks put on the scrum board need to be specific, easily actionable, easy to check for completion.

I call this story development.

In story development the product owner chews large chunks of requirements to make them more easily digestable by the rest of the team. Also tasks get prioritized. And to get everyone on the same page and enable the team members to work on tasks as soon as there is free capacity the product owner presents them to the others.

Such planning meetings focus the team on what's up next, what's most important. After the planning meeting the tasks are put on the scrum board. The team should concentrate on getting them done – until the next planning meeting changes the plan :-)

6. Celebration

Once a team starts to really focus it's a good thing to see how things are going. Working your ass off while being highly motivated and focused can be fun – but it's even more fun to have a feeling of what the overall progress is. Are you closing in on the goal? Are you advancing?

To get a sense on how things are moving forward you can put up some kind of diagram. I suggest a burn-up chart (instead of a burn-down chart).

Keep it simple, keep it easy to understand. The most important thing to see on such a chart is with how big steps the endeavor is moving forward.

How close to a goal the team is, is only of secondary interest. The simple reason: the goal probably is moving. So be careful to not instill a false sense of closeness to a goal.

Periodically gather around the burn-up chart and... celebrate. This could be during a daily standup or retrospective. Celebrate the feeling of fluent movement, celebrate your focusedness, celebrate doing the right thing, celebrate your autonomy and your reactivity.

7. Cadence

Commonly it is recommend that planning meetings and approvals should be done at a certain fixed pace, e.g. periodically every two weeks. This is called a sprint.

However I find that sprints can be limiting to the reactivity of a team. That's why I suggest to not start with sprints but only add them if needed. More important than regular planning meetings and regular approvals after many days are immediate demand and focus. That's why cadence through sprints is so far down on my list here.

Also the practice of sprints with a commitment to accomplishing a certain number of stories to me seems distracting from the purpose of Scrum. Scrum is not about fulfilling plans, but about getting important things done.

What's important is ever changing. And plans have no merit of themselves. So to me it's not very important to deliver all planned features at the end of some sprint.

As long as all involved have been working smart and hard as they can and progress can be shown, there is nothing wrong in not fulfilling a sprint's commitment. Which leads to the question: Why commit at all?

I deem sprint planning meetings with much effort in story estimation for predictive purposes a waste. So be careful when you introduce them. At least don't start out with them.

Pre-requisite: Autonomy

To be honest this should be the first step. But then it's not really a Scrum practice. Autonomy is a pre-requisite for Scrum. It's its foundation. Without autonomy or self-organization (and cross-functionality) a team will not be able to reap many benefits from trying Scrum.

So if somebody is considering Scrum for some endeavor he/she needs to understand: first you have to let go of some (or most of) control. Which means cut back on regulations, policies, reports etc. And it means you have to accept some failures – because without failure no learning, no development of an identity as a team.

A group of people should only be called a team if they are actually autonomous in all regards pertaining the problem to solve. Otherwise call the group a group or a heap or whatever, but not a team.

Sure, a team can be given input here and there from the outside. Like a coach shouting from the side line. But other than that a team is working on its own.

This might be hard to accept – but it's a non-negotiable pre-requisite for Scrum. Managers need to back off. But then... this frees them for doing more important stuff like strategic planning. Isn't that a good thing?

Summary

If you're pondering the introduction of Scrum to your organization and don't know where to start... then start at the top of my list. Work you way down from top to bottom. Since retrospectives are at the top, keep checking what works and what don't. Inspect and adapt.

Scrum is about learning, learning organizations which are required to solve problems. Feel free to adapt even Scrum itself. There is no truth except for what works best for you. But Scrum has some valuable suggestions for you in store. Try them out one after the other.

Here's my view of the above practice sequence as a true hierarchy:

Read this from bottom to top: At the bottom are the most fundamental practices/principles. They form layers on which others can rest.

You also can read the pyramids like Maslow's hierarchy of needs: As long as a lower level is missing or compromised, higher levels will not bear fruit. E.g. forget about focus as long as there is no real demand or without coherence there is no use to cadence.

Build your Scrum team from the bottom up. Better do small steps towards change than large strides – and don't even think of sprinting ;-)