Getting Started with Scrum

Let's talk about the basic standard patterns in getting started with Scrum. (We have talked about these ideas before, and so have many many coaches and advisors.)

• Start a pilot team

This also means pull together a team with the best possible criteria for success. These criteria are worth reviewing in more detail later. But let's at least mention now that it ought to be a full time team (every member full time), about 7 usually, and dedicated to the full success of only one mission. And the environment around the team should be set up for success (at least as compared to set up for failure). Start only one or two teams at a time. The organization needs to support them. The people (eg, you) and the org can only handle so much change at one time. Once you have the one or two teams going well, maybe add a third.

• Team training

We recommend that the full team be given training together. And that should include key people around the team. They all see each other buying-in to the lean-agile-scrum ideas, or maybe not fully. But they can all see. This makes it much easier for the beginning ScrumMaster, for example.

• Team coach

Everyone (AFAIK) agrees that a team coach is essential. This needs to be a senior agile person, an experienced coach. That person is coaching the whole team and the organization immediately around the team. The person is teaching them Scrum (what they do wrong compared to what they learned in the course), advising, coaching about details, answering all their 'how do I do it exactly?' questions, etc. Both in the team and for people outside the team. There is not much agreement in the Scrum community on how much the coach is there. Some say, for example, full time for one team for 2 months (40 days). Others say 3 days or 2 days at a time for 4 sprints (let's call that 9 days). But, that beginning teams need a coach is understood. Should this coach be internal or external? At first, no one internal is usually ready to be a coach. And at first you need an authority, and an internal person usually does not carry that authority. Later, you need both internal and external coaches. The internal ones help make 'realistic' choices and address 'realistic' problems. The external people keep the internal people 'honest', and keep them from compromising too much. The external people tend to pursue change more aggressively. Always a good thing as long as people are willing to learn through mistakes. Enough for a start?  

Lean Agile Open - April 15th, 2016.

We had a great event in Charlotte yesterday, and I hope you did not miss it. Self-organizing people did the best they could (which is actually a lot) to learn as much as they could with other smart people. About Lean and Agile topics. With, I think, the goals of (a) becoming more effective, and (b) making their own loves, making the lives of their team members, and making the lives of their customers ...better. I don't want the event to sound too goody-goody. We all had fun too. But what I want to emphasize first is: we self-organized. And then: it was good. Thanks to many people! Let me name at least these people: Cassandra Wagner, Riddhi Gupta, Murali Varadarajan, and Bob Petruska. But many others also contributed. What was the value?

1. Senior people at 'waterfall' companies could see that regular people could self-organize.
2. We all saw that we all can help each other.
3. Each of us learned some important things to use back at the ranch to make lean or agile work better at our real work. Each person got to focus his learning where he or she wanted.
4. Most or maybe all of us were 'enlivened.' We felt more hope, more belief that things can change, less alone, more hopeful. We had a sense of a brighter future. This is something that you can never 'buy.'

We did we learn? As I said, we each learned some specific things about specific areas of lean and agile. All good, but not my focus for right now. For some who were new to Open Space, we learned to trust 'open space.' So, I hope we learned to be more courageous next time. As your parents always told you, it is important to trust people. Of course, not to trust too much. But to have some trust, and to be trustworthy. Because more people will have more trust next time, the event will be bigger and better. More people now know how to 'use' Open Space effectively. If we use these events well, this will start to change the community. No man is an island. We are all inter-connected. And we all influence each other. These events, repeated regularly, will change the community. And they can, perhaps more slowly than you may want, change the culture of your company. We will use these events to continue to .... Well, the mundane way to say it is: To get better and better results from lean and agile. But I hope in your heart or stomach (those of you who were there) you feel a stronger energy, an energy you cannot ignore, and that it draws you much more strongly than those simple, mundane words.    

The A3 Approach

In every class, I teach the A3 approach to kaizen.

Kaizen is usually translated into English as 'continuous improvement.' In Scrum that means 'removing impediments.'

The first thing to note is that it is an approach.  It is a method, with certain values and principles, and the fundamentals of the approach are more important than the detailed practices per SE.  But, to make an approach into action, you must have practices.

The A3 approach gets its name from that size of paper (for North American readers, roughly 11 x 17 inches).

The A3 approach wants to fit 'everything' on one sheet of paper.  And make it as concise and as visual, and obvious as possible.  The concept is "if you need more paper, you don't really understand it well enough yet."

Then I must mention team-based interactive 'thinking together' at all the right levels.  So, in context, the Scrum Team is trying to get the manager or managers on board with fixing an impediment.  Usually that means the manager must approve ...
(a) money
(b) people
(c) allowing the change to happen (give permission), or
(d) some combination of the 3 above.

The A3 approach supports multiple formats (eg, different section titles) depending on the situation and the need.

Maybe the next thing to say: The A3 approach is tied with the classic PDCA cycle.  Plan - Do - Check - Act.

The context I am talking about, we want to use an A3 document to get the 'planning and approval' done. First.

After the approval, then Do - Check.  After that, 'act' in the sense or reflect and learn and assess whether it solved the problem.  Or assess, after the fact, "okay, we fixed x amount, but should we fix this problem even more?"  (I am imagining that was only partially mitigated a rather large problem or impediment.)

So, use an A3 document to summarize to managers (or potentially other stakeholders) what we plan to do.  The Scrum Team learns to speak manager-speak. (smile)

The A3 sections I recommend (in addressing impediments) are: Problem, Solution, Benefits, Costs, Action Items, Measures.  They are discussed below.

First, I must say: Use common sense.  I make some suggestions below, but you must use common sense in applying those suggestions to your situation. If you are having questions, be aware that the community has almost surely dealt with a similar situation, and may already have a better suggestion for your specific case.  Again, common sense is very uncommon.
<h4>Problem</h4>
Give a problem statement. Sometimes longer, sometimes fairly short.

Perhaps justify the problem. And explain it, often visually.

Two related questions often from the manager:
* why is this problem important enough for me to address?
* is this our most important problem now? (or high on the list)

When you present, be ready for those. (That does not mean you have to address them visibly in the A3 'report'...just be ready.)

To address the important question, often you are tempted to mention ALL the benefits here (eg, to discuss them verbally as you are making the presentation).  Do not.  At this point, the manager wants just one key number that tells him 'I am not wasting my time in discussing this.'

The second, relative importance, may be easier or harder to address.  I would have to know more about your situation.

Often start with a symptom, and ask the classic 5 Whys to get to the root cause of the problem.

Some problems (and even some root causes) are quite obvious.  So, this can be short. Or it can be a long section 'selling the problem.'

Many managers know from experience: often we have a solution looking for a problem.  So, they know that identifying the problem well is often half the issue.  The Lean community and lots of others give you plenty of tools to identify and assess the problem.

The manager may well follow-up with....'why do I believe you have identified the correct root cause?'  Or similar questions.  You may need to have done 'root cause analysis' or the 5 Whys or something similar.
<h4>Solution</h4>
Here you describe the solution you are proposing.  Fairly succinctly.  Perhaps visually.

You might talk about why you chose Solution X over Solution Y.

Often the question is: why do I believe this solution will really fix the problem (root cause) identified?

As suggested earlier, people have two problems in this section of the A3:
(a) the connection between the problem and the solution is just weak. Period. (Human nature I think is the culprit.)
(b) it is hard to quickly and simply <span style="text-decoration: underline;">show</span> the connection between the problem and the solution.

If you only have a partial solution (very common), say so.  And explain, briefly, why you think this solution should be implemented before other possible solutions to the 'bigger problem.'

Again, make the solution as visual as possible.  KISS (Keep It Stupid Simple) for the managers.
<h4>Benefits</h4>
Address all the benefits of the solution.  Both tangible and intangible.

Often it helps to express these as money estimates.  Expect the managers to question your estimates.  Estimates of the future are never perfect, so expect them to revise your estimates.

Try to express your estimates as improvements in velocity, such that we get extra BV delivered in the same time period (say, year).  Usually BV is some multiple of the cost of the Team (say, 3X).  So, the benefits are larger if you see them that way.  If you look at the benefits as only cost reduction, then the benefits are much less.
<h4>Costs</h4>
These are both the tangible and intangible costs.  As broadly defined.

Consider all the costs for 'everyone.'  There might be some debate about what 'everyone' and 'all' includes.

It is classic to have two types of cost: (a) one-time costs, often called 'initial costs' and (b) on-going costs (costs over some future time period).

Again, a manager typically wants all of these expressed 'apples-to-apples' with the benefits. Dollars to dollars makes it clear and simple to the manager (although seldom simple for you).

Again, make estimates of the future, which are always 'rough and ready.'  Expect the managers to question them, and perhaps even revise them.

And the benefits need to be a high multiple of the costs (I recommend 6x, but this varies by the situation, etc).

You may not write this down, but at least consider the personal cost to the manager.  There are many types of personal cost, but one might be political risk, or who he has to explain this to, or 'will I get fired if this goes south?'  Be ready to address these in the discussion.

When discussing costs, the managers will often ask questions like:
* who has to be involved
* how much time is involved
* which other efforts must be delayed if we do this (aka opportunity cost)

In this section we also want to address risk.  Reduction of risk may be addressed in Benefits, but any concerns about increased risk (for any important person) should be considered here.

ROI Ratio: Make very clear and visible the ratio between benefits and costs.  That ratio needs to pass a 'hurdle rate' to be approved.  I suggested 6X above.  Not every firm uses the term 'hurdle rate,' but almost all firms have the concept.  The benefits must be at least X times higher than the costs.

Why? Almost always there are plenty of good things to do. The manager needs the ROI to be high enough to justify executing your proposal versus other (not quite as good) proposals.  We can't do all the 'good' proposals.
<h4>Action Items</h4>
This section can be phrased other ways.  'Next Steps' is a common alternative title.  And it can have different purposes.

But usually the manager wants to know: "If I approve this, what will you do next?"

Maybe the manager wants you to check it out with X or Y or Z person or group.  Maybe he wants to know when it will be done.  Maybe he just wants to know that you have 'a plan that has been thought through, which suggests a high likelihood of successful implementation.' In that case, you might summarize the key steps in 'the plan.'

Some people think this section requires a very detailed project plan.  Almost always: No!  Almost always that is too much information for the manager.  Maybe she would want to know that you had planned this out at some moderate level of detail, though.  (Not to see the detail, just to know that your team has done it.)

Often you are addressing a semi-latent concern, such as: "The last time we did something like this, X (a bad thing) happened. How do I know X won't happen again?"  You might address that concern in this section.
<h4>Measures</h4>
This is a very important section, both in practice and also concept.  Often, even for managers, this is <span style="text-decoration: underline;">new</span> in concept.

In this section you propose how you will measure, after the fact, that the implemented solution turned out to have the success expected.  In this way, after implementation we will close the P-D-C-A loop.

This 'learning after the fact' is vital. In this way you become better and better at solving problems, or as we call it in Scrum: fixing impediments.

In the context of getting the manager to say yes, it has two benefits.  One, the manager is impressed that you thought the measures through. And guesses that if we actually measure X and Y and Z (however many things you propose measuring), that you and your team will surely do a lot better job in executing, since you will be measured later. And if execution is better, then success is more likely.

Two, the manager can also see that if the measures start soon, and if the measures show this proposal going 'south', then the manager can mitigate his risk by stopping the implementation quickly.  Before his boss finds out that 'it did not work out well.'

***

I spent most of the time discussing the A3 document, because that is essential to implementing a basic A3 approach.

One of the key ideas behind A3 is: "Things should be as simple as possible, and not simpler."  (Einstein)  Since we are agile people, maybe the Ward Cunningham version is better: "Try the simplest thing that could possibly work, and then test."  (Ward complains that people often forget the '...that could possibly work' phrase.)

In other words, do not make the A3 document more complex than it needs to be. But do not make it too simple, either.

Related to that, the A3 is a focus for collaboration in solving problems.  The purpose is to work together and become better.  The purposes are not (to pick some bad examples): fight endlessly, CYA, grandstanding, to nit-pick, analysis paralysis, hide the truth (by saying too little), or, hide the truth (by saying too much).

Enough for today.

For more background on the A3 approach, there are many many resources on the internet.  Here is <a href="http://asq.org/conferences/six-sigma/2009/pdf/proceedings/c6.pdf">one.</a>  A good slide deck. If you get into it, you may notice that the A3 approach is used in many, very diverse situations.  So, the 'culture' around it is rich and complex.  But the basics are very simple.  I recommend KISS at first.

Enjoy!

PS. Thanks to Jeff Sutherland and Mary Poppendieck, who got me 'into the A3' many years ago.

&nbsp;