What’s wrong with that impediment list?

Let’s pretend that the impediment list that I just posted (the one from the Charleston class) was a real public impediment list.

What would be wrong with it?

First, the most important thing to say is GREAT!  Finally, we have a public list of key things we can work on.  And, if we work on them well, it will make us MUCH better.

But again, imagine it is a list for only one Team…what’s wrong with the picture?

Here are a few ideas…

1. Too many items.

It just is not useful to have more than 20 or so items in a list for a Team.  Then, if new items come up, you ask “Is it more important than anything on our top 20?”  Usually the answer will be no. Until the Top 20 list gets to be maybe 18 left.  In which case, you might add an item to the bottom. (smile)

2. Not prioritized.

Well, you didn’t know that, but I know that they did not prioritize them. And, if you thought about it, I doubt you would have prioritized them that way for your team.

3. Not ordered.

By prioritized, we mean that the list is in order of what ‘slows down the whole team the most’.  By ordered we mean additional ideas: cost-benefit analysis has been included. Dependencies between impediment fixes has been considered. The items have been sliced appropriately (eg, small enough). Etc, etc.  They are in an order that will lead to the greatest improvement in the least time. Cf TOC.

Cost-benefit analysis means that someone (or more than one) has made some effort to consider the cost of fixing each of the items. This might be done intuitively or more formally.

4. Not well described.

Well, first I will mention again that some items are huge, and hence too vague to be useful.  So, part of describing them well is to make them smaller.  Some are more symptoms than causes. At the very least, the Team should be much more clear than you and I are about what they really mean. Often they were written quickly, and after you discuss ‘what did you really mean’, you realize that different words would say it better.

5. No RCA

The list does not make visible whether any Root Cause Analysis has been done. And of course that must be done.  And the biggest root cause must be fixed first.

6. Small enough?

This is important to say yet again a different way.  The items at the top at least should be small enough …. so that, the top one can be ‘fixed’ or mitigated in one Sprint, and people can feel the benefit in that sprint or the following sprint.  Usually.
Small and actionable. (Where did we hear this idea before?)

7. Take action?

Yes, Virginia, some people use a list NOT to take action.  The list is to enable them to forget about the top item, and NOT to take action on it.

So, hopefully it is obvious to you, me, your Team and company……the list must represent the tacit commitment to take aggressive action on the top SINGLE item. One at a time. And not to take any action on lower items (until the top one is fixed).  And that action always (in general at least) must include a commitment from people outside the Team as well (for money, for maybe some more people, for approval).  (Managers outside the Team won’t be involved in every impediment, but often enough they will have to be involved in some of them.)

Of course, the ‘single-piece-flow’ idea must be applied with common sense. We might have 3 impediments ‘in flight’ in this way: The SM is working on one, the Team is working on one, and Managers outside the Team are working on another.  Maybe this is ok, even good. It depends on common sense.

Impediments: from the Charleston CSM class in September

As you may know, I think it is key in Scrum to aggressively attack impediments.

I think each Team should have a (mostly) public impediment list. I think the SM should be attacking the top impediment each day.  I think this ‘kaizen’ should lead to improvements in velocity. I think every Team can get better. Always.

An impediment is anything (anything) that is slowing the Team down (or stopping the Team).

So, I asked the Charleston class to list their top impediments. It was a diverse crowd, representing many teams and several companies.  Here are the stickies that they showed each other:

• Deflection
• Skill set (lack of…)
• Identifying risks upfront (lack of…)
• Market (changes?)
• Interest (by the Team??)
• Eliminating scope creep (ok, I think now they would say ‘reducing’)
• Notification of deadlines
• Communication
• Hardware defective
• Environments not ready
• Task slippage (too much)
• Too many items open at once
• Not co-located
• No project rooms
• DBA backlog
• Too much talking – too little action
• Operational responsibilities
• No staffing in critical areas
• Lack of documentation
• Status updates
• No prioritization
• Wrong product selection
• Night job; people working day jobs fit it in when they can
• Wrong Tech skills
• Too aggressive a schedule
• Not enough people
• Customer won’t accept product
• Unclear scope
• Not knowing what the customer wants
• Unclear product owner
• Risks were not mitigated
• Changing end goal mid project (and it didn’t make enough sense)
• Mgmt issues
• Poor process
• Poor planning
• No project methodology
• Market value (effort had a ‘low’….)
• Not enough $ (for effort, per what makes business sense)
• Lack of control – outsourcing too much
• Morale
• Customer participation
• Structure
• Poor system availability and speed
• People constraints (eg, tech)
• Prioritization (lack of)
• Communication
• Synch of environments (lack of)
• Control of patches (lack of)
• Improve upper mgmt focus
• Unwilling to ask for help
• Unknown requirement
• Lack of Auto testing
• Undefined goals
• Improving the ‘owner’ (maybe the PO)
• No accountability
• Managing whirlwind
• Knowledgeable subject expert not available
• Lack of procedure
• Lack of Scrum [I liked this one - smile]
• Broken code
• No installation guide
• Incorrect estimates
• Indecisive “decision” makers
• Data crash
• Time spent on non-value added tasks
• A wide variety of different things.  I recommended to them that a Team track the top 20 impediments…that was probably enough.

I hope this list suggests to you or your team that maybe there are…. one or two more ‘opportunities for increased excellence’.

Scrum is Hard! (Scrum is Fun!)

The classic phrase from Sutherland and Schwaber is: Scrum is simple, but Scrum is hard.

And yet, with almost any decent Team, Scrum is fun. Unless the personal chemistry is dysfunctional.

So: If I don’t warn you  that Scrum is Hard, I am lying.

But if I don’t ‘warn’ you that Scrum will be fun, I am also lying.

OK, but why is Scrum hard?  Here are a few reasons. There are other ways to put it. And probably other reasons.

1. A person does not want to admit that he is imperfect.

Very common, right? And understandable. So, when you see and talk about imperfections, find some way not to let people get defensive.

2. People don’t like to admit that ‘we’ are imperfect.

From a certain point of view, this is silly. But it is also how humans are. We don’t like to ‘air our dirty linen’ we sometimes say.

So, this can be a hard thing to change. Again, a lot of it is how we talk about it. So, one cliche is that we phrase it as ‘opportunities for improvement’.  Sometimes very useful.

The key here: Scrum makes obvious lots of personal, team and organizational ‘problems’ or impediments. Makes them very obvious. And some people find this very very hard. And for us Scrum guys, getting those people not to make a mess can be very hard.

3. Change

Scrum is a change. And Scrum demands more changes.

And any change is often hard. You surely have experienced this many times personally.

Now, for a given person, some changes are felt as good. So, not everyone every day will find that changes of Scrum hard. But almost always someone, to some degree finds ‘the change’ hard.

Be sympathetic, to some degree. Bend them, but don’t break them. The next key statement is: Most people don’t resist change, they resist most being changed (by you).

4. Pressure or Stress

Our business of new product development is, by its nature, somewhat stressful.

New products MUST be built ‘quickly’ or ‘on time’.  Time, and quickly delivery are fundamental.

In the old waterfall way, the stress was ‘controlled’ a certain way.  Usually low for a long time, and then very high at the end.  Typically.  In Scrum, the stress is continual, all along the way.

Some people think Sprint means that stress is too HIGH every sprint. (That is not what the word was meant to convey.)

Really, with Scrum the Team is supposed to have ‘positive’ stress (you can google that is you don’t know the concept). And bad stress is supposed to be eliminated. But life is never quite that simple.

So, as you introduce Scrum, you must actively manage that they understand and execute on the ‘stress’ ideas in the proper way.  Much too often, ‘Scrum’ is used to just beat up on the Team continually.  (Or at least that’s how they hear it.)  In many ways, Scrum was designed to SAVE the Team from the Death March. So this ‘beating up’ is rather ironic.

But also ironic is the notion that the Team with Scrum should have zero stress. That time magically has no importance suddenly. This is of course not true. The full team is faced with the business problem of delivering something useful in a reasonable time.  They may or may not be able to do it in a specific situation (eg, company and product), but that fundamental pressure is unavoidable in our business.

5, People Types

A few Myers-Briggs types will find Scrum ‘uncomfortable’ or hard.

Those types may have been fairly satisfied (even if unproductive) in the ‘regularity’ and ‘control’ of waterfall. But Scrum exposes that our business actually has a fair amount of ‘chaos’.  Makes that much more obvious.  And a small percentage of people will find this too uncomfortable for their Type.

In the long term, this is a good thing.  People get reallocated to work that suits them better. But in the short term, it can be hard.

6. Skill Development Feels Endless

We know from any sport that even for ‘simple’ sports it takes years to develop into a true professional.

Scrum, in a similar way, exposes that development into a professional product development person (whether business or technology side) takes time.

And learning and playing the simple sport of Scrum takes years to master as well. Years. Years of hard practice. And this realization can be discomforting to some.

In truth, this was always true in a way. But waterfall kind of hid this truth to a fair degree. And one could feel ‘advanced’ much sooner. It was an illusion, but it seemed to be true then.

So, while this can seem hard, I am not convinced that it is really hard.
But you have seen already that almost all of what I have called ‘hard’ is mainly inside the heads of people. It is not ‘externally’ hard (mostly), but rather internally hard. Or subjectively hard.

7. Impediment Removal

Getting groups of people to remove impediments often feels very very hard.

And it is. All work in life is hard in some sense. And when we are inexpert at some things, they definitely feel very hard at first.

But with impediments, we tyoically also must get other people to ‘assist’ or go along in some way. And that can be very very hard.

Very useful, but very hard.

***

So, there are a few ‘hard’ things about Scrum.

I would be interested in your thoughts on why Scrum is hard.  I have not used the word ‘culture’ yet, and expect some of you to use it.