Sample Impediments (RUD)

Just did a course in Raleigh-Durham.  Here are some impediments the group identified….

Lack of people
Turnover in staff
Unclear scope
Requirements changing too much
Cutting corners
Lack of communication with customer
Bureaucracy – pessimistic stakeholders
Poor morale
Manage by fear
Budget (insufficient)
Lack of visibility
Lack of management skill
Dependencies (other projects)
Traceability (lack of)
External risks
Lack of direction

 During the course one person frequently mention CI (or lack of good continuous integration).

How does this list match with your public impediment list?

(Note: The above list was not for one team, but for multiple teams over multiple years.)

Managing self-organizing teams

How do we suggest that managers ...well... manage self-organizing teams?  By self-organizing, we also mean self-managing.


Let's assume that not all 'self-organizing teams' will self-organize effectively.

So, a few suggestions.

1. Get rid of almost all the old stuff.

Really.

Maybe keep one or two 'group' meetings at fairly long intervals, eg, once a month. (We are assuming that the Sprint meetings will give them and you most of the information you all need.)

2. Offer to give the teams feedback.

Get reasonable information from the Scrum teams. Information that they already have.  Discuss with them how you are looking at overall success.  Go to the main meetings. Offer to discuss.  Offer to give feedback.  But don't force yourself on them.

2b. Overall success

Of course managers should be involved in defining overall success for a team. The basic mission and the key constraints.

I would typically recommend a focus on business value and velocity.  By velocity, we always have to say "We don't want you working more than 40 hours per week, but we want the overall velocity of the team to double. By removing impediments, not by working harder."  And focus on quality. Always, it needs to be higher.

Measuring BV success is hard, but important.  (Much more to say, but not here, now.)

In general, business managers should be defining what BV is.  What BV means for a specific team.  Not technology managers.  Ceteris paribus.  (Other things equal.)

3. Offer to fix impediments.

Offer to help. Or approve money, or other people, or just help get permission.

Offer once each Sprint, at least.

4. Group yourselves in small teams (of managers).

We think managing Scrum teams doing innovation is very hard.  The problems each team is trying to address are usually quite hard.  The dynamics inside a team are complex. Etc. Etc. It is a problem (or set of problems) where we need multiple heads to consult.

So, I recommend that 3 managers group themselves, and manage 5-7 teams together. And consult with each other about how to help the teams be more successful.

As implied by my prior comments, at least one of these managers should be a business manager.  Someone who looks at things mainly through a BV lens.

5. Impediment Removal Team

I recommend managers form an "impediment removal team" (IRT).  And that the managers take impediments from the teams, and work on them, one at a time. And deliver 'fixes'.

Discuss with the team when the IRT will take impediments, and when the impediments will 'stay' with the team.

6. After some time, intervene if the team is failing.

"After some time" is the hard part.  How long to wait?  How much do you say?  When?  How?

First, let me suggest that if you smell problems, ask the Team.  And ask them if they want help.

Do not look only at the 'leaders' in the team (eg, the PO and the SM).  Ask the whole team.  Remind them that they are all responsible for success.

In some cases, the team or the situation can be quite messed up. You just must intervene.  But usually they should at least have told you the problems (the impediments) and you should be agreeing.  And usually, depending on the nature of the impediment, you have given the team a reasonable opportunity to address the impediment themselves, their way.

And your action (as a small team of managers) could be selected from a very broad range, depending on the nature of the situation.

You could cancel the effort.
You could disband the team.
You could add or subtract a person.
You could some people more highly dedicated.
You could help them get better Continuous Integation and better automated testing.
You could help them improve the Agile Specs getting into the Team (just enough, just in time, documentation).
You could get a more specific impediment fixed. In possibly lots of different categories.

Does this make the manager's job more specific?

CBA: new Maserati vs. used Lexus??

Ladies, Please forgive me. I have to make an obvious point with some guys. And you know how guys can be. Sometimes you have to make it really obvious to them.

***

We need to know the BVPs (business value points) and the SPs (Story points) of each story, so that we can do CBA (cost-benefits analysis).  And choose the right story to do next.

Why?


Now I explain the picture.

Many guys who are into cars would prefer a free Maserati.  Truly nice sports car. See the picture. 
Wow!  Is that a car or what?  Especially if it is 'free'. (It also helps that I like really smart brown-haired girls and the color blue, but we won't go there.  The things I have to suffer through to make a point!)

But it is shocking how many guys will choose a 2 year old used Lexus, if they have to pay for it (the car).  Why?  Just on initial cost, a Maserati costs about $300,000.  I think a 2 year old Lexus is close to $25,000.  Big difference in cost.

And the customers and business managers are the same way with the features in the new product.  If they can see no difference in the cost, of course they want the Maserati feature. But as soon as they can do CBA, even roughly, they start to say...."umm, I think I can live with the used Lexus" feature.

CBA is also a way to convince them to do the right thing. Release earlier. And then the Team looks like a bunch of heros. Rather than suffering a Death March. (I am surprised that that picture could make regular guys turn into heros.  But I think it could be true.)

Why I prefer ScrumBan to Kanban

I have spoken before about why I like Lean and why I like ScrumBan, a combination of Scrum and Kanban.

Some people prefer 'Kanban', as it is being called in the software development community.

Of course, what 'Kanban' is actually in the wild varies a lot.

So, here are my concerns about doing 'Kanban' alone, without Scrum. And I make some assumptions
about what Kanban is, and these assumptions may not be correct in many cases.

1. No upfront planning.

It is fine and correct to say that waterfall does too much upfront thinking.  But this does not mean we should do zero upfront thinking.

In general people who do Scrum also advocate (as I do) some upfront planning before starting the first sprint.  I call this Agile Release Planning, and have talked about specific techniques extensively.  These are patterns that I use. Not always, but almost all the time.

In the wild, many Kanban people do not even do any Sprint Planning. Much less 'agile release planning'.  Which I think is almost always sad. Yes, I can imagine a few odd cases where agile release planning is not necessary at all.

If the Team is doing purely maintenance work (bugs and small enhancements) and has ZERO work in backlog at the beginning of the Sprint, well then I guess there is no point in Sprint Planning.  But I have never seen this situation. I have seen where a lot of the work for the Sprint will be defined later, as the high priority problems come in.  So...minimal Sprint Planning might make sense.

People (the customers and the implementers, etc.) need to see the big picture. It affects creativity about designing the better solution, it affects motivation, and makes better able to address dependencies.  But, we also must never again suffer the illusion that we have all the information upfront. That too is patently incorrectly.

2. No Team

Kanban in the wild does not require a Team concept. Certainly some people are involved, but how they are involved and whether they are a real, stable team is left totally open.

The Team concept, which involves many things (self-organization, etc, etc), is so important. And it needs to be a whole, real, stable team.  By whole, we mean it must include the business side, as we usually call it.  At least good people representing the 'customers' well. Inside the Team.

3. No Sprint.

Kanban is often played without any concept of a sprint.  Although frequently people will say "we got 20 cards done in a week", which implies a 1 week sprint concept.

There are many many advantages to having a sprint. One is so that the Team and the people around the team can see productivity per Sprint (a measurement or feedback loop).

4. 'Scrum does not allow any changes to  the Sprint Backlog'

This is a reason people give for using Kanban that is not correct.

First, it is true that Team productivity is getting killed by interruptions and whipsawing.  So, we want to minimize disruptions. And the first, overly simplistic rule to get the 'kids' straightened out is: No changes to the Sprint Backlog.

But Scrum is not opposed to common sense. So, for example, inserting 2 SPs of 'bug' work (higher priority) to replace a 2SP story (lower priority) that has not been started -- this can be done.  It should be explained to the Team why we are doing this. And the Team is not being asked to do a higher velocity than what they 'committed' to. And they get to re-commit to the new work too (eg, sometimes there are technical reasons why the 2 SP of bug work is not 'equal', this sprint at least, to the 2SP story).

So, this need to address to-be-identified-high-priority work is a false reason to switch to Kanban.

5. Dis-engagement from the Business

Kanban as played in the wild is often used to enable dis-engagement between Technology and the Business. Of course that does not have to be so, but it often is.

Often the Business side does not want to engage. The solution to this is not to give up, but to attack the issue, and 'force' them to engage.  So, I am very discouraged when I see Kanban used this way.  People seldom admit overtly this is the purpose, but it often is. IMO.

Scrum forces engagement, by making a business person (well, usually a business person) Product Owner of a real Team (and the PO is part of the Team).  And then, if the PO is not engaged enough, that should become apparent quickly as an impediment, and hopefully fixed (if high enough in priority).

6. No Daily Scrum

Kanban in the wild often has nothing like a Daily Scrum.

All Lean teams do a short daily meeting (AFAIK). Why do 'Kanban' teams not do this?  Well, they often say they don't want to stop 'continuous flow'.  But then, still, everyone goes home at night and flow stops.  Lean has a short daily meeting, because it helps the Team stay in sync, etc. And the stoppage 'cost' is repaid the same day by higher productivity.

So, I think the Daily Scrum adds a lot in enabling the Team to sync up, self-organize and self-manage.  As a Team.

(Kanban does not require any Team concept.  But sometimes it is played with a Team. So, a Daily Scrum would enable them to do a better job in collaborating, etc as a Team.)

One Team (and I think I believe they are a real Team) that uses Kanban does a kind of Daily Scrum every day at lunch. Still, I am thinking this is less effective than a regular Daily Scrum.  If done professionally.  Although, to be fair, many so-called Daily Scrums are...not really what they should be -- they are not done professionally.

7. No Sprint Review

Kanban in the wild is often played with no Sprint Review or Demo. AFAIK, Kanban does not require any demo.

Related to that, Scrum requires a Demo every Sprint. That includes the business stakeholders.

Now, in Kanban one could have demos.  Ad-hoc. For example, of each 'card' when it completes.

But this is not nearly as good, usually, because the best people to give the best feedback are the business stakeholders. They are often fairly senior or at least very busy. So, it is better for them if, fairly far in advance, they can schedule that every two weeks (or every Sprint), they will come to the Demo (Sprint Review).  This leads to better attendance and better feedback, based upon all the stories, seen together.  'The whole is greater than the sum of the parts.'

In Scrum one could still add additional feedback during the Sprint. For individual stories, as one example. There is no restriction on additional feedback.

8. No Retrospective

Kanban does not require any Retrospective.

Of course, something like a Retrospective could happen 'naturally'.

But from lots of experience, we think the odds of a regular and good retrospective go down considerably if there is no 'required' meeting to make it happen.

Again, to be fair, lots of 'scrum' Retrospectives are done in name only. And are not good or not very good. I want them not to call that kind of unprofessional work 'scrum'. But of course I cannot enforce that.

***

It is fine to add more Kanban ideas to Scrum. And specifically the Scrum board (which out-of-the-box is a basic Kanban board). And to focus on flow, pull, single-piece flow, minimizing WIP, etc.  Excellent ideas.

And sometimes you can't get a Team to do all of Scrum.  At first.  So you start with Kanban. I totally understand.  Getting people to change is hard.  But as soon as you have that change made, start working on them to make some more change.  And adding each part of Scrum, piece by piece.

Comments?

Store Points rather than Hours

Jeff Sutherland has a great post about this, here.  A must read.