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…