Toronto – Impediment List

Here is what the Toronto course identified as impediments.  Not in any order (although understood that it must be ordered).

1. Overlooking risks
2. Big scope
3. Team competence
4. Too many defects
5. Team changes
6. Processes not clear
7. Product owner involvement
8. Under estimated
9. Requirements not clear
10. Requirement change not being communicated
11. Not what client expected
12. Finance
13. Resource (probably mot the right people or not enough people)
14. Schedule (too tight)
15. Poor communication plan
16. Stakeholder (poor, missing, etc.)
17. Knowledge (lack of)
18. Training (lack of)
19. QA (test)
20. Lack of focus
21. Buy-in
22. Scope creep
23. Bad Req
24. Too many opinions

Some of these should say ‘(lack of)’.
We recommend a public impediment list. Of course, the list itself is not the point.  But rather AGGRESSIVELY attacking the impediments and fixing all the impediments is.
We like to have one list for ALL the improvements we need to be made (for the Team). From people issues to Blockers, to tech issues and changing culture.

Making Change Happen

How do we get change to happen?

First, this is an interesting and somewhat hard problem.

And no one knows the full answer. Change does happen, and people after the fact ascribe causes to why the change happens (or does not happen). But the facts are very messy, and mostly in the minds of people, so it is hard to be sure. And hard to know if we are lying to ourselves.

Still, first, change does happen.

And, second, some people seem to be better at making it happen than others.

Why is this topic interesting to you?

Well, I suggest it could change your job and your career. I will suggest some of you should move to a different company.

I will suggest that if you make change happen, you can dramatically affect the lives of people you care about. Change them a lot. Double their happiness, send up their productivity by 200, 300, 600%.

Make customers 100% more satisfied. Destroy the competition.

So, I hope by now you are attentive to this subject.

***

A couple of assumptions.

1. Agile values, principles and practices, if adopted well and executed professionally (but not perfectly), can provide tremendous results.

I think that agile, even if done unprofessionally and partially, can usually provide notable results (+20%).
But if done well, agile can have a tremendous impact (+500% or more). From the base line of the team you are working with. And the benefits probably extend higher, but I don’t know if ordinary people can get a Team to keep going that much higher (e.g., higher than 10x better).
For today, I will not try to justify that statement, but I say it today simply as an assumption that is key.

2. For any large group of people, the thought processes associated with agile are not the normal culture.

It may be that some individuals understand agile almost completely and almost naturally and intuitively. With a minimal mixture of waterfall thinking or culture.
But, it is now our belief that almost every company (or collection of people) has a strong mixture of ‘old style’ thinking that retards or degrades or diminishes success with agile.

3. It is hard to get the group culture to change.

It is easy to change one or two people some, and introduce to them some new ideas.
But it is very hard to change a department’s culture.
And even harder to get the whole company’s culture to change.
But, at least in small groups, we can get the culture to change.  At least enough to adopt agile initially.  And enough, often, to have that adoption become better and better over time.

4. The Change never ends.

I am less sure of this one, but I think it is always true.
That is, do not be gulled into the opposite feeling: “Oh, we have changed to agile and no more change is needed.”
First, your group probably is not really doing agile well, or nearly as well as it can do it.
Second, by definition with Scrum, we are continuously getting better.  In a very aggressive way each Sprint, by removing the impediments.
Third, we find that ‘old style thinking’ starts to come back, and people forget why they started to do agile, or why agile works, and this starts to degrade the lean-agile implementation.
So, we must be continually changing in a forward direction, and watching out for retrograde movements in the culture.  And then fixing them.
***
Now, what do we do?
My 3 favorite things to talk about in this area are:

1. Just do it!

By this I mean, just start doing Scrum, and do Scrum well.  And then add things to Scrum, but also come bacj and do Scrum well. And by doing Scrum, the whole culture starts to change.
It is not enough, by itself, but if you understand what I really mean (eg, that you are explaining the success of Scrum all the time), it starts to have a significant impact.

2. Read John Kotter

Kotter has an 8-step program for change.  These are the steps:

1. Create a sense of urgency
2. Build a guiding coalition
3. Form a strategic vision and initiatives
4. Enlist a volunteer army
5. Enable action by removing barriers
6. Generate short term wins
7. Sustain acceleration
8. Institute change (that is, put it into the structure of the org)

These ideas are worth looking into more.
The biggest problem is step 1.

3. Use Fearless Change

Mary Lynn Manns and Linda Rising wrote a great book about change, called Fearless Change.  We strongly recommend the book.
The main part of the book describes 48 patterns you can use to change your group (your set of people).
Use those patterns regularly (one per day).

4. Open Agile Adoption

Daniel Mezick has a wonderful set of ideas around Open Agile Adoption.
In summary, do not force the people to adopt agile. You can (you must) explain it to them (eg, hire a trainer to train them on it, etc.).
And give them a vision, something like: “Over the next year, we want to become Agile to see if that gives us some real business benefits.”
And then invite ‘the people’ (including all the people) to join in, and define the details of the change.  And argue about it.
Use Open Space events periodically (every 3 months?) to define chapters of change.  And to enable the people to self-organize on which parts of the change should be worked on now.
If you notice, these ideas invoke several of Kotter’s ‘steps’.
***
Too long for today, so I will stop.
Comments please…

Managers : Impediments

It should not be confusing how to manage in Scrum (agile) Let's put a scope of this. We are talking about the management of innovation, using Teams. Not the management of BAU or regular production or whatever your firm calls that. I am less sure these principles apply in those cases. First, you have a Team that should be a real Team. And they (the full Team) should mostly self-manage. Second: ask a few questions as a manager. Ask the Team things like this:

1. How is it going?

Then listen carefully. Don't 'talk', listen.

2. Am I (or is 'management') an impediment to the Team?

It is remarkable how often, in trying to help, we managers actually get in the way. We distract, we interrupt, we just don't help them. OTOH, sometimes things that actually are helpful are not understood that way. But if the Team does not understand (in your opinion), at least listen carefully to their opinion. They might actually be correct. Always recognize that management is 'overhead' and by definition is in some way 'getting in the way' of doing the real work of innovation.

3. Where is your public impediment list?

Review it with them, especially the top items. And you might suggest impediments that they should consider. You want to see a good, current list of the top 20 ways they think they can improve.

4. Let's discuss the impediments you have fixed lately (in the last sprint) and how much impact that has had.

Comment favorably on the progress they have made. Reward that behavior. Ask them: having done that, 20-20 hindsight, how might you (or you all) have done that better (the next time)?

5. Are there any impediments you would like me to help you with?

This is THE essential question. In fact, the answer always must be 'yes', and the only real question is deciding which one. It probably will be one where the manager is competent to help. And then, more competent than the Team itself to fix.

6. Is the Team spending enough time 'sharpening the saw'? What percentage is that?

"Sharpening the saw' is from that famous story in Covey's Seven Habits book. Human beings 'naturally' never spend enough time sharpening the saw. They seem to be thinking that it is 'better' to just do the work with brute force. Perhaps in the middle of a battle, hand-to-hand combat, that is the right thing to do. But not with our knowledge work. I recommend that the Team spend about 1/7th of the 'power' on getting better (aka fixing impediments). *** Some notes: The public impediment list will be prioritized, and the priorities could change with time. The order should include cost-benefit analysis, at least to the degree they can do it. You might need to help them think that through. Often they have little or no experience in doing that. Political cost is among the costs to consider. But we do expect managers (and teams) to take political risks, in a measured way. You might not agree with the priorities, especially at first. Discuss that with them, without using your power. Don't worry about the priorities too much. Even if you do them 'out of order', a significant part of the benefit of fixing impediments is that you did what they wanted you to do. It has a huge motivational impact. You are saying via action their work is important. Now, I am not saying spend tons of money just to have them 'feel good'. But do not ignore the motivational factor. There are many many more things to say about impediments. But I hope for many of you managers, these notes are a good start. I think if your encourage 'removing impediments' in these ways, I think you will be surprised how much better the Team becomes. *** Please comment....

Agile Adoption: Two styles contrasted

Imagine a smallish organization with 10 Scrum teams (or what will be 10 Scrum teams).  I want you to be thinking of a relatively uncomplicated situation.

Imagine that you offered two ways to implement agile. Let us assume that we believe that agile will lead to better lives for the workers and better lives for the customers.  And, indeed, better lives for all.  And to a fairly high degree.

Option 1. Top-down, via 'convincing'

You get a senior sponsor.  He says some good words.

You hire SMs, coaches, some agile people.

You get an 'agile committee,' not unlike a sponsor committee for a large project.

And the small group of agile people do things to make the agile transformation happen.

But, importantly, this approach does not allow the whole group to self-organize.  The Leader or a small group 

imposes an order on it.

And you are, and everyone knows you are, trying to 'make agile happen.'

Two commonplace sayings in change management.

"People do not resist change, they resist being changed."

"People are remarkably good at doing what they want to do."  Little's Second Law

 

Option 2. Similar, but allow self-organization

This approach is very similar, really, to me.  But with some very important differences.

You skip the 'agile committee.'  Because you know that committees almost always waste time and do nothing.  In fact, that's WHY we have committees.  It's what we do to ideas we wish to kill.

The agile advocates might still meet and talk, and get smarter.  But they do not attempt to decide for the group, nor to force the group to accept 'agile' (however it might be defined).

But an important difference: we invite everyone to help solve the problem or problems, to make agile work for us.

And we use Open Space to allow the whole group to self-organize within the context of a vision.  (Sample vision: "We want to experiment with agile and see if it will work for us, and maybe give us some great results.")   The self-organization is highlighted by two events bounding a timebox of change.  The opening and closing events are done using Open Space (some of you know OST).   And they learn how to self-organize by repeating this regularly (say, every 2-3 months at first).

In this way 'the wisdom of the crowd' is harnessed, in part for its wisdom.  And what is not working well in the formal structure is avoided.  Everyone can contribute and, particularly, the wisdom of the informal people is harnessed more.

But more importantly, we allow them, who are actually doing the real work, to tell us what their biggest concerns are.  And then we (all of us...management and workers) address those concerns and issues in priority order.

And they all become engaged.  They start to think of it as their own show (not completely, but to a large degree).  They are acting to help realize the vision.

BTW, management does not give up on introducing agile ideas to the group.  We have to be mindful that most of them do not understand agile at first, and have never experienced its real benefits.  So lots of explanations of the counter-intuitive aspects of agile are needed.  But the explanations are offered, not forced.

And management is very mindful about telling the story.  Stories about the past, the present and the future.  Stories that help them see the truth better, that agile is helping (well, assuming that is the truth now).  Stories that give the change meaning for them.  Everyone is, to some degree, telling stories, but management actively engages in forming the new story for the new culture.

Note: In these ways, we actively engage in culture change.

But 'our' attitude is different.  We are not 'forcing' these ideas on them (the ill-informed knowledge workers).  We are instead inviting them to experiment with these ideas.

Just as Taiichi Ohno suggested.

 

Results

It is, of course, a bit more complex than this.  There are other issues to consider, beyond the scope of this short blog piece.

But which Option will have more success?

This is your question.  And, in my experience, a huge difference hangs on your choice.

It seems to me that Option 2 is far more likely to realize the real benefits of Agile.  Potentially huge benefits.

Option 1 will still probably get you some benefits.  Maybe the Teams will be 20% better.  Probably.  And you don't have to give up the illusion that you can control people.

With Option 2 you can get 100-400% improvements in productivity.  We certainly can argue exactly why it happens (Scrum, Agile, self-organization, CAS, etc, etc.)

But to do Option 2 you must give up the illusion of control of people.  It feels hard to some of us.  It is not, really.  (Still, any change in paradigm is hard for those wedded to that paradigm.  Be sympathetic, as you will want them, in a different context, to be sympathetic to you.)

For senior managers: Asking the middle managers to give up the illusion of control of people can sound very dangerous to them.  You have to work with them, over and over, and get them comfortable.  Or, failing that, no matter which option you take, experience shows you are likely to end up with some problems and a relatively weak implementation of agile.

***

BTW, Option 2 is explained in more detail as part of Open Agile Adoption.  You might start reading here:

http://newtechusa.net/agile/open-agile-adoption-explained/

It has been tried and tested, to some degree.  (Open Space has decades of being tried and tested, and if done professionally, is very robust.)  OAA is relatively new.  But I hope you see its power.  I invite you to consider it.  And it works both for new agile adoptions and well as for a 're-start' of a troubled agile adoption.

Option 1 has been tried in myriad variations.  Pretty clear that unless you have a charismatic leader or a culture that already 'wants' to do agile, you are going to get a 'meh' adoption.  Very likely.  Yes, some benefits (20%), and a few teams doing well for a while.  But to me, only getting 20% is 'meh.'

Let me say it a different way.  I think if the adoption does not harness the will of the people in wanting the change, the change results will be 'meh'.  OAA is one way to engage the people.  I would be very interested in any other ways.  But for now, you may want to consider OAA.

Avoid an agile adoption that's 'meh'

We suppose there are many ways to adopt Agile or Scrum.

And in a sense it is true that each organization adopts agile in it's own way.

One pattern is 'bottom-up'.  This means that it starts with one team, who finds out about it and starts doing it, and then it spreads.  Without official approval at first, but later with at least the authorities not resisting it.  To the degree the 'bottom' gets the 'top' to support it in some ways, this can be a very successful approach.

And other pattern is 'top-down'.  The Leader decides 'we will do agile', and tells the group in detail.  This can work, to some degree, especially if the Leader has credibility and, in one way or another, explains what and particularly why.  And gets buy-in.  In that case, with time, it can be successful.   Why?  In my opinion, in large part because Agile justifies itself to the people.  Once they try it, they see the results, and become convinced.

However, very commonly the top-down implementations are 'troubled.'  They get some benefits, but people naturally resist.  They do not become engaged, they do not buy-in.  And, hence (at least IMO), the energy is not there, and so the adoption's benefits are rather modest.  And the people slowly, in a sneaky way, start to revert back to what they want to do.  Perhaps they do it consciously, maybe even more they do it unconsciously.

There is a another method now, called Open Agile Adoption.  One of the key ideas is that it is 'optional', or maybe better to say 'experimental'.

In other words, it is an attempt to see what people will want to do. At first, as a group, they do not understand agile.  Often, even later, they do not fully understand agile or scrum.  So, we do recommend some training on what agile is.  And some discussion within the group.  And use other methods to learn what agile really is.

Then the Leader 'invites' them to experiment and discover the benefits.

One. The adoption is no longer 'forced' or perceived as forced.  So, the natural resistance that occurs when you do that (at least in some people) is avoided.

Second.  By inviting them, you get them to start to buy-in. They are making a choice.  They feel like they are creating the change themselves.

***
Here’s how it works.

1. Let's try letting them volunteer within the context of a vision.  Practice, experiment, learn (much as Ohno suggests).

2. Let's get them engaged in the change itself (partly via doing practical work).

3. Let's bind these 'chapters of learning' (or chapters of change) in timeboxes.  We call each timebox a 'rite of passage'.  Maybe 2-3 months.  After each timebox, the group levels up.

4. Let's put a self-organizing event at either end of the timebox. We'll call these 'open spaces'.  1 day each.  And they act kind of like a sprint planning meeting and a retrospective, all rolled into one.

Then rinse and repeat.

And let's include Steve Denning's idea of leadership story-telling.  In fact, let everyone tell stories (they do anyway), but we (the good guys) tell MORE stories than we usually do (for God's sake!  We must!).

And the culture gets changed.

***

I recommend this set of ideas.

Start here: http://newtechusa.net/open-agile-adoption/

And read Harrison Owen's book, Spirit, here: http://www.openspaceworld.com/Spirit.pdf
This is a fascinating read.  Too intense, I think, to read quickly.

Heck, you are NOT going to read Harrison's book until you watch the video:  https://www.youtube.com/watch?v=APD7oQ3xrSA
It's about 14 minutes.

***
 

OAA is practical and tested approach to 'good' agile adoption.

Who knew we could treat the people like people?  And self-organize the change within a vision!

This approach allows, as far as I know, you (as agile advocate) to do also almost every other 'trick' you were going to do.  But whenever you do something now,  do it with respect for the brains of the people you want to change.  Get them to see the merits.  Don't think about 'forcing' it.

So, the Leader does not 'mandate' the change in detail.  ie, In OAA the Leader can give a vision (eg, at first "We want to experiment with agile methods to see if they will work with us"), but we urge you not to add too much detail to the vision.

AND...you (the leader or the leader group) can also OFFER to them details about things (like Scrum) that they might use.  And suggest that they *experiment with them."

So training, coaching, talking can still be used.  But in the context of invitation.

Who knew people, especially our knowledge workers, needed a feeling of autonomy?  (Cf Danial Pink in "Drive".)

Seriously, I recommend you consider this approach.  You will get more success.

Strategy as Distributed Phronesis - Nonaka

Some of you will recognize this name.  He is one of the two men who wrote The New New Product Development Game, which directly lead to the creation and naming of Scrum.

Here is slide deck on "Strategy as Distributed Phronesis."

Sounds like a mouthful, but it has some great stuff in there.

I think you will enjoy.

nonaka phronesis slides

 

What does the Executive Team do in Scrum?

In an earlier post, we described an Executive Team in a smallish company (aka an oversight group in a larger company).  And we described a simple situation.  For example, the oversight group is responsible for 8-10 initiatives. Or, basically, 8-10 Scrum teams.  For now, let's make it simple, and imagine that each Scrum Team is working fairly independently.

What does the Executive Team do?

First, the ET is getting new ideas, new projects, new initiatives.  The ET must decide which things to start and which to stop.  Ideally, we stop an initiative just after the Team has delivered a significant release, so that the productivity of the Team is not wasted.

And the ET resolves conflicts between Teams.  Team 1 wants George and Team 2 wants George.  Often the Teams and/or some individual managers can figure out this problem quite well, but sometimes it requires and Executive decision.

The ET does high-level budgeting.  For example, how many initiatives should the firm have in flight at one time.  And this decision affects the start-stop decisions.

The ET monitors the overall impact of the initiatives on the firm and the customers.  Only with all the different perspectives on the ET, can the ET (as a team) see the overall impact of all the different factors.  (And there are so many different factors.)  No one person sees them all, but the ET (if it has the right people) sees them all.  Or, at least should see them better than any other group.  (We must admit that we are all human, and so the ET too will be imperfect.)

So, the ET must act as a real team, and decide for the overall good of the customers and the firm.  And not have each person focus only on his individual area.

So, in a broad sense, the ET (together) sees and looks after the broader interests of the customers and the firm.  Everything considered.

And, of the 3 levels I mentioned before (Team, business stakeholders, ET), only the ET together sees the overall picture. And only the ET has the knowledge and power to make better, high-level, decisions.

***

One key thing the ET must decide: The priority order (today) of all the initiatives.  And of all the 'ideas' that might be done.  Only together can they compare and decide on the probable impact to the customer base and the firm.  And then start the best initiatives and stop the least valuable initiatives.

***

One more key factor: Do not under-estimate the motivational impact to the Team of seeing the ET once per month (briefly).

First, the Team will realize 'hey, this must actually be important work, because the ET cares about us.'

Second, the Team will say 'darn, we must have some good stuff to 'show' every month, to impress the ET.  We can fool around or lose focus.'  (By show, I do not mean a demo to the ET.)

Third, when the ET likes it, the Team can feel proud.

Fourth, the Team can ask for help from the ET.  'Give us some money or some people or just approval to fix our top impediment.'  The Team will need to pull together a decent business case, but the ET must look at and decide on this requests.  (Note that a business stakeholder/manager could also get some of these requests too.)  'Who knew the ET would actually help us?' is what they often say.

***

What does an ET do for a Team?

Most often two things:

1. 'We like your work and your progress. Please continue.'  If this can be done briefly, at low cost, this should have a big impact on the Team.

Note: While doing this, the ET (for the customers and the firm and the overall motivation of the Team) has re-confirmed, after all the change and everything we have learned in a month, that, compared to anything else this Team might do, this is still one of the Top X initiatives.

2. The ET helps the team with one impediment.  Ex: The ET directs that George give not just 10% but 20% of his time to the Team.  Ex: The ET gives the team $3000 to take a course on some aspect of Java.  Ex: The ET directs that the Team engage the Communications group in the next week.

Let me take that last example, and go a step further.  What should have happened is that the Team itself contacted the Communications dept, and Team and the Communications dept worked out that problem soon enough.  Or, failing that, that the business stakeholders (manager) associated with that Team had intervened and had gotten that conversation going sooner.  And the Communication group also has the responsibility to reach out to the Team and contact them, if they see a need.

BUT (possibly) in this case all those thing had not happened (yet) because the Team and the manager did not see the big picture, and could not know that because of X Y and Z, that engagement with the Communication group needs to happen sooner.  And the ET, seeing the bigger picture, directs that that conversation happen sooner (in this case).

So, we must recognize two things:

1. Human being will fail sometimes.  One failure does not mean that the responsibility should be taken away.  When we manage, we must assume some degree of failure.  So, we have backup systems, but only to some reasonable degree.

2. Even if one has a responsibility, one will not always have the information to execute well on that responsibility.  In this case, the ET, having the broader view (as a full Team) could see the issue and direct a resolution.  (One could call this fixing an impediment.)

***

Trade-offs

We must emphasize the following point.

In managing innovation, there is a strong trade-off between managing things better and the cost/overhead of management.

It has been our tendency to over-manage innovation.  And mostly what that does is destroy the productivity of our knowledge workers.

The ET meeting for any one Team must be brief.  Probably 15 minutes per month.  (One might argue for 30 mins.)  Obviously, if the Team is doing badly, or the ET feels it must take some action, then the meeting for that Team might take longer this time.  In any case, the timebox must be managed; all Teams and initiatives are complex and we easily could talk 'for a long time', but with very little additional value added.

In this context, an 'epmo process' must give the ET some information to do their job effectively.  But we must make sure that process does not over-burden the Team with reporting work.   Also, the 'epmo' itself should not become another layer of management... this is bad.

And it is tempting.  The ET people are by definition very busy.  The unconscious desire is to avoid the tough decisions, and to push work back on the epmo person.  The epmo person will never have the broad perspective that the ET has (as a team, if the ET people share the tacit knowledge as a unified team).

Also, for the ET to be effective, the information flow to the ET must be 'clean' or unbiased.  If the epmo person is allowed to 'take responsibility' for things, the more that happens, the more we get the human desire to hide and to only show what we want to show, ie, the ET gets biased information. This degrades the effectiveness of the ET, possibly almost completely (I think I have seen those cases).

Last warning: Let the Team talk directly with the ET.  (Maybe only the PO and SM attend.)  It is tempting to rely only on reports.  In innovation, a huge portion of the inputs are people.  Hence, only by 'looking at the people' can the ET see what is really going on.  Also, only the people can explain what is really happening (all the tacit knowledge that never gets into a report).  And, if the ET decides or directs anything, the people need to understand.

The Team are indeed human and prone to bias.  We have to accept that that happens to some degree.  So, we also recommend that one or more business stakeholders from the Team also be there in the ET meeting, to also answer questions with less bias.

***

We hope you can see from this discussion how the management at the ET level would really work in this situation.

We welcome your comments.