Q: Becoming a good ScrumMaster

Q: "What is your advice on becoming a good ScrumMaster?"

A: This is a good and difficult question.  The main difficulty is where to start and how best to express it.

First, what is a good ScrumMaster?  What makes one better than usual?

You may think it odd, but the first thing I want to say is: the team is having more fun.  Why do I say that?  Mainly because more fun will lead to higher business value.  And it leads to a virtuous cycle or circle of cause and effect.

We do not mean silly fun.  Well, it could be silly a bit (as in a quick joke and some stress relief).  But we mean more the 'serious fun.'  People are enjoying their work. They think of work almost as play or fun.  They would almost pay the company to be allowed to do their job.  That kind of fun.

For example, they enjoy working in the Team.  And while they are serious, they often smile and laugh as they work with each other and talk to each other.

Second, more self-organization.

This is hard to explain, I think.  "You make people self-organize" is my joking way of saying it.  It is a joke, because you cannot really make the team self-organize.  But you can, as a SM, coach and advise and set up the right conditions for self-organization.  And then address any people (or other issues) that inhibit it.

You let people be free. Well, yes and no.  You help people to become the best each person and the Team has ever been before.

And you do not inhibit self-organization yourself. (Actually, we all want to control things, and while some control is good, most of us want to control too much.  At least, that is a common problem, even among the well-intentioned.)  You do not 'tell' people to do things, although you might ask 'could you help with X?'  But, gosh darn it, do not act like a 'command-and-control' style project manager. "I have a list of things for all of you to do, and I will be checking the list daily to see what you got done."  Not that. Not even anything close to that.

Still, you might need to explain why they need to have detailed tasks and answer the questions in the Daily Scrum.  And why that is useful for them.  Paradoxically to some, they do need to self-manage themselves rather closely.

Third, more impediments are removed, and the Team is gaining velocity.

You have to aggressively attack the most important impediment. And when that one is 'fixed,' attack the new most important impediment aggressively. So that the velocity of the team easily doubles in no more than 6 months. (OK, some of you are in organizations that really are hard to change, so you will work hard to double in 1 year.)

And then keep on improving!

Fourth, more business value.

What?  That is the SM's responsibility?  Yes, as we have already hinted.  But let us say more.

The SM should be helping the Team get better in every way. The Team of course includes the Product Owner, so the SM is helping the PO get better.

And the goal of the Team, of course, is to maximize the Business Value (in whatever way they define that) from the Team to the Customers. (There is no maximum.)  And release more quickly and frequently.

Obviously, if the velocity increases the BV will increase.  But we really mean more than that.  The SM should be helping the PO learn to do all those things a PO should do to help the Team maximize the BV.  Examples include: clearer requirements, focus on one release at a time, a clear Minimum (minimum!) Market Feature Set (aka Minimum Viable Product), slicing the stories smaller and re-Pareto-izing them, maximizing the feedback to try to improve the odds the customer will really be excited when they get it, maximizing the feedback (see Lean Start-Up) after the release and then 'adjusting' (pivoting, as appropriate), etc, etc.

I do not mean to suggest that the SM does the PO's job. I mean 'only' that the SM helps the PO become a better PO.  And not only the PO.  The ScrumMaster helps all the people (on what we often call 'the business side') to work better with each other so that the BV is maximized more.  And delivered more frequently (which also helps maximize it).

So, at least as general goals, the SM wants to make the Team the best possible team ever.

More specifically, that means:
<ul>
    <li>More fun</li>
    <li>More self-organization</li>
    <li>More velocity</li>
    <li>More business value</li>
</ul>
It is, of course, more blessed to give than to receive, so actually they will start to feel that delivering more business value faster is more fun.

It can be said that 'removing impediments' is the way to make those 4 things happen. Put another way, anything that is holding those things back is an impediment for the Team.  Fix it!

Have we fully answered the question?  No.

&nbsp;

Scrum makes work a game.

You know, of course, that Scrum is named for the Scrum formation in rugby.

More generally, Takeuchi and Nonaka were inspired by the 'rugby' they saw in several great companies and how they did new product innovation.  And Sutherland and Schwaber read that article in HBR: The New New Product Development Game. And that was a key input to creating Scrum.

Here's where we are I think: "Life is hard, life is confusing, and I can never tell if I am making progress. It starts to be no fun, no real people to talk to usefully, no way to see if we are making progress. I am always late and it seem never-ending!"

If some of your colleagues feel that way sometimes, you can imagine that that is: Not Good.

So, Scrum changes it to a 'game.'  It is still real, so not a game in a sense that it is divorced from real life.  But it is, as they say, gamified.

We have a 2 week sprint. We have some defined roles. We put a person on a Team.  We ask the Team (not one person) to be successful.  We suggest that they self-organize and work together (collaborate).

And we allow they to make first downs (as in America football). They get feedback quickly (as in any game)...are they making progress.

Are the measures of progress that we have in Scrum perfect?  Well, actually I think they are very good, but they are not perfect.  But something that is fairly frequent feedback and fairly accurate is far far better than 'nothing.'  Or a couple of 'at-a-boys' that were said half-heartedly.

The key thing is that we have made things 'fun' in a way.  And that feedback is useful for course correction, but perhaps more useful as motivation.

Why?

• we get positive feedback
• we see that other people care
• we can feel proud of ourselves with small wins
• we work together, and it no longer feels lonely
• usually they team starts laughing during the day.  It is fun in that way too.

Let me remind you how games are seductive.  As any behaviorist psychology major can tell you, they give intermittent (positive) feedback.  To be honest, not always positive feedback.  But the positive feedback in intermittent.

And this, according to the research, is key to making the game 'fun.' Now, when they are playing the game, they do not always have a smile on their faces, but still they are engaged, and typically more focused, more 'giving their all' than they usually do working 'in their cube' (as we often see in waterfall).

As with any good game, we need to be able to see frequently, transparently, easily if we are making progress or not.

The managers need to talk about work as a game.  A game we wish to win.

Wide-Band Delphi Estimation for Business Value - 3

This is the third in a series of three.  See part 1 and part 2. ***

How can we use the BV points

We could organize the Product backlog strictly by BVPs, at least initially.

In fact, I recommended this, to see patterns or to make any mistakes obvious.

But I do not recommend doing the work in the order of the BVPs, the story with the most BVPs first.  This is much too simplistic.

The key thing we are missing is cost.  For centuries now, man has talked about the trade-off between costs and benefits.  And in business we have the concept of return on investment.  You invest $1000 (the cost) and get $2000 back (the benefit).

Can we use that concept here?  Yes!

For each story, we can calculate an R factor by dividing the BVPs by the SPs.  This gives us a rough ROI for each story. We could call it CBA (cost benefit analysis, or bang for the buck).

We think this is useful.

By no means does the R factor completely determine the order of the Product Backlog, but one can readily see that following the R Factor could help us maximize the business value per release, other things equal. (Of course, other things are not always equal, but we will not try to address that here, except to say that the Product Owner or others must re-order the Product Backlog some to account for the other things.)

What is the value of a BV Point

Sooner or later someone will ask: What is a BV Point worth?

At first, it is relative, strictly relative.  That is Story X is 50 BVPs, which means it has half the value of the reference story (which has 100 BVPs).

But let's imagine a very simple situation and see what it shows us.

Imagine a product backlog.

Imagine it has a total of 1,000 BVPs across all the stories.

Imagine that we know that the total Product Backlog is worth $2,ooo,ooo.

In that case, we can calculate that each BVP on average is worth $2,000.

You can't cash in your Story cards at the bank for money (based on the BVPs on each one).  You must release and there are MVP or MMFS issues as well, but one can at least feel (fairly accurately) that the BVPs are not just fantasy, but actually a foretelling of a future reality.  Well, if the customer still wants it when we deliver, and if we had good BV estimators.  

Objectivity and Visibility

In our opinion, whatever business value is, it is ultimately in the mind of the customer, and in the future.

So, to us as business people trying to solve a business problem (help people and also not go bankrupt), this seems altogether too subjective.

The BVPs start to make it a more tangible thing.  And this helps.

Whatever number we decide ob is then no longer a 'feeling' inside us (or one of us), but rather a number 'out there' on the story card.

This helps.

It helps in many ways, but let's give one example.

In former days, we would ask two experts for Story X: Is it high, medium or low?  And of course they would both typically say high.  Now, we ask the two experts to vote with cards. One says 21 and the other 89.  We and they can quickly see that one high is not another high.  And they can start to have the famous conversation about how high is high.  We can laugh, but actually this is a useful conversation.

In fact, one of the most valuable things about the numbers is that it makes the conversations better.

Tacit Knowledge

We just gave the example of the more useful conversation that arises.

When they vote, and they disagree significantly (wider than 3 Fibonacci cards), we want the two extremes to talk. Others may talk as well.

What do they talk about? Well, we think it is best to think of this as sharing the Tacit Knowledge.

One definition of tacit knowledge is "all that stuff we know, but we don't even know we know it, and it has not been made explicit it."  And, obviously, this is knowledge that we think is relevant and even useful in a given domain, or to accomplish a given set of work.  Explicit knowledge is knowledge that has been written down or put in a formula.

Do you want a Team to share their tacit knowledge?  Of course! In all the relevant domains.

Is it easy to get them to do so?  NO!  It is extremely hard.  In part because they don't know what they know, and in part because each person doesn't know what the other people are missing.

Priority poker forces them, in a fun way, to share the tacit knowledge.

In my opinion, this is the most valuable thing about the whole exercise.  Not that other things would not justify it.  But the sharing of the tacit knowledge is the single most useful thing.

Helping the Product Owner

Priority poker makes the PO job easier.  And it is a very very hard job, so any help is welcome.

In what way? Without priority poker, the PO had to make tough choices in ordering the Product Backlog.

Let's assume, in former days, that he talked to all the business stakeholder individually.  And they disagreed, of course, on the values of different stories.

So, the PO has to use up his political capital in just saying: This story is #1, this one #2, etc, etc.

This was 'risky' and often there would be some tense conversations. Too often the PO would be wrongly overridden by one or two business stakeholders.

Now, with the priority poker, all the business stakeholder educate each other. (Again I say, bring the popcorn.  This is fun to watch.)

Still sometimes, in relatively rare cases, all 4 of the business stakeholders are being stupid at the same time, and the PO's number will make only a small difference in the average.  And let us assume the PO's number is right.  Only then does the PO have to use political capital to 'move' the story to a more correct BV number or more correct ordering.

This reduction in effort frees the PO to focus his work in other areas.

Overall benefits

I want to reiterate the key overall benefits I mentioned earlier.

• They all see the same elephant (better)
• They all are more motivated
• They all have shared the tacit knowledge

If priority poker is done with the implementers, these benefits accrue to the whole team.  And remember that motivation is not just a 'feel good' thing; higher motivation directly leads to higher productivity from the Team.

I hope you try priority poker soon.  And tell us how it went.  I hope you will tell us how much it helped you.