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…

Achieving the Goal of a Retrospective

Some teams seem to approach Retrospectives without a real drive to succeed.  Or so it seems.  They just use it to ‘talk’.  About the ‘good, the bad, the ugly’ as I sometimes tease.

Now, talking can be helpful.  Still, we can usually do better than this.

What is the goal of a Retrospective?  Well, I think it should be to seriously improve the Team.

Sometimes, to help them have more fun. And other times to become --‘more productive’ is the usual phrase.  And becoming more productive should be a point of pride for the Team.  That they are good, and they are always getting better.  And that mere fact should be part of what makes them happy.

How do we mean more productive?  Well, I am ok with two ideas about this.  One: we are delivering more business value. Or,  two:  that our velocity has increased (and not by working harder or longer).

So, how do we make this happen?

Well, there is no end of ideas about the details of the Retrospective.  And we need o have many ideas.  Because we need to be creative about improving ourselves.

But let me suggest two basics.

1. Starting Stuff
2. Attacking one impediment

By ‘starting stuff’ I mean something fairly brief.  Let’s sat about 15 minutes.  And this section might include the following (or not, if already done or done elsewhere).

• Some appreciations or ‘yea us!’ or ‘let’s continue’.  Some good news of things going well.  We need some good news.
• Eliciting some ‘bad news’.  Mostly what we need are new impediments, or impediments not previously identified.
• Deciding on the top impediment as a team

Note that additional impediments are only useful if it or they are within the ‘top 20’ impediments.

Almost surely, anything less important than that is just distracting for the team.
Also, some times the top impediment is entirely obvious to everyone on the team. But certainly not always.

There are lots of detailed techniques for doing this starting stuff.

Also, note that I have implied (and am now saying) that the Retrospective is not a a general talk session.  It is not for general ‘bitching and moaning’.  It is not to ‘answer questions’ or just to ‘look back’ or simply to gather ‘lessons learned’.

And, we must prioritize. And make a significant improvement.

We must work on the top impediment.

Will we always choose the real top impediment?  No.  But we pick the one we think, when worked on, will give us the most benefit (improvement) per unit of cost.  (Ok, a few other factors might also be included.)  We pick our best guess at the top one.

Three things the Team should typically do in the Retrospective to attack the impediment.

1. Devise a solution.
2. Develop an implementation plan for the solution.  I do not mean a detailed Gantt chart or WBS. No.  But an approach, and identify who is needed, the basic activities, a sense of who needs to do what.  So that it can then get done.
3. An A3. Or a business case to a manager.  To get the manager to say ‘yes’.  To money, to providing people, to just approval that the change can happen.

One or more of these 3 should normally take up the bulk of the Retrospective. Normally, actually fixing the impediment is done outside the Retrospective.  By the ScrumMaster, or by the Team, or by someone outside the Team

And, we expect to get measurable improvement (eg, better velocity) in the next sprint.  Usually.
We think if you follow this advice, that your team will find the Retrospective more useful, and will become more productive overall.  And enjoy the happiness of being more successful.

The PO - The Team - Daily Scrum

I have some different views on this, and wanted to share them.

Your comments are of course welcome.

I am NOT asking what is or should be in the Scrum Guide. Or whichever 'scrum bible' you use.

I am just saying what my thoughts and experiences have, together, taught me.  I want to discover just what is most effective for 'pretty good' Scrum teams.  (Maybe not best for super teams or for beginner teams.)  So, I am trying to have a conversation -- maybe about what to add to Scrum -- not a religious war.

OK.  My views expressed too quickly:

1. The PO is very important to success.
2. Understanding business value and understanding detailed 'requirements' is very important to success. Both these 'activities' are extremely difficult.  Both for the PO and for the Team.
3. Knowledge creation as a full team is very important. In multiple domains. All domains impinge on all other domains. (Key example: cost-benefit analysis.)
4. The full Scrum team delivers the product. Each provides his unique skills and ideas and creativity.
5. The PO is definitely a member of the Team.  Given real life, often 100% of his time is not enough (see also #7 below).
6. The only team that matters is the full Scrum Team.  It is this team that self-orgs, most importantly. (Yes, every person, pair, teamlet self-orgs....not the most important aspect of self-org though.)
7. I do not think it is useful to talk about a team within the team. (I hardly ever say 'Dev Team'.)  Talking about a team within the team  creates an us-them attitude. And anyway is not useful. And at first at least, a bit confusing.
8. The PO must spend a lot of time with 'people outside the team'.  I will call them, at times, customers. managers, business stakeholders, etc etc.
9. Still, the PO should attend the Daily Scrum as often as possible (by phone if not in person).  And should answer the 3 questions. His work affects the output of the Team.
10. The simplest example is: On Day 1, a question is asked by the coder. On Day 2, the PO can give the answer (or at least say 'I got the answer') in the Daily Scrum.
11. If the PO does not do the Daily Scrum (ever), I think most team members start to think or feel (sub-consciously): "who is that guy; he is not part of the real team".

OK.  This is my experience.  Maybe limited experience.   Maybe just bad thinking.

Imagine that you disagree.

Where we differ, I expect my main reaction or push-back would be: "Well, I can see that happening, and it has happened to me, but I think we should coach them to be better, and often, if we coach them to be better, they actually will be."  Meaning for example: They can do the things above, and it will make them at least a bit better.

Certainly some of you have done different things and been successful.  But could you have been more successful doing it this way?  Or might 'my' teams be more successful doing it your way?  This, to me, is the question.

Again, I am not sure I would coach all beginning teams do it this way.  I am sure some super teams might be more successful another way.  My inquiry is: For most 'good' (but not super) teams, which is the best way to do these things? (PO, Team, Daily Scrum)

Of course, there are many other things in life and in Scrum than just the 3 things I discuss above.

BTW, while what I am saying above is not exactly how it is described in the current Scrum Guide, I do not think it is contrary to what the authors would want.  But it may be more than 'the bare Scrum framework'.  The minimum that they want.

Self-organization

We have this idea in Agile, that the Team should self-organize.  This is an important idea. And also an important occurrence (eg, the reality precedes the idea).

In Agile, self-organization is compared to command-and-control.

We think self-org is an important thing to study, both in general and in your Team.

Why

Well, one, because it is just right.  People are free, and self-organization is saying that the Team is allowed to be free.

I guess this needs to be explained a bit.  Some will say: well, the company has bought their time as employees, so the company gets to define what the Team does.  Well, let is concede this at a high level; let us say that the company may define the vision or the goal or the general product.  Perhaps even the user stories.  The Team members are not slaves, but we can assume that, as employees, they agree to do the company's work for pay.  A contract.

But, devising the work, figuring out how they will get to the goal, they should have the freedom to do.

The second main answer is: self-organizing humans tend to do better work than human 'slaves' (humans directed by one or a few command-and-control people).

There is lots of evidence of this. The first book I recommend is The Wisdom of Teams by Katzenbach and Smith.  This is a rather old book.  But the basic evidence is that a self-organizing team out-performs, almost always, an individual.  And to such a degree that the extra cost is well worth it.  But, you must given them some degree of 'freedom'.

There are also a lot of more recent evidence.

Some topic you may wish to research:
Self-organization
Complex Adaptive Systems
Maneuver Warfare
Free Enterprise
Knowledge Creation

Note: Some people say that a free enterprise system is mainly characterized by (mostly) private ownership of capital (means of production). And attribute its successes or failures to that. Others focus on the freedom of individuals to make their own decisions (much like the "wisdom of crowds" idea) and on the view of the national economy as a complex adaptive system, trying to accomplish high-level economic success via many individual agents (people or companies) making their own decisions.  In our view, successful free enterprise countries exhibit many of the successful characteristics related to self-organization.

Command-and-Control Managers

Lots of managers have been taught, explicitly or implicitly, that the 'workers' are dumb, and the manager must tell the worker how to work.  In our view, especially for virtually 100% of knowledge workers (our domain), this is very very incorrect teaching.  But it is nonetheless, what they have been taught.

Now, some of them also understand freedom to some degree, and understand that they want the people in their group to 'think for themselves'. But, we can say with relative assurance, most companies have a lot of people who are relatively command-and-control in their style.

And, in pressure situations (our common situation), they want to use too much command-and-control.

Again, this is not true of all managers, but of many. It depends, in part, on the company's culture.

It is hard to convince these people to be patient for self-organization.

Teams that won't self-organize

This is seen in real teams.

There seem to be several root causes. One, the team has been beat down by command-and-control managers so much, that they have 'forgotten' how to self-organize.  Another: that they Team does not believe it when managers say 'self-organize'.  Another: The Team is fearful that by self-organizing they will be 'held accountable' with punishment a likely outcome.  To avoid pain, they refuse to self-organize.

Whatever the reason, two things can be said.

Many Team (perhaps with Agile coaches) do eventually break out from being 'stuck' (not self-organizing).

And some Teams may take a very long time or perhaps never do it.

The key advice is this: If the Team will not self-organize, or seems to want to self-organize to mediocrity, then a good manager should intervene.  Temporarily.

Perhaps prior key advice: Be patient. Often Teams will self-organize in two or three sprints.  Keep talking about it, and ask them if they need help.

Third advice: In the view of some (including me), some Teams lack some key skills to self-organize. For example, a new junior Team may not know really how to break down work into tasks for the sprint planning meeting. Sometimes 'holding their hand' as they mature is a very successful approach.  And 3 or 4 sprint later, they can be very good at self-organizing their own Sprint Backlog.

Learning to decide as a Team

I think each Team learns how to decide.

The first, most useful thing, is that everyone in the Team gets to offer input on a decision.

Next, the Team needs to accept that no decision is ever perfect.  Thus, decisions in general must be made, perhaps not always quickly, but promptly.

The Team needs to understand the impact of decisions on the morale of the Team and on the success of the Team.

In our view, most teams go through a forming and storming period of decision-making.  And then later get better.

Good self-organization... and better

Lots of Teams seems to self-organize well.

What is also common is for most Teams to plateau.

In part, we may say that a root cause is that most Teams want to reach a stasis... a place where things are balanced and where change slows down.

But have they reached the height of improvement?  We think not.  Some Teams have reached much higher heights.  And some Teams keep on improving.

There seem to be two main factors (or sets of factors):
* magic -- or, more accurately, a bunch of things that are hard to describe.
* a bunch of factors that people talk about, and some teams study and work on

Some of these last factors seem to be quite 'soft'.  Love, listening, creativity, heart seem to be among them.

Lastly

If you have never been on a good team, it is hard to understand what self-organizing is all about.

Within the Team, it might be rather rough and ready. But a lot depends on the specific individuals in the Team.

Self-organization

Some smart people are discussing self-organization on the Lean Software Development yahoo group. You might want to listen or talk there.

Here is what I said today:

****

First, we must recognize that self-organization happens willy-nilly all the time. The only question is when does it start, and where or why does it stop. (Thanks to Tolstoy and War & Peace for explaining this to me. And I am not just a slow learner; it's a great book in many ways.)

That is to say, whenever a 'boss' gives someone an order (big or small), that person must figure out how to do that (assuming they agree to do it... lots of self-organization very smartly ignores the boss' stupid orders).

At a high level, an 'order' could be an initial vision of a product: "We need a hybrid car pronto...figure it out." I think none of us would call that command-and-control, but it could be called an 'order'.

AND...with a Scrum Team there are rightly times and places for them to say "geez, we don't know what to do next, can someone help, please?!!?" Not exactly classical self-organization.

Yes, self-organization is magical and is changing all the time (to a lessor or greater degree). But it is quite real and indeed happening all the time. And we all have many experiences of it.

Now, when asked, I don't think that a 'capable team' that kinda sorta wants to do the work will ever refuse to self-organize. Assuming they are not dysfunctional also. From their background (company culture), they may at first not believe the request to self-organize (how did the manager allow that to happen??). But after a Sprint or two, I have always seen them self-organize.

And I have seen more than one mediocre team need a manager's 'nudging' (that's the official term) to get them started. This is partly because they are relatively inexperienced, not used to power, and not used to being in the project this early in the process. It feels odd to them so they feel unsure what to do. But, once started, they self-organize pretty well.

Now, one more thing must be said or asked. Will a team of 7 always come up with the best solution on their own?

Asked that way, I think it is clear the answer is No. Even if they give themselves some feedback (eg, the Scrum demo). So, the Team should be encouraged to ask for more feedback and advice. And indeed, there is room for managers to provide leadership. It might be called 'coaching' or something else (so that all of them are less likely to fall into command and control). But,
despite what some agile people say, what I see is that smart and good managers have a real role. (OK, yes, there are fewer of them than we want. Agreed.)

And that these good managers are not contrary to self-organization at all. Once mutual respect is built up (and, as Taiichi Ohno might say, mutual humility: "Half of what I know is wrong" is pretty close to his quote).

Spontaneous Order

I will not remember this well (knowledge decay), but there is a great quote from Fujio Cho (now Chairman of Toyota) at the beginning of Liker's The Toyota Way. Something like: "There are many things you do not understand, and therefore we ask you, 'why don't you just take action? Try to do something.'" With the idea that you thus cut the gordian knot of inaction, and start real learning.

What happens if we do not? The opposite: "And thus the native hue of resolution is sicklied o'er with the pale cast of thought."

And enterprises of great pitch and moment
With this regard their currents turn awry
And lose the name of action.

I have been in projects like that, and so have many of you. (These last two quotes are from a play, not Fujio Cho.)

The soft spider web of thought can be the hardest, most granite-like roadblock.

Yesterday I finished helping to teach a Certified ScrumMaster course with Jeff Sutherland. So, a couple of related thoughts from several conversations.

1. Spontaneous Organization. In the agile community, we are fond of self-organization and complex adaptive systems. And these ideas go way back. Chuangtze and Laotze taught us that the Tao that can be expressed is not the true Tao. That Tao organizes itself in things great and small. And Chuangtze especially talked about the spontaneous organization of things, nature, people, society. That if left alone, they would move toward Tao; that human meddling would more likely move them away from Tao. Better that they take on that more perfect imperfection of Tao, he seemed to say.

Like many another idea, these ideas were picked up later by others, by Proudon and Hayek for example. Tolstoy speaks of this when he talks about the hive of Moscow after the battle of Borodino in War and Peace. We see this in the things of nature, where Energy and Mass self-organize at the speed of light. (OK, perhaps a play on Einstein.) But there is a natural organic spontaneous organization of things.

Now, in real life, that spontaneous organization might be at a mediocre level or a hyperproductive level. The ScrumMaster may have more influence over this fork in the road than she has accepted yet.

I suggest to you that the ScrumMaster, at least, think deeply on how to put these mere thoughts into action for each team. And stir the pot gently. Maybe start here: http://en.wikipedia.org/wiki/Spontaneous_order

It is by spontaneous order that free enterprise gives you your daily bread. However much we may say (and it is true) that man does not live by bread alone, still we must have bread.

2. The ineluctable contradictoriness of things. We humans have this wish for things, for life, to be simple. And so in some ways it is indeed. "A kiss is still a kiss." But we are everyday forced, if we allow our eyes to see, that in so many things there are contradictions. Male and female. Good and bad. Black and white. Darkly wise and rudely great. Go fast slowly. Achieve by not trying. I must be cruel only to be kind.

Sometimes we see through the glass, darkly, that these contradictions do not need to ensnare us, but rather they give us balance.

So, for a pedestrian example, the ScrumMaster should be a servant-leader. The Team should use velocity to push back at the magical-thinking managers who demand they double output; and the next minute demand of themselves that they push velocity to hyperproductivity. From a certain point of view, these can seem utter contradictions.

In theory, we may think these contradictions should make us fail; in practice, done well, we come to know they do the opposite.

Perhaps a few of you will find the famous Butterfly Dream (see that link) an apt koan for the harmonious contradictoriness of things. Chuangtze has other, perhaps better, stories that deal with this.

ScrumMasters: They can cut through their mental spider webs in a minute. Or in two years. You can be a key difference. This is your great refactoring work. Find that sharp, swift, gentle, liberating sword. And pull it out.

Shock Therapy

Back in September, Jeff Sutherland spoke at the Googleplex in NYC.

Topic: Shock Therapy. Also called: "Self-Organization: The secret sauce for improving your Scrum team".

About 90 minutes.

Here: http://www.youtube.com/watch?v=M1q6b9JI2Wc

Recommended.

Summary: Shock Therapy is a technique for a special and experienced coach to work with a Team to help the team boot up so that they can self-organize to a better life and hyperproductivity. Like many things in Scrum, it sounds paradoxical, but is not in practice.

Self-Organization in Scrum

Last Thursday, Sept 4, 2008, Jeff Sutherland gave a talk on Self Organization in Scrum at Google in NYC. The talk also covered some of the associated contradictions (or perhaps, seeming contradictions).

Here are the slides from the talk. Google video to come soon.