Blue pill and Red pill

In a class in Romania, a participant asked me: "don't you think you are setting false expectations? Scrum may help but it will not help that much. This sets false expectations and disappoints people."

Good comments. Good concerns. But I don't agree that we are setting false expectations, although I think these issues must be addressed.

As background, I said that we want each team to increase their productivity by 5 to 10 times. And we want that by working normal, sustainable pace. And with everyone (as far as possible) having more fun. And we want to double productivity in 6-12 months.

Now, this assumes that we get aggressive about removing impediments. Creative in identifying them. That we make a good business case for many of them. That we act rigorously and professionally. And that the managers and the firm permit us to fix things, if we make a reasonable business case.

I admit these the managers often don't let us fix enough impediments.  Sometimes almost none.  But usually the biggest problems are elsewhere.

So, if someone has managers who won't let us fix impediments readily (and yes this situation exists in the real world some), I still expect them to try to fix things. Yes, it will be harder, and maybe it will be hard to double productivity.

And I think a lot of 'bad' managers are just decent people and they just need someone smart like you to help them see the light.

As another partial answer to his question...

It helps to tell the truth even when it is hard. And I think adults should not lose heart even when things aren't good and the path forward is unclear. In other words, adults should not get discouraged.

Scrum does not believe in taking the Blue pill.

For those who have not seen the Matrix movie in a while, let me remind you. The Red pill means that you can see the truth, and it is painful and hard, but you have a chance at freedom.  And a chance to fix things.  The Blue pill gives you 'happiness' as the Matrix would like you to see it, with a blue filter.  But it is false and it is not the truth you are seeing. And freedom is not possible. You give up freedom for a false 'happiness.'

So, people can and do complain that Scrum makes them see bad things. And, so far, Scrum compared to waterfall, does do that.  You do see more 'bad' things using Scrum.  Because Scrum makes them visible (not because Scrum causes them to exist).

Except that seeing the truth makes it easier to fix things.

The next thing to say is that Scrum, after everything, is still more fun than waterfall.  Well, if they play real Scrum.

Selling the benefits of Scrum

Two other CSTs (scrum trainers) made some comments in a Google Group, which got me thinking.  They reminded me of the following exercise I normally do in my Scrum classes.

Every class is different, but imagine a class that is mixed. Some people are new to Scrum, some have a few months experience, some have 9-24 months’ of experience.

And a recent experience makes me think I should modify the exercise. A bit.  I have to say explicitly: “If change is going to happen, you must ‘sell’ Scrum. In some sense of the word sell.”

I show a slide listing all the benefits of scrum.  ‘More Fun’ being one of the big benefits. In all, 6 or 7 benefits…
I then ask the class:
‘I need an estimate from you. Each of you.  A single rough percentage.  On average across all these factors.
If on Monday you start with one team, maybe your real team, and you get to work with them for 1 year, after all that you learn in this course and your hard work in applying it over 1 year, in removing impediments over a year — how much better will the Team be, after one year?
Using whatever weighting you want to use on these (pointing to the slide) 6 or 7 success factors.
So, George (first person) what is your number?’

And then I go around the room.

I get a wide range, sometimes.  Usually a bunch of low numbers.  0% (rarely), 10%, 15%, 20%, 25%, 30%…sometimes 80%, 100%, 150%, 200% (rarely).  As you might guess, almost always many more low numbers than high numbers.

Usually I end that segment with the Henry Ford quote: “Whether you think you can or you can’t, you’re right.”

***
In the past, I have been asked to ‘sell’ in several different contexts. And it has usually made me uncomfortable.  So, why am I asking us all to sell now?

It is simple. Change makes people uncomfortable. Unless they see a real reason to change, they will not change. 

For example, the company culture will not change.

So, to get change to happen you must ‘sell’. In some sense of the word. And sell in a compelling way.

Now, I know from experience that the benefits of doing Scrum properly are tremendous. So, obviously, we want everyone to experience those benefits. But it starts, as John Kotter says, with a sense of urgency.  And that means we, who understand Scrum, must be continually ‘selling’.

Now, selling to me does not mean: fakery, lying, exaggerating, forcing people to listen, etc, etc.  By ‘selling’ I mean giving people a chance to have, or to have again, that sense of urgency for the change.

Change: “You miss 100% of the shots you never take.”

Change: “You miss 100% of the shots you never take.”

This is a quote by Wayne Gretzky.
I am flying to Canada now. And I like hockey.

Today the quote reminds me of how hard change is.

To make any change happen in an organization it is hard.  Takes a lot of energy.  Takes a willingness to miss a shot, to make a mistake, as Gretzky says.  That takes guts.  Most people don’t have guts for things they don’t really really care about.

Why is it so hard?

First, I think organizations are mainly there to remain ‘static’.  A company is there to preserve the situation.  Yes, yes, of course any corporation is building things or providing services for its customers.  So, a kind of change is happening all the time.

But the main idea of the corporation is to assure that the basics are there every day.  Regular, unchanging.  The building is there, its warm (or cool), the lights are on, the processes are known, you know who to go to, etc, etc.  The same.  Every day.  Despite all the other things in the world that are changing.

And people want that.  They need that stability.

Second.  While people actually like some change, some degree of variety, still…

Still they don’t want to be changed.  They don’t want to be the helpless pawn of some brilliant change that I (the great and wonderful Oz) am bringing them.  No one wants to be a helpless pawn.

Also, there is too much change these days.  People are tired of it.  Why was everything stupid yesterday, and today, again for the 1000th time, we must change everything?  Too much (damn) change!  Stop it!

And you can feel this yourself, and see that it ties back also to that helplessness.

Still, people like change, they believe in improving their situation.  So, if you can tie your idea to that inner feeling of progress, then they will want the change.  Want it, at least to some degree.

Third, politics.

By this I mean the messiness of dealing with people in groups.  The hierarchy, the power, the games. So, with any change, we must ‘play politics’ to some degree. Very bothersome for most of us.

So, where am I going with this?

To this idea: That one must be very motivated if one is going to start to make a significant change in an company (or many organization).  Very motivated.  Otherwise, one is easily stopped by all the barriers to change.

Kotter calls this motivation a sense of urgency.


***
I recently had an in-house class.  And I was teaching them Scrum.

And most in this class found some aspects of it ‘impossible’.  Meaning, that most of them did not think they could get the culture in their company to change that much.

My initial reaction was an inner anger (not shown outwardly).  Anger that they in effect wanted me to change Scrum.  Anger that these very talented people would let so much potentially good change go by, ‘merely’ because they thought that such as change was ‘impossible’.  I say this in part because I know that people — less talented than these people were — have made this kind of change happen. And against odds equally as great.

But, looking back, anger is not good. And also not appropriate.  They don’t owe it to me to change.  And my getting angry that they can’t see the benefits and push through to get them, for themselves, my being angry about that, well, it is sweet and all, that I want them to have a better life, but also kind of silly.

Now, later I am reading Fearless Change by Mary Lynn Manns and Linda Rising.  One of the change patterns in the book is Personal Touch.  I start reading that pattern.

Aha!

I got two big flashes of insight.

First, most of the people in that group do not value the change in the way I do.  And they have no reason to.  They had no experience of its real success.  To them, it was just ‘Joe talking’ — maybe sounds good, but no inner conviction yet.

Secondly, every one is different.  One has to explain the change to each person, slowly, and help them come to see that it will benefit them (or even, that it has benefited them).

So, once you have helped someone care enough, gotten through to them in some unique way, then you will see someone who will make change happen.

Someone who will take many shots, and happily miss many.  Knowing that eventually they will win the game.

We band of brothers

“We few, we happy few, we band of brothers.”  A great speech did Shakespeare write.
Here it is explained. The leadership in the real field of battle, against great odds.  You may find this interesting as well.
Here it is enacted. Kenneth Branagh. You may wish to go to about 2 mins 20 secs in.
A bit later King Henry speaks:

We are but warriors for the working-day;
Our gayness and our gilt are all besmirch’d
With rainy marching in the painful field;
…
And time hath worn us into slovenry:
But, by the mass, our hearts are in the trim;

You may perhaps recognize yourself in this situation: that time hath worn you down, yet still your heart is in the trim.
Enjoy!
And may your Team have its heart half so much in the trim.

6 Myths of Product Development

I was going through the articles I have, and this one struck me.  A HBR article by Stefan Thomke and Donald Reinertson.  Reinertson is known well in the lean-agile community.  And it is an excellent article.  Go here to buy it for $6.  Well worth it.
Here are the myths or fallacies:
1. High utilization of resources will improve performance.
By ‘resources’ they mean mainly people. Speed of delivery is much more important.
2. Processing work in large batches improves the economics of the development process.
Hence, small stories in small sprints. And get fast feedback from business stakeholders.
3. Our development plan is great; we just need to stick to it.
For many reasons, during the course of ‘development’, the needed features will change. Hence, the plan must also change.
4. The sooner the project is started, the sooner it will be finished.
Reduce WIP.
5. The more features we put into a product, the more customers will like it.
Deciding what to omit is as important as deciding what to include.
6. We will be more successful if we get it right the first time.
Demanding that teams “get it right the first time” just biases them to focus on the least-risky solutions.
***
This article is good in helping managers see what lean-agile-scrum is all about.

Radical Management

Steve Denning has written a great agile book for managers, called The Leader’s Guide to Radical Management.
Here are the five principles:

• A shift in goal from making money for shareholders to delighting customers through continuous innovation.
• A shift in the role of managers from controlling individuals to enabling self-organizing teams.
• A shift in the way work is coordinated from bureaucracy to dynamic linking.
• A shift in values from a preoccupation with efficiency to a broader set of values that will foster continuous innovation.
• A shift in communications from top-down commands to horizontal communications.

I recommend the book.

High Interrupt Work in Scrum

Imagine that you have a lot of new work, high priority new work, that gets identified every sprint.  During the sprint. 

In other words, you don’t even know about many of the stories or issues or tickets until after the Sprint Planning Meeting.  A support team is a classic example of this.

How do you organize things in Scrum to handle this?

First, question whether all the so-called high priority work is really high priority. It often is not.

Second, go to the root causes of why the high priority work is being identified so late. Example: If the quality is low when we release to production, let’s fix the quality issues (maybe caused by lots of interrupts to the Team).

Third, shorten your sprint length.  Maybe from 4 weeks to 2 weeks. Or from 2 weeks to 1 week.  Note that the so-called Scrum overhead of the meetings adjusts proportionally to the sprint length.  So, it’s a 4 hour (max) Sprint Planning Meeting (SPM) for a 2 week sprint, and a 2 hour SPM for a 1 week sprint.

Fourth, in the SPM set up a box of velocity, say 5 story points out of your total velocity of 20, for ‘to be discovered’ work.  The PO has to manage the usage of the box against ‘tickets’ as they arrive.

Fifth, as an alternative, substitute items. Example: Plan for the full 20 SP, but if a high priority ticket comes in, substitute that 2 SP ticket for the 2 SP story at the bottom of the Sprint Backlog.

That means: We have the Sprint Backlog items in priority order.  We complete them in priority order.  And we story point each new ticket. Just as we have story pointed each user story we took into the sprint backlog.

Principles

What are the key ideas behind all this?

Minimize disruptions. It is demoralizing and wasteful for the Team to be disrupted. It may still happen, it is part of life, but the Team and the firm should try hard to minimize disruptions.  And explain any disruptions that remain. Making the Team ‘happy’ is not the sole and only value in life, but it is important.

Mura.  A lean principle (Japanese).  Mura is the negative, the lack of an evenness of flow.  So, we want an even flow through the system. This is reflected, in part, by having all the Product Backlog Items in a Sprint Backlog have about the same size.

Muri.  Another lean principle (Japanese), in the negative. Over-stressing the system. And this never helps. (It does help to challenge the Team. Idea to discuss in another post.) Never ask them to do more than they can in a Sprint. It only reduces their capability. But, after they have completed everything they ‘committed to’, then they can start another story at the end of the sprint.

Do the most important thing first. (Enough said.)

Understanding business value is difficult. So, in this case, just because someone says this new ticket is very very important, we do not have to believe that person. The Team should judge for itself, based on benefit/cost ratio and other factors, whether that items deserves to ‘interrupt’ the sprint backlog.  Many contribute, and if the decision is not obvious, the PO makes the final decision. Note: The main thing the PO is trying to do is maximize the business value out of the Team.

Scrum and Kanban

Some people have recommended that you use Kanban for high interrupt work.

I do recommend Scrumban.  Where Scrum and Kanban are combined. Much as Toyota uses Kanban within the broader context of all the Lean ideas and tools.

I recommend converting the basic Scrum board (which already includes Kanban board ideas) into a fuller Kanban board. Once you have some good experience with Scrum. A good Kanban board executed well by a strong Team: that’s a wonderful thing.

Now, setting up a truly good Kanban board is hard. The best Kanban boards have high requirements, and are not suitable for many situations. A beginning Team or a difficult situation may well be better served by the basic Kanban board in the normal Scrum board.

And, especially in this case, with lots of high-interrupt work, you should want to convert the Scrum Board into more of an advanced Kanban board sooner.

I do not recommend ‘Kanban’ as I often see it played ‘out there’. Where we have groups of people, not Teams. Where there is no time box (no sprint). Where there is no Sprint Planning Meeting, no Sprint Review, no Retrospective, no Daily Scrum.  No roles, no artifacts. (Or, if they have a few of these, they are much too weak.)

***

Do these comments help? Your comments please.

Do high benefit/cost work!

Tom DeMarco wrote an article a while ago: “Software Engineering: An idea whose time has come and gone?” (2009)  I guess I am just catching up on my reading.
One topic is: are metrics useful.
I think the real issue is: how useful is it that we ‘control’ projects?
His comparison is:
1. If we have a project that probably will cost $1 million and returns a benefit of $1.1 million, then we must control cost carefully. Or the project will be underwater.
2. If we have a project that probably will cost $1 million and returns a benefit of $3 million, then some variance in cost is not important.
His contention (and mine) is that there is plenty of work in category 2.
This does not mean have no budget and do no planning. It just means that we should not look at planning and control as the main drivers of success. The main drivers are: identifying the problem well, and delivering a truly innovative solution.

Agile Release Planning booklet ver 1.08

Here is our latest Agile release planning booklet: “Joe’s Approach to Agile Release Planning.”  31 pages, including a table of contents.  Free now. PDF format.

Some ideas or explanations are included, but mostly actionable steps.

Feedback welcome.  jhlittle@kittyhawkconsulting.com

The term ‘release planning’

Mike Cohn has a good blog post about this, here.
I will agree and then slightly disagree.
Release Planning I think should normally mean planning the next release.  So, as Mike says, we are looking ahead a few sprints (1 or 3 or 10 or …), to get an idea what features we expect to include in that release. Or to see if the features we ‘need’ to release can be released by that date.
In agile, we assume nothing is fixed. In the sense that everything has some degree of negotiability. If it needs to. And we assume that everything changes, nothing remains the same. As the Buddha said 2000+ years ago.
But, when I (and others?) use the term we mean something a bit different.
We mean a set of tools and techniques, and a way of thinking, about how to plan the product.  Short-term and longer-term. And how this planning will feed the sprints (where we have ‘sprint planning’).  We do ‘release planning’ to feed the sprints.
‘Garbage in, garbage out’ we have heard many times. So we are trying to feed good stuff into the sprint, so that good working product comes out of the sprint.

***

I have to agree with Mike completely on this: More people are releasing faster now. Often every sprint. This is great, almost always.
So, does ‘release planning’ go away?  Well, the same tools and techniques may not be needed at all in some situations. This is true.
But usually, most firms have a lasting, evolving product. So ‘release planning’ (where you have one or more releases every sprint) becomes ‘product planning’ over multiple releases. And essentially the same tools, techniques and ideas apply.  ‘A rose by any other name would smell as sweet’ as Shakespeare said.
Do I want to stop using the term ‘release planning’? No. Because it is still useful to most people, I think.  But more and more I want to discuss the issues mentioned here, when I use the term.
For the longer view, Jeff Sutherland likes the term ‘product roadmap.’  He thinks most firms need a product roadmap that gives them an idea how the product will likely evolve over the next 12 months (some products less time, some products more time).  This seems like a sensible idea to me.
***
Guarantee, predict, estimate, commit, forecast.  Be very careful with these words.  Or similar words.  Do not mis-lead or mislead people.
‘To predict is difficult, particularly of the future.’ This was said in Latin some 2000 years ago. And remains true today, maybe more true.
Managers: It will not help you to drive a ‘death march’ or anything like it. Not to mention that it is immoral. They are not your slaves. Almost always, if you think they are lazy, then you have been too lazy to work with them closely.  Almost always, it is your fault that their work situation is so disrupted that they can barely get anything across the goal line for the customer.
Workers (if we may divide the world into managers and workers): Do not say things that the managers can easily mis-understand. Tell the truth. ‘No’ is often the right answer. Do not use weasel words that, to you, mean ‘no’, but to the managers are often heard as ‘yes’.

Kent McDonald on Release Planning

Here is a good article on release planning. Includes a video.

Enjoy.

2012 Agile Dev Survey

Once again, agile and scrum are making more progress in the real world.
Is the world all rosy now?   Well, that depends.  Compared to yesterday, at least in terms of Agile, I think we are better.  Compared to where we could be, we have such a long way to go.
People still too much like central planning.
People do not understand well-enough the power of a Team.
Many managers have no clue about self-organization.
And yet, despite all, and despite some backwards moves, we still make progress.
Look and see here…
It is a survey, it is not science exactly, but it does say and mean something.