Tag Archives: Scrum Master

Refactoring the release plan

Posted on by
Reply

At the end of the last post, we had complete the initial release plan.
What were the key outcomes?

[This is one in a series of posts about release planning. See here.]

Well, the plan had some sort of scope, date and budget. Usually on Day zero the quality is ‘crappy’ to use the technical term. As it must be, given how much we don’t know on Day zero.

The real win was that we now have ‘everyone’ on the same page, at a useful middle level of detail: what is this elephant?  What are we about to do…

And then we start the first sprint.  Or more specifically, we start the first Sprint Planning Meeting.

But that is not really the end of release planning. But the beginning of RPR (release plan refactoring).

It is absolutely fundamental to agile release planning that we refactor the release plan frequently. I say (and many others that I greatly respect say) that we must refactor the release plan every sprint. Every sprint.  Ok, maybe during every 10th sprint there will be so little change, that we don’t have to change the release plan at all.  Ok, maybe this very occasionally happens. But at least we must evaluate that that is the case.

Now, when I say release plan refactoring, I mean all of the following:

* changing the vision (all of these are ‘if needed’)
* improving the product backlog items (more, fewer, smaller, better)
* re-evaluating business value (very key and very hard)
* Re-estimating the effort (eg, where Story Points are wrong, for new stories, for newly sliced stories, etc.)
* taking a new look at the benefit-cost ratios
* including new learning about risks, dependencies, learning, MMFS, etc.
* re-ordering the work
* doing a new scope-date trade-off.  Usually to make the initial release smaller (fewer aggregate story points — is one way of expressing it).
* including the newest velocity expectations (based on recent trends).
* adjusting the buffers and communicating the new, new release plan (scope, date, budget) to the right people

Now, I also include in Release Plan Refactoring all the changes to the Product Backlog information to make it ready for the Team to be successful in doing the Sprint work.  Some people use phrases such as ‘product backlog grooming’ for this. (Note: I think ‘product backlog grooming’ can have other meanings too, depending on who is using the phrase.)

These activities include:
* breaking down stories or epics into small sprint-sized stories.
* improving the stories or PBIs (wording, INVEST criteria, etc.)
* estimating the business value of the smaller stories
* estimating the effort of the smaller stories
* answering questions from the Team about the expected sprint stories
* adding detail (notes, acceptance criteria, etc.)
* adding an agile spec for each PBI to be in the next sprint.  [Sometimes this may be done 2 sprints or more ahead. But not 'way' ahead.]
* checking that the Team thinks each story (likely to go in the next sprint) is ‘ready’ before the Sprint Planning Meeting

One could argue that release plan refactoring and product backlog grooming are completely different.  I think this way of thinking is unhelpful.  One of the purposes of release planning is to make the work in the sprints more successful. Release planning is not completed until, for each sprint planning meeting, we have ‘the stuff’ ready for a successful sprint planning meeting. Among the key success criteria of that meeting is: we used the time of the business stakeholders well.

Let me pause.

Why is using the time of the business stakeholders important?

Well, they are the key independent check on the thinking of the Product Owner.  We know from long experience in our industry that ‘knowing what the customer wants’ is extremely hard. Extremely. The business stakeholders are people whose time is scarce and yet these people are essential to us in getting a much better fix on what the customer really wants (or what the firm wants).  We want them in the Sprint Planning Meeting, agreeing with what the Team takes in and, at the Sprint Review, giving us feedback.  Because these independent input and output checks are so vital, we must use their time efficiently.

Thus, for me it is better to think of higher level release plan refactoring and lower level release plan refactoring. And when people say ‘product backlog grooming’ they often mean lower level release plan refactoring of those stories about to go into the next sprint.

Again, the key idea here is that we ALWAYS refactor the release plan every sprint.  We improve it.  This is absolutely key to adaptive planning.

Why our CSM (Scrum) course + Workshop is unique.

Posted on by

We believe our CSM (Scrum) course plus Workshop is unique.  And better.  For the following reasons.

1. We focus on results. We want you, your team and your customers to get real results. In a big way.  In 3 words, more satisfaction, more money, more fun.

2. Therefore the teaching style is not toward remembering explicit knowledge.  The teaching style is to enable you to change your own mind, so that you want to take action.

3. We focus more on ‘why’ each Scrum practice is done.  We think that this ‘music’ makes the dance steps of Scrum more powerful, more effective.

4. We have learned from 8 co-trainings with Jeff Sutherland.

5. We are more business-oriented than most Scrum trainers.  And still protective of the Team being asked to do a Death March and yet call it Scrum.

5. While we offer some serious challenges, and ask you to challenge yourselves and your company to truly achieve the results you deserve, we are also realistic.  We appreciate that Scrum will be tough. We offer sympathy.  But not too much.

6. Attendees say the Workshop converts the ideas of the course into action. So that the Team can get off to a good start.

John Kotter Explains the 8 Steps to Create Successful Change

Posted on by

Here is a slide show and voice over by John Kotter (our big expert on change) talking about how to get organizations to change.  Watch and listen here.  About 7 minutes.

Of course, your organization is smarter about change than John Kotter, so your colleagues do not need to see this.  (smile…I might have been sarcastic.)

In fact, my premise is that no organization is professional about introducing ‘different’ changes within the organization.  (Example: I don’t know Apple well.  I am impressed by how much their products have changed things. But I am far less confident about how well Apple itself has changed internally. Still, maybe they are the exception that proves my point. As a small example so far, they seemed to have adapted well to the new leader. Oh yeah, Tim Cook is his name.)

Taking Ideas on a Test Drive

Posted on by

I am a strong proponent of “show me the money.”

In other words, there are lots and lots of ideas that sound good. And only a relative few that are really worthwhile. And we only know by trying to put the idea into action.

But even this basic scientific idea is not complete. I would agree that not all ideas are subject to proof in a scientific way. Even though scientifically it might be proven that murder were ‘correct’, morally I still am going to think true murder is wrong.  (No, Virginia, we are not going to have a debate on all the possible situation and moral permutations of killing a person.)

Here is a WSJ article about a new book, Uncontrolled by Jim Manzi.  Haven’t bough the book yet, but the article makes it sound interesting.

And this is what lean-agile-scrum does. We try to do a series of small semi-controlled experiments.  To see if we are really on the right course.

If you have a problem reaching the WSJ article, contact me and perhaps I can send it to you.

A list summarizing Scrum

Posted on by

Revised May 6, 2012.

***
The list below is not self-explanatory, but it covers the key ideas one has to know and execute on to do Scrum professionally.  Of course, becoming proficient at doing them at the highest level (at the rugby World Cup level) is a lifetime’s work.  Rugby is a simple game with simple rules, but to reach the highest level of play is very difficult.

This list could be used as a starting point for defining ‘agile’ or ‘scrum’ in your firm. I am suggesting such a definition could drive useful conversations.  And it fits on one page (a key criterion).

A list that summarizes what Scrum is:

Roles:
Product Owner
ScrumMaster
Implementor (‘Dev Team’ role)

Events:
Sprint – 4 weeks or less.
Sprint Planning Meeting
Daily Scrum
Sprint Review
Sprint Retrospective

Scrum Artifacts:
Product Backlog
Product Backlog Items
Sprint Backlog
Working Product
Increment (of working product)
[Sprint Burndown chart]
[Release Burndown chart]
Definition of Done
[Public Impediment List]

Key Ideas:
Scrum is a process framework
Deliver business value faster
The Product Owner is maximizing the value delivered by the Team
Inspect & Adapt
Transparency
Self-organizing
7 plus/minus 2
Build iteratively and incrementally
Working product at the end of each Sprint
Potentially shippable product increment
Need for feedback
Always learning
Always adapting to good and bad change
Usefulness of high quality
Scrum hates technical debt
Knowing work remaining in a Sprint (daily)
Knowing work remaining in a Release (every Sprint)
Protecting the implementers from disruptions
Protecting the implementers from the Death March
The ScrumMaster drives the removal of impediments
Must add other practices (e.g., engineering practices) to Scrum to do work
Scrum does not include agile release planning (but you probably need it)
Scrum is consistent with the Agile Manifesto and Agile Principles
The Team should be having more fun (and be more creative)
Sprint Planning Meeting, parts 1 & 2.
The Product Owner orders the work in the PB; the implementers decide how much they can do in a Sprint.
Sprint Goal
Sprint “commitment”
The 3 Daily Scrum questions
Purpose of Daily Scrum: self-management
Demo working product & get feedback
Servant leadership
Chickens can help
Just-enough, just-in-time, documentation

***

Your comments please.

Here is the file: http://agileconsortium.pbworks.com/w/page/53405031/List%20summarizing%20Scrum

Agile’s broad adoption and mediocrity – what to do

Posted on by

Ken Judy has an excellent, although blunt, blog post here:

http://judykat.com/ken-judy/agilescrumlean-broad-adoption-mediocrity-faul/

His main point maybe is that we do not have enough truly professional scrum (or agile) implementations.

And why? Because we have implemented too broadly too fast.  Is probably the main reason, in his opinion.

Some good insights.  Read them.

***

Here are my related thoughts.

The potential of a team using Scrum is enormous. And I don’t think any team, ever, reaches their full potential.  In any sport, including what we call Scrum.

It is fair to say that most teams barely scratch the surface of their potential.  They get a 20% improvement when they could easily have gotten 100%.  And eventually get 5x – 10x.

Why?  Some root causes…

1. Reliance on “Scrum”: Too many teams have a ‘sit back’ attitude and expect Scrum magically to do all the work. And it is amazing what Scrum alone can do.  But it really takes an active, purposeful, spirited team to get real success.

2. Better Product Owner. Scrum will not magically make George (a really smart guy in your firm) a good product owner.  In fact, all Scrum does is make us assign him that title, and then gives us lots of ways to observe, if we will, that he sucks at the job. Hopefully, someone sees the problem and fixes it.  It really really helps to have a really really good PO.

3. No real Team. The people don’t feel they are a real Team. And no one knows how to form a real team. (Lots of explicit and tacit knowledge in doing that.  We will talk about that later.)

4. Not attacking impediments. One of the most powerful things in Scrum is that single-piece flow of attacking one impediment at a time.  The Scrum team is not aggressive enough in doing this. Or the company does not support it meaningfully.

5. Better Engineering Practices. When switching to agile, a team needs to move to more agile engineering practices. No, not for the silly reason that agile is in the name. Because the agile engineering practices are more effective. Probably more effective even if doing waterfall, but certainly when doing agile. SCM, automated build, CI, automated UT, automated functional tests, faster regression testing, etc, etc.

6. Scrum-Butt and Unprofessional Scrum.  Do you think the NY Giants should have fired all their coaches in Sept 2011?  Me neither.  Yet, somehow, many people magically expect that all a team needs is one 2-day course, and then they can play Scrum professionally.  Remember that at the beginning of September, every player on the Giants team has been playing football for years. At what you and I would call a professional level (college is virtually professional in many way). They are not beginners in the sport, and they need further coaching. Further training.

And we think people who are beginners at Scrum need only a 2 day course?  C’mon. They need a lot more. Now, of course it has to be reasonable compared to the value. If you need help with that math, I can help.

Related, but a bit different, is how beginners (or beginning firms) are so sure they are smarter than the Scrum community, which now has many centuries of experience with Scrum.  So, they change Scrum (‘we are special,’ they sometimes say). They do Scrum, but people on more than one team. They do Scrum, but they do the Daily Scrum twice a week. They do Scrum, but they don’t have working software at the end of every Sprint.  Etc. Etc.

***
There are other reasons.  Many more.

We need more teams playing Scrum professionally, and showing others how it really ought to be done.

Release Planning: Business Value

Posted on by

Now we move on to Business Value in Release Planning.

For those who have not been reading before, this is a continuation of a series that starts here.

Per Yogi Berra: “You have to be very careful if you don’t know where you’re going, because you might not get there.”

If you are in the mood, this can be very funny.  Or just a chuckle.  But this is our problem. How do we identify what the customer really really wants.  Well, business value is part of that.

When we did the vision, we directly or indirectly probably talk ed about business value.

Now we want to talk about business value for each individual PBI (product backlog item) or user story.

Again, we want to have two actions within this.

People: Again, to do this work, I want the whole team of pigs (PO, SM, implementers) and the BSHs (business stakeholders).  Again, the BSHs are the best people we can get to attend Release Planning to represent the customers and the firm well.

Business Drivers:  It is my contention that the key thoughts and phrases we want to use about business value vary by the situation. The product, the customers, the people involved.  It may be that the high-level basics of business value for all for-profit firms could be distilled into 5 phrases. But I find for useful discussions in specific products, it helps to ‘invent’ the 3-7 top drivers each time.

Business drivers may include making money, risk, customer satisfaction and lots of other things. Or not.

So, they whole group gets together and discusses and agrees on the top 5 (about) business drivers that apply to the set of work (the product) as represented in the existing Product Backlog (its PBIs).  Sometimes this will lead to the identification of some new stories (or PBIs).

Priority Poker: Most of you are familiar with Planning Poker, which is where we use the planning poker cards to vote as a team on the relative story points of [new story] compared to the 1 SP on the [reference story].

Priority Poker is very similar to Planning Poker, except that it is about business value, not effort.  In fact, we assume there is no correlation between effort and value.

So, the similarities: use a team, vote, use Fibonacci cards, discuss assumptions, share knowledge and ideas, average the numbers after reaching some consensus, the number is comparative, relatively quick, somewhat imprecise for each individual card but fairly accurate over a set of cards, etc.

Some differences: a different team (the experts on business value), reference story is the TOP story (for business value) rather than the SMALLEST story (for effort), prefer the real Fibonacci sequence at the top end, done in the presence of the implementers, etc.

So, first the top experts (usually between 4 and 7 people) on business value huddle around the user stories (or PBIs) and determine which one has the most business value.  This one is arbitrarily given a value of 90 or 100 (it is minor which one you choose).

The Business Value experts are typically the PO, the BSHs and maybe one member of the Team who has a lot of experience with customers. Or for some other reason, knows BV pretty well.

OK, now we have the reference story for Business Value. Then the BV experts start to add relative BVP (business value points) to each user story (or PBI).

Here are the rules:
* pick a story randomly (we do not want to prejudice the panel by already putting stories in BV order).
* discuss the story
* identify drivers of BV for that story (but not how much the driver is affected)
* ask each person to pick a Fibonacci card, but don’t reveal the vote to anyone
* once everyone has selected a card, 1-2-3, they all reveal the card
* the people with the two extreme cards discuss why each was high or low
* the team re-votes until within 3 consecutive Fibonacci cards of each other
* then the averages the numbers, to the nearest integer.

Example: The vote is 34, 55, 55, 89. The value for that story is 58.

Meaning: If the reference story is 100, and they vote 50, that means that they feel that the new story has 1/2 the business value of the reference story, considering all the different drivers of business value.

The others listening (the non-voters) may ask questions at the end of each “card.”  The purpose for them being there is so they can pick up the tacit knowledge about business value, and which stories are more important (and why).

Final review: Once all the cards have been assigned BVP (business value points), the experts then gather around all the cards on the wall, and look for “the stupidest” numbers. Often in 50 cards, they will identify 3 or 4 that seem stupid now.  Maybe this 30 seems a lot bigger than the other 30′s.  Maybe that 70 seems too high now.  The person identifying can ask the experts to re-vote.  In general, we would expect them to re-vote on a few. After all, now that they have discussed them all, they are probably smarter now about business value than when they started.

Timing: Priority Poker takes some time, but is worth it.  Understanding Business Value is very, well, valuable.  Of course, one person in your group may talk too much.  So, the facilitator must monitor that.

We find a time box of 1.5 to 3 hours is usually quite sufficient for 50 cards.  But again, if the discussion is deemed valuable by most of the participants, it is unlikely that 4 hours would be too long.

Comments:
We like them to think more and more that no two things have exactly the same business value.  Yes, for example, we may have to do 5 steps in a business process, but steps 2 and 5 are exciting.  The others are just chores that must happen. Steps 2 and 5, when we deliver them to the business and deliver them well, that’s when the big smiles come out.  Or that’s when the big money is made.

Often new stories are identified. Or a few existing stories are deemed so big, that they must be sliced and diced into smaller stories.  This is normal.

Sometimes an expert may feel he does not know how to vote on a specific story. He should take his best guess anyway. And learn from how the others vote.

Averaging: Apparently there are many who have been taught Planning Poker and told to force the team to consensus on one Fibonacci card. This is incorrect for Planning Poker.  The research shows that averaging is more accurate and faster. (If not too fast.)  And the same applies to Priority Poker.

Accuracy: Are all the cards perfectly accurately assigned BVP?  No!
Have we learned a lot more about our different ideas about business value and shared that throughout the group?  Yes!
Did the numbers help? Yes!
Can we change the BVPs later, once someone becomes ‘sure’ that one or more is wrong?  Of course, by team vote.
Will we change some? I absolutely expect it. We want you to get smarter and smarter about business value, in multiple ways. This should in part be reflected in changes to the BV points.

Epics: If an epic is worth 100 BVP, does that mean that when it is broken into 5 stories, then each of the 5 is worth 20 BVP?  No, we don’t assume that. In fact, along with Pareto, we assume that there are more vital parts of the 100 story, as well as less vital parts.  In the simplest world, one of the smaller stories would be worth 80 BVP and the other 4 stories would total 20 BVP together (the 80-20 rules).  But life is not always that simple, either.

***

Results: One clear result is that we have a BVP number on every PBI (or user story).  This is remarkable.  And no one in the group thinks any of the numbers totally suck.

More importantly (IMHO), the whole team starts to share a bunch of ideas about how the BV is distributed amongst the features.  Every feature is not equal.  This is a great thing.

Typically new stories are identified. And typically the MMFS (minimum marketable feature set) is starting to emerge.

But the main thing, to me, is that the whole group starts to share relatively specific tacit knowledge about the relative business value of each story.  Specific down to the user story.  Not hand waving at the vision level.

This work changes motivation. And it changes the behavior. Of everyone.  The business guys start to respect that the geeks understand them a little. And the geeks now understand better why business-side work is so hard.

***
The real value of all this work is getting closer.  And will be revealed soon.  Just a few more steps….

Release Planning: Product Backlog

Posted on by

After we complete the Vision, we must develop the Product Backlog. (Please go to this post for an overview of what I think Release Planning includes.)

There are two parts to this.

First, we must define the Roles to use in the User Stories.
Second, we must write User Stories.  I call this second part a User Story Workshop.

Let’s break this down.

Assumption:  We have a new team that is doing Agile-Scrum for the first time.

Who: We want the whole team of pigs (PO, SM, and implementers). And the BSHs (business stakeholders).  Usually you want the 3-5 best business stakeholders you can get.  They are never perfect, but at least they are the best you can get. The Product Owner is usually the main person driving which BSHs to bring in.

The Product Owner is leading the content. The ScrumMaster is leading the facilitation.

What: We want about 5 to 7 roles. These are the roles to go in the User Stories.

And then we often want about six months of work for some good release planning.  (In some situations, we want more or less work.)

If we want about 6 months of work, lets do some math.  My rule of thumb is 8 stories per 2 week Sprint.  6 months work is 13 sprints.  13 x 8 = 104.  Now, those stories are all small enough for a Sprint. So, in Release Planning, we can be pretty happy with 50 stories (average about twice as big as a Sprint-sized story).  So, this gives us a rough idea of what we are shooting for.  Of course, we will learn a lot later, and can make many adjustments.

So, we only need about 50 stories that cover about 6 months worth of work.

How: Brainstorming to get 5-7 roles can be easy or can be hard.

We mostly want different user types (roles), end users of the system or product. But more generally, we want any role that would want some feature in the product.  Even if they don’t (directly) use the product.

(Note: These are not the roles of the Scrum team members. A fairly common question.)

Some teams will come up with 30 roles. Some will come up with only 2. We want to either synthesize or break down until the number of roles gets in the 5-7 range. Something magic about that number. But not worth dying for.

Whatever they do, it will probably work the first time. But it will become better as they start to get practice with stories, and appreciate, tacitly, the characteristics of a good story.

OK.  Now, with the Roles, the whole team starts to write stories. We let them self-organize.  We give them 15 minute timeboxes.  At each 15 minute break, they “check in.”  They inspect progress and see if they want to adjust anything. Usually they see that they want to write stories faster.

Typical productivity for a team is to average about 1 story per minute.  So, in about 50 minutes…..50 stories.

When they feel finished, we recommend having the whole team gather around all the stories (imagine them on a wall).  They should look at them, and try to see what needs improving the most.  Maybe a few aren’t worded well.  Maybe a few need the INVEST criteria a bit tighter.  Maybe two team members identify 3 missing stories.

What were the INVEST criteria?
* Independent (we try to maximize this, but we never can make all stories independent)
* Negotiable
* Valuable
* Estimable (clear enough that we feel effort can be estimated)
* Sized Appropriately
* Testable

It is sometimes useful to get more sophisticated.  I don’t like to do that the first time.  They need to get one cycle of just doing the basics.  Probably several cycles.

We recommend that the PO answer questions and talk about the product that he envisions. But let the others identify the specific stories.  He gets them more engaged. They get more creative. They have better motivation.The PO can always add or modify later (if there work is imperfect).

Why?

Why do we have all the pigs and the business stakeholders?
Several reasons I will mention.

1. We want the whole group to share whatever tacit knowledge they have with the rest of the group.

It turns out that everyone has some knowledge or ideas to share. Or at least some good questions. Well, almost everyone (yes, there are a few exceptions sometimes on this one.)

2. We want the group to create knowledge together.  And share it together.

A bunch of things happen has they create knowledge. One is that they all start to form a similar mental picture (or pictures) of the product and the effort and things related to it (eg, the architecture).

3. We want the team to develop motivation together.

Finally, having been involved in the creation, the whole thing becomes their ‘baby.’  This is far better motivation than we get from ‘the mushroom treatment,’ which is de facto the most common thing. (The mushroom treatment is where the team is kept in the dark and fed manure — this is great for growing mushrooms, not so great for growing teams.)

Yes, it is somewhat expensive to have everyone involved.  But the payback during the project is very high.  Very high. And the time to market is better.

Time Box: As indicated, I like to have a series of 15 minute timeboxes, where the team checks in. Are we going too fast or too slow?  Anything we should change? Who is talking too much, who too little?

Usually the whole thing can be done is 60-90 minutes.  But really it is not a problem if it goes 120 minutes. Or even more. The main thing is, as SM, if one guy gets talking and worrying, and nothing is getting done, you can’t let the team just spin.  Someone must fix it, and get them productive again.

Common Issues:  I like brainstorming rules. Meaning: Anyone can create anything, and for this timebox (say, 15 mintes), no critique is allowed. Then an editing or ‘fixing’ timebox, where the team reviews and improves the roles or stories.  Then another ‘create anything’ timebox. And so on.

I find creating one story and then criticizing each one is too slow, and inhibits the team too much. Especially beginning teams.

Another issue is having only one person write the stories. If a team really wants to do this, it is not terrible. But things usually go faster if everyone writes.

Not sharing. I think it is useful if, as a person writes a story, he shares it with the group (says the words of the story out loud). That way, no one writes the same story a second time.

Top Down/Bottom Up.  I find some people are top down thinkers and other are bottom up thinkers. It takes both kinds. Let them be who they are. Especially while they create.  Rather obviously, top down thinkers will tend to write epics that need to be broken down (even at this point we can often see some epics are just too big).  And bottom up guys will write stories that sometimes are too small.  And we sooner or later need to combine stories.

User Story format. I like it and encourage it. They especially tend to forget the “so that” clause. So I encourage them to include it. But, if they just can’t think of the feature in a user story format, I say: ok, just write something as a PBI (product backlog item). Maybe later we will convert that into user story format.  Be easy on the beginners. They are just learning to ride the bike.

Results.  Usually the team ends up with 40-60 stories that represent 5-7 months worth of work. Ballpark.  (It is just a gut feel at this point.)  Which is a great start for the Release Planning.

These user stories (or PBIs) are just the right middle level of ‘features’ for everyone to have a clear enough picture of what the product will be. It embodies the vision. It makes things concrete for people, without getting mired in details. Wonderful.  And they can do this the first time.

Is it perfect? No. Could it ever be perfect? No. Is it a reasonable time to spend to get a level of ‘quality’ (in all aspects) that it very useful?  Yes!

Can we write more stories, if we discover them, later in Release Planning? Yes! And it always happens! And will we add more stories as we are doing the Sprint? Yes, always.

Public Impediment List – Again

Posted on by

I wrote the following post to a Scrum group. Perhaps you will find it interesting. It is lightly edited. And it is in response to another person’s post.

***
Let’s talk about the impediment list more.

Along the way I will mention some of the problems I see in real life.

I find that most ScrumMasters don’t have a list. Even in their head. And it leads to a low level of activity (bordering on none, much too often) in removing impediments.  One example of what they typically should have: We need better engineering practices (add XP things, one at a time).

I agree of course that not every impediment can be put on the list.

In Scrum we are working both with and against human nature. Yes, I agree it is human nature to want to hide. And yes we need transparency to be better.  So, the solution is some common sense. More transparency, but we have to be reasonable.

So, a public impediment list, but we don’t show the one that goes ‘George picks his nose in the team room’ or whatever example you want to use.

Yes, managers don’t want to see a list of ‘bitches and moans’.  They don’t want people saying ‘your kids are ugly’, …meaning: If I as a manager put in place Process X, I don’t like it when some team calls it an impediment.  Again, some common sense….  But in general, more public, please. The more mature the firm, the more public.

Next problem I see: (expressed in this metaphor)  There is a table with rolling wheels under it. And beside the table a movable wall, also on wheels.  You and I would say they are both impediments. I see far too many teams not even identifying them as impediments (the table and wall in my metaphor). When shown them, they say: Well, it would be impossible to (re)move them. We point out the wheels. They say: Well, still impossible. Only when we actually move them ourselves, does something happen.  Weird, but oh so true.

More broadly: They (the whole team) are not creative enough in identifying impediments. By making the list public, we can start to get more creativity.  Or at least see weaknesses in the list.  This is not anyone’s fault.  It is just human nature. The pains you are used to no longer feel painful.  But we after overcome human nature (or parts of it).

Pareto: As with any work, there are a few items with the real juice, and lots and lots of relatively minor things. We must Pareto-ize the list. Prioritize it; order it.  Just like the Product Backlog.  But we need a good list first.

Ordered. Yes. There are dependencies in implementing better engineering practices. For example. These need to be shown in the ordering.

Social Contract: the Impediment List is like a social contract.  I will say, at this moment, between the firm and the team. The firm agrees to fix, within some reasonable constraints, the top item on the list.  And then the next top item.  And so on.  (The firm is investing in the SM to drive this.)  The team agrees to stop bitching and moaning about all the other stuff, and get some work done.  It’s a much more functional deal than we had before.

Listened. We need the list public so each member of the team knows they were listened to.  Only if they see ‘their baby’ on the list, do they know it even got on the list.

Discuss and clarify value.  We need the list public so that each person can see where ‘their baby’ was ordered. And can bitch and moan some more if a stupid SM does not understand HOW important their thing is.  (Sometimes the SM needs a bit of educating.  Who knew SMs did not know everything!?!?)  I won’t add how it affects the motivation of the whole team to see the ordering of the whole list…you can figure that out.

If there is a list, and the SM owns it, is he likely to focus more or less on that top item if the list is public?  I am thinking that visual management principles suggest that the distracted SM is likely to have a tad, just a tad, more focus if the list is public. (Ok, sorry if the sarcasm was a bit too thick. It helps, one hopes, fight through our rationalizations, and we all do that. So the sarcasm is directed at me as much as anyone else.)

Those are my main arguments for a (mostly) public impediment list.

Of course, if by magic always the top impediment is being removed and everyone is otherwise completely happy, then I am a practical guy. If life could not get more wonderful, screw the impediment list. In fact, let’s forget about scrum.

But as you suggested, I don’t think human nature in the wild has evolved that far.

Now, as a tease, I will say that I am shocked, shocked that you don’t want to be completely transparent.  Does that mean that we should remove the transparency idea from Scrum?

One final comment: I say, agreeing with you I think, that the impediment list never ends.  Since nothing we do is ever perfect, everything everywhere always needs to be fixed (improved). So there is an endless job for the SM. In fact, most Super Bowl winners can’t even repeat the next year. So, yes, it is a hard job, daunting, and it takes courage. But that is just the truth. I could lie to you, and say life’s a beach and growing old is completely easy.  Would that help?  Sufficient unto the day is the top impediment thereof. Just work on that one.  That is not so daunting.

So, after maybe 20 items on the list, I am not sure we need a longer working list. Then order the 20 or so items. As some are fixed, add more items to the list.

Now, to me an implication your ‘daunting’ concern is that we need some way to measure progress on the impediments. And I completely agree. Most mere mortals need some encouragement. And at least looking back, sometimes, at all the impediments thrown out of the path is satisfying and reassuring.  There could be other ways too….but we need to start with a (mostly) public impediment list.

I await your comments (and others’ too).

Thanks,
Joe

What cocktail parties teach us

Posted on by

This is the title of an article today in the Wall Street Journal.  The subhead is:

Brain Is Wired to Focus on Just One Thing; Which Tasks Are Easier to Combine

It’s all about how we humans are built to focus. Multi-tasking is, well, inhuman.  A few monkeys pretend, but we lose all effectiveness.

See this.  I am a “member” so it may not work for you.  I can email it to you, if you want. (But ‘you’ can’t be too many people.)

Scrum tries hard to help the team focus. And not be interrupted.

I usually like cocktail parties anyway.  Now more.