Wednesday, December 10, 2014

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.

Friday, December 5, 2014

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…

Friday, November 21, 2014

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....