The Daily Scrum - a question

Srinivas sent me the following note:
"Thanks to Joe and all of the attendees – I have learned a lot from all of you. I have a simple question – in the daily scrum meeting – if I understood it correctly, team members are expected to answer the 3 questions to the team – and not the scrum master. Yes? How did you get them to do it? What I am finding is that the members are reporting to the scrum master."

Here is how I replied.
Yes, the 3 questions are answered by each 'pig' (including the Product Owner). To the whole team, not to the SM. (We don't need to get too concerned about exactly where the eyes look, as long as the attitude is right.) The SM is the master of ceremonies of the meeting...trying to keep it good, to the point, quick, useful.

Explain the purpose: To give the team members enough info each day to make mid-course corrections to 'land' all the promised stories by the end of the sprint. Everyone can help make mid-course corrections. Of one sort or another.

To stop the behavior you mention, sometimes the SM has to remind them to report to the team. Remind them of the purpose. And sometimes avert eye contact. And sometimes step 'outside' the semi-circle of pigs.

If the SM is the former Project Manager, this is a hard switch for everyone, since the habit of 'reporting' to the PM may be well engrained.

Help enough?

Responsibility

In my last post, I talked about responsibility. Or mentioned it briefly.

As I was walking my dog today, I was thinking of what I would say. And I thought of the famous line from that movie: "I'm mad as hell, and I'm not going to take this anymore." (Network) [This is a rather complicated allusion, so apologies to those expecting a simple one.]

So, if we are free, we have to also acknowledge our duty, our responsibility. This is an ancient concept in all cultures. Freedom to be completely irresponsible is not a thing any civilized person wants.

At the personal level, responsibility means first we must take care of ourselves, without violating the freedom of others. And take care of our immediate families and friends.

But, and perhaps in this season and in my culture influenced by Christ, we may say responsibility joyfully also includes: It is more blessed to give than to receive. More broadly to our, as it was quaintly phrased, to give to our neighbors. To those we know but have no real connection to.

In business this may seem a paradox. And for me for most of my life this seemed hard: That I should give more than I get. But it does not say that. To me it says: by focusing on the giving, you actually receive more. Not unlike what Peter Drucker said (that the purpose of the firm was to serve the customers).

Receive more of what? Ah, yes, of the more valuable things. Let me leave it at that. No doubt in some way you have experienced this.

Business is a wonderful transaction, where each side gives less than he gets. One side pays less than the object is worth to them. And the other side gives up a (to them) less valuable object (or service) for the money they need more. It is wonderful magic. The magic of freedom, and free enterprise.

So, what am I mad about? I look about me and see, so plainly, so much imperfection. So much want. So much need. So many tears. So many who deny such large parts of their full humanity. As though life or the world is so dreadful, they must hole themselves up inside a 'resource' that is barely more than a thinking machine that drinks coffee. They willingly give up such large parts of their full humanity. I too have done this. We are so much more than we have yet become.

So, if you are a little bit free, if you have a little bit more of material wealth or perhaps that greater wealth, confidence that in life (as in death) all will be well if we stride confidently toward our dreams, then you have the responsibility to give that to others. Make them more free. Make them more confident that they can make of their own lives a better life. And themselves do that too, for others. Not abstractly, but one moist, shaking, confused, imperfect, animalistic, feeling, breath-inspiring, mistake-making, incompletely understanding child of god at a time. Make ready one person waiting to shine as the paragon of animals. This is where the real value is.

Now, I am not against money and business. Far far from that. I believe in money, as one of the more useful illusions of man. But money and business were made to serve man, not man to serve them. I am speaking now of the music that plays beneath all the MBA stuff you may have learned.

You have the responsibility, as you well know, to serve a higher purpose.

I do not sound this call to ask you to make an unreasonable sacrifice, which would most likely be only an ego-trip. No, within the real humility of your real self and station, neither too high nor too low, you can do more easily. If you put yourself in the flow of the truth and the way. Easily. If you stand upon the truth, and act in concert with your friends and colleagues, the world cannot resist you. Fearsome as it may seem sometimes, it cannot resist you. We have so many examples, do you need to hear them again? I will mention, as one overwhelming to me, the falling of the Iron Curtain in 1989.

So, this is our responsibility. To act somewhat more greatly than we have till this day. And yet to recognize that even our enemies are our friends. Fight them if we must, but fight them as a way of saying they are worthy of our fight. They are humans who deserve the help of correction.

The first shall be last. And the greatest wash the very feet of their friends. These seem paradoxes, but the wise know that strongest action comes from quietness and balance. You can do it.

Perhaps you do not like, or do not feel called to be responsible to, the purpose I have tried to articulate. No mind. Articulate for yourself and others a yet better purpose.

PS. For those looking for concrete agile ideas, see the next post on Sprint Planning. (Although the ideas in this post really are also agile ideas you can act on.)

Freedom

We have written here about freedom before. But, as Rousseau said, man is born free and everywhere is in chains. So, it is a topic that bears repeated discussion.

In business and in life, too many people want to think that they own other people. Other 'resources' or whatever they may call these people. These owners might be managers, generals, admirals, spouses, older brothers.

The more correct attitude should be as a manager or as a person: 'Thank you for graciously allowing me to work (or live) with you."

No one owes us anything.

Yes, I know it is hard to accept. But there is no amount of anything that we 'gave' them that makes them our slave.

Not an employee, not a spouse, not a friend, not a child, not anyone. They always have the choice to work (or live) with us or not. We never, in any way, own or command them.

(Yes, perhaps in wartime, it may be useful for the commander-in-chief to command from time to time. But almost always, according to good military ideas, it is setting a mission rather than commanding a specific action. Cf. Maneuver Warfare in Wikipedia, as one example. Thus, even in this situation, there is much scope for freedom. And few are the successful generals who lead troops that do not choose (freely) to accomplish the mission.)

Least of all should we contravene their freedom for their own benefit -- for our view of the 'benefit' for these employees (except perhaps for children who are 17 or less).

We have to respect that God, in his infinite wisdom, has given them their freedom (and given us our freedom). And allowed them to make mistakes (and us to make our mistakes). And we have no right to control what God has made free.

Now, this does not mean we can not give our friends advice or our employees (or others) advice. But, real soon, if they don't take the advice, we have to let them be free. Leave them alone, as we say.

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

Meaning: They will do what they want. And they won't do what they do not want to do (what we wish to 'force' them to do).

It may seem like a traffic wreck to us, sometimes, but we have to let them do it. Often we (who think we are so smart) are wrong. It does not become a traffic wreck at all. Sometimes we are right, that it does become a traffic wreck (of some proportion). Usually even that actually ends up good -- they learn from that. Far better learning than what would have come from our so-called brilliant advice.

So, if your team trusts you, from your actions in removing their impediments perhaps, trusts that you actually care about the team, then, surprisingly, they may actually listen to your advice more. But you have to accept, as a manager, that it MUST be only advice, and not a command.

Sorry! It seems so much harder than just commanding.
In fact, it is so much better. (So, the 'sorry' is retracted.) Even for you as a manager.

Many are the men who bob their heads, saying by that action that they believe in freedom, perhaps even that their lives are dedicated to freedom. And then in the next hour they try to abridge the freedom of another. 'As you from sins would pardoned be, let your indulgence set me free.' I too of course have made this error; and so I can forgive.

PS. Not only is freedom still to be learned by those who wish to command. Equally we who continue to be commanded must learn that we really are free, and we cannot put up with abridgments of our freedom. This is the path that humanity has been on for only a millennium or perhaps two, so we still have far to go.

PSS. As soon as we talk about freedom, we must immediately speak of responsibility. It seems paradoxical, but it is not. On that topic next post.

How I teach - 1

For those who will teach and for some puzzled course attendees, I want to do a series of posts about how I teach.

First, the goal is not to teach. Or, more clearly, the goal is neither teaching nor learning, but results (ie, more than just action, but actual results from action). Results for you, for your team, for your customers. That is the only goal that counts.

If you think I 'fail' as a teacher, and yet you get results...to me I have succeeded. Such 'failures' I will take any day.

OK, so I conduct the class in such a way as I think best will lead to the most results for the most people.

Right away you see certain 'philosophical' or fundamental issues have been addressed with certain assumptions. Assumptions that we have developed over many years of experience, but assumptions nonetheless, as we are far far from omniscient.

For example, we don't assume that everyone is the same. (In fact, closer to the opposite.) Nonetheless, at any moment, in overly simple terms, only one style of teaching is going on at that moment.

Second, I don't assume that the brain is the most important part of the human being. The soul, the spirit, the heart, the guts, the will, and many other parts are also important. There is increasing evidence that they are more important. At least in terms of real results.

Third, we have a theory, based partly on Piaget and others, that the mind resists changes to its fundamental constructs of the universe, of how 'things work'. And we have a theory that lean-agile-scrum is a fundamental paradigm shift in many of these constructs. So we are subversive. There, we have admitted it openly. We are trying to sneak up on your brain. But in a good way. Not to rob you, but to give you a gift more quickly.

Fourth, while lean-agile and scrum particularly are very simple (like all great things), at the same time, they are very complex. We hold the perhaps arrogant view that, at least vis-a-vis lean-agile-scrum, we are smarter than you. (And that's why we are leading the course, and not you.) So, while we get you active and talking, there are, sometimes rather indirectly, some things we are trying to tell you. We might wait for you to discover them on your own, and we might wait for monkeys at a typewriter to eventually write Hamlet. But, frankly, while we have some exercises where you discover things for yourself, for everything we are not that patient. Given that we only have 2 days for the basic course. So, we "tell you". (Some might call it 'lecture', although you might not. In any case, a different kind of lecture than most are used to.) Yes, yes, yes; we know all the problems with that. But we actually think that some people, if we add jokes and other tricks, actually stay awake, actually listen, and actually learn this way.

As Yogi Berra said, if people don't want to come out to the ballpark, nobody's going to stop them. Meaning: If they don't want to learn, fugetaboutit!

Also, we frankly are not clever enough to come up with enough exercises that can be done quickly. And, having felt 'played with' (in a bad way) by some of these kinds of games ourselves, we are sympathetic with those who are naturally skeptical of games. So, we still do some games and exercises, but maybe not as many as others. Instead, we use other tricks.

It perhaps bears saying at this point.... What we teach are not ideas that we invented. We feel we have been blessed to share the wisdom from men and women on whose shoulders (as the metaphor goes) we stand. It is a great wisdom, from the gods one might say, and we are humble about our real ability to pass it along as accurately as it deserves. And yet, despite the jokes and playfulness, which in some eyes might imply lack of caring, we value this wisdom very highly. And we think reaching the inner secrets of this wisdom is difficult. Realizing in a full way the most benefits is very very difficult. And, paradoxically, as with all great things, it is in fun and with great ease that the most benefits are realized. Trying too hard does not help. As any baseball player knows, we must simply swing the bat, and just let happen what may. So, the main point here is a certain kind of humility.

More later....

And your comments and reflections on this are solicited.

Note: The picture is of Carolyn Eyles, an award-winning teacher in Canada. Google her.

Release Planning

This is a short post to summarize our recommendations for Release Planning.

First, R.P. is that initial part of Scrum, where we plan the Product Roadmap and develop the first Release Plan. It is pretty important. We do it before we start doing Sprints.

Some people believe one myth about Agile (and maybe others). This first myth says: "we always leap in without looking or thinking." This is a myth, ie, incorrect. We must look and we must think first. But, how much??

Within Agile there is always this tension, between thinking just enough and YAGNI (you ain't gonna need it). Each team must resolve this tension its own way. Experience has shown that we learn most from real experience. So, suffice to say we do not, in agile, have a 6 month planning 'phase' (for any project that I have ever been on... and I accept the possibility that there just might be a fundamentally different kind of project than I have ever experienced before).

So, should it be done in one day? In 3 days? In 3 weeks elapsed time? The simple framework of Scrum does not answer this question. Use common sense (which is quite uncommon).

Still, the Product Owner and the ScrumMaster must set a high-level time box and day-by-day time boxes for the Release Planning. And try to get the participants to stay within them. It is hard. But the law of diminishing returns tells us not to waste that 'extra' time.

OK, what to do?

1. The Vision
2. Build the Product Backlog (stories)
3. Organize the stories with Business Value (I like BV points from Priority Poker)
4. Estimate the effort of the stories (using relative Story Points)
5. Discuss risks, dependencies and other things.

THEN
6. Order the work (based on all the info developed above)
7. Decide on (a) scope and date (together), and (b) cost.

We generally assume that the team is a constant cost per Sprint, so once you know the number of Sprints, you can easily calculate the cost.

Over-simplified. Left out some key things (well, not left out, but maybe not made fully transparent to some readers; assumed by me).

Having completed the R.P. you have achieved two main benefits.
1. You have established an "early warning system", which, when improved, can give you some advanced notice if your effort is getting into trouble.
2. You have all the "pigs" (and others) much much more on the same page about what the effort is really about. At a good medium level of detail. This is very very valuable.

Oh, yes, and we have the initial scope and date. The quality of those is technically termed 'crappy', so I minimize them as benefits. But soon, when revised and improved, they will become decent guesses.

Eventually (maybe up-front), this release plan must be developed further into a Product Roadmap (I don't really care what name you call it). Typically this is a rolling 12-month plan. After the current release, this is typically at a pretty high level (small to medium epics). Most businesses need about a 12 month plan. Some less, some more.

To close on a semi-controversial note: NO Sprint Zero! We did some release planning, now let's do a real Sprint (with a demo of working software at the end)!

No man is an island, entire of itself

In summers past, I have gone whale-fishing from Nantucket island. Well, not I, although I did go to beautiful Nantucket, as Ishmael did in that novel. But they never called me Ishmael.

But I have set out from Nantucket, as they did of former days, intent to catch me a whale. Albeit mine was a metaphorical whale.

So, you see why I choose Nantucket as the island. I think maybe John Donne, in his very famous Meditation XVII (a much recommended long tweet), maybe was in part thinking of the small island of England, Scotland and Wales.

And thinking of how we are all connected, one to another.

There is something very mystical, magical and special about any team that achieves success. They are indeed connected. And, no doubt it is or will be painful at times, but mostly such a wonderful feeling.

And the great paradox, by losing ourselves we become ourselves, becomes true.

If your collection of individuals would become a great team, they must not just gush with emotions, but act in their beating heart, and strike it with their muscles. Together. The paradox is cut through not in meditation, but in fierce sword-like sharpness in the real world. A game for the courageous.

This team part of the game we try to ignore, quite often. The head bobs at "we are a team" but the body does not follow through, as we might say. Each of us has our issues about this: our old patterns, our egos, our introversion, etc, etc.

People are "Created half to rise and half to fall" as Alexander Pope wrote, so, yes, it can take a lot to deal with them. And it is not just the logical and the emotional. We must deal with all the 18 (and counting) sides of the people in the team with us. (Yes, Virginia, we need more than IQ and EQ. These are whole people in the team. Dang.)

But if we would have any success or satisfaction in life, 'deal' most of us must. And the simple framework of Scrum sets in motion a basic interaction pattern. Which we can build on.

What gives?

I was just at the Agile Tour at Research Triangle Park in North Carolina. Very good event (kudos to Catherine Louis and the other organizers!!).

Laurie Williams, who is a great person and a great agile researcher, has done some work recently on, and I should use her words but don't have them handy, 'how do we feel about the Agile Manifesto and the Agile Principles now?'

One general reaction I had, which is also a reaction I have had recently in other situations....

When push comes to shove, what should give way: Agile principles or our local organization?

In my view, almost always the problem is 'us' and not the agile values, principles and practices.

And almost always, we make the agile stuff 'give right of way' to what we call 'reality'. But it is not 'reality' as in the law of gravity, but only reality in that these are the stupid ways our organization is doing things today.

Example: Sustainable pace.

Some people complain that the principle of sustainable pace means that managers can whip us to stay at 30 story points per sprint (after the team itself volunteered to go 30), and that it does not allow us to fix the technical debt or do the broader range work that must (at least eventually) be done.

This is my view:
* sustainable pace is very important in many ways. The main way I like to talk about it is that it is no longer about 'hard work', it is about 'creativity' and 'innovation' and 'inventive' solutions to difficult technical problems. Our brains have to be fresh to be creative as a team.

* sustainable pace (as measured via velocity) quickly becomes less valuable unless we are doing virtually everything possible never to allow technical debt to grow. Let's be professional.

* sustainable pace does not mean that the team 'must' maintain the same velocity every sprint. (Yes, Virginia, stuff does happen, for example.) AND, the team should always be challenging itself to remove impediments so that more 'work' can be accomplished in the same amount of time. In other words, in general and on average, 'velocity' should be upwardly sloping. But NOT by working harder.

* an empirical process requires transparency (or a high level of it) and any pretending about or hiding of 'undone work' (as Ken Schwaber likes to call it) is not helpful at all. Sustainable pace quickly becomes meaningless if we do this. (Cf Technical debt above.)

* Bad news does not get better with age. So, sustainable pace must be immediately linked to a strong and improving 'definition of done' for normal stories in a sprint.

* By sustainable we must mean we are doing everything we professionally can to assure we are keeping each sprint up with ALL the different types of work needed to keep the system fully 'done'. This includes fixing all bugs, doing all the refactoring, building all the truly useful documentation, visioning of future sprints, release plan refactoring, etc, etc.

* As soon as we discover some undone work (and we as humans will typically forget something and thus it is undone), we must address it professionally....do it immediately or put it on the product backlog. And consider how much it makes our previous information about velocity and progress a lie. (Always, to some minor degree, and possibly to a significant degree.)

* Just because we will always be imperfect does not mean we should give up on agile or agile principles or practices.

Can you put these ideas into action real soon? (Today is a good day.)

PS. I am not saying the Agile Manifesto and the Agile Principles are perfect. But maybe I am saying that our real worlds are messier than those ideas. Or so I see.

A real person in a good team

Some people take the view that they will be lost in a team. And, to be fair, this can happen. There are bosses and there are teammates who want you to conform, to submit, to lose your identity. To a meaningful degree.

But in a real and good team, the opposite occurs. We each become able to become more of who we are.

We each can learn faster. We can be more honest. We can make mistakes and admit to them. We can learn faster from these mistakes. We can enjoy our colleagues, whom we come to know as more complete people.

Yes, there can be dysfunctions in a team. Some teams can learn their way from those dysfunctions. Some cannot.

So, we and Scrum are not in favor of collectivism, of people losing their identify. We are in favor of each person using his or her unique abilities to be creative. And struggling to find themselves within the context of the team. (Yes, one must face and deal with some compromises, which to the inexperienced or immature can seem really tough. May indeed be really tough sometimes. But unavoidable in our life as humans. 'No man is an island' it was once said.)

So, we are not talking about dysfunctional teams mainly. We are talking about good to great teams.

Perhaps most importantly, I get to contribute to the team making a great product that real customers will like (more). This is very satisfying.

So, it is funny how life can be more satisfying when you give to others. You get more for yourself when you are thinking mainly of others.

Now how are things for the so-called top performer?

Umm. Well, the good team should be able to recognize fairly the talents of all it's members. (But it won't happen every time.)

So, again, we cannot promise nirvana, but we think in good to great teams, even the top performer(s) can have a better life.

Some of this seems paradoxical to those who have been in bad situations. My sympathy to you. But do not lose the faith that some day you will see, in a good team, that it is true.

In my opinion, one of our deepest desires as humans is to be known for that person that we truly are, neither hiding nor boasting, both the good and the bad. It is a deep desire, and a good team can enable you to experience that in a far greater degree than we may have up to now. And it even happens while we are going real work. (ie, Not from some fluffy exercise from a consultant, not in some artificial way.)

The importance of teams

As I teach scrum and lean-agile classes, I often meet people who don't understand teams. Often this is true for some of the smartest, most capable people.

Why?
I think there are many answers.

One is that they have been taught the single-leader team discipline. (This is the phrase that Katzenbach and Smith use for it.) So they assume there is no real team discipline. Ie, they have not been taught it.

So, what is the real team discipline? Many people have talked about it, but Katzenbach and Smith have done a good job of defining it in The Wisdom of Teams.

• Small number
• Complementary skills
• Common purpose, common set of specific performance goals
• Commonly agreed work approach
• Mutually accountable

Another, simpler way of talking about this is to say that the team is smarter than any individual.

This is a little dangerous to say. Yes, teams can be stupider than a single individual, if they let themselves. But Katzenbach and Smith show a number of cases where the team, a real team, was smarter than one individual. Not really surprising to me, since we know the old saying, two heads are better than one.

Why is this so true in our work?

Well....
- we need innovation; generally via basic brainstorming, a small team can be more creative
- our business domains are typically bigger than they used to be
- our technical domains are typically more complex than they used to be
- the speed of change (in all these areas and more) is greater

So a team is better able to keep up. If they are a real team.

More soon....

See The Wisdom of Teams here:
http://bit.ly/9BixGz

JIT Knowledge Creation

This is our business. Just-in-time knowledge creation. (It is not just-in-time knowledge management.)

Why? And why is it so important?

Well, ultimately the answer is because people are important. Or maybe it is better to say we respect the customer. And the firm's shareholders.

What do I mean, you say?

Let's start from the beginning. A long time ago the Lean people discovered that any Work-In-Process waste (WIP) or inventory, is muda. No, they weren't being silly. All Lean firms still have some WIP and inventory, but they have been relentlessly reducing the ratio of WIP and inventory to sales for 50 years now. And now it is a very small fraction of what it used to be. And they are still not satisfied. It must be reduced more.

And why did they do that? Well, in the auto industry they realized that an unsold car in inventory is trouble. It can only get worse, it cannot get better. The sun can spoil the paint job. Rain can cause rust. Hail can damage the exterior. Time can make it go out of the current model year. In other words, they noticed that the car can decay. (There are other reasons too.)

In software development, our business is knowledge. In the form of working code.

How fast can our knowledge decay compared to a car?

And here we mean not only the final knowledge (the working code), but also all the other tacit and explicit knowledge needed in the course of building the working product.

My opinion, and I usually demonstrate this easily in each Scrum class, is that our knowledge decays exponentially faster than a car. And a car's value will only go down a bit at a time. But our knowledge can lose its value as much as 100% in one day.

So, although no one told you, we in the software industry need to be relentlessly reducing our all our work-in-process and inventory. So, WIP is any work we have done that has not resulted in finished inventory. Finished inventory is fully finished software, that is all but deployed and in use by the 'customer'.

Now, we don't mean you should be foolish. For example, there is a minimum marketable feature set concept that does apply. Although we think that the size of the MMFS is much smaller than we almost always want to believe.

Again, a key goal of how we organize things should be to minimize WIP and inventory. And because there are many reasons for that, we can also organize things to minimize the negative impact of the WIP and inventory we 'must' have. (We will talk later about some of the other negative impacts of WIP and inventory.)

We must have a greater percentage reduction in WIP and inventory than the auto industry. We have lots of work to do to make that happen. Lots of impediments to remove. It was hard for the auto industry, and it will be hard for us. And now we have made the first step -- someone has told you that is absolutely key to your job.

Now, you know what your job really is. To know and not to do, is not to know.

BTW, Takeuchi and Nonaka have written many many pages about knowledge creation. They are the godfathers of Scrum. (A hint, for those who want a hint.)

Where to start?

Some of us have been doing lean-agile-scrum for awhile now. And we forget that others are just starting.

So, where does one start?

The first answer is that you start from where you are. One thing this means is that one starts with the impediments one has today. And you use Scrum to help tell you "what is the biggest impediment today?"

And there is always a biggest one today. And it is hard to predict what will be the biggest impediment tomorrow. So many different things can be slowing down the team. So many things can come up in an instant.

Is it useful to work on a less-important impediment? Well, yes, but not nearly as useful as working on the top impediment. THIS IS IMPORTANT. We should always be working on the top impediment (presuming that it can be improved, or that 'they' will allow us to fix it).

Why should you start Scrum? (This gets to the core issue of starting with right intention. As any good Buddhist would want us to.)

Well, some people want a work life that is more fun. Some want to get rid of a bad manager. (BTW, I think very very few managers are 'bad', although I do think lots of managers have been taught badly how to do their work.) Some want money. These are all good reasons.

But I think the best reasons are phrased a bit differently: To make my life better, to make our team's life better, to make our customers' lives better. You will note how that starts from the center and moves outward.

And it raises a fundamental question: what does it mean to make someone's life better? This is a difficult yet important question.

I think it is bigger than software. And I think that important words, like freedom, love and self-responsibility, are in there. And working as a team and at the same time fulfilling oneself as a person. Perhaps we may say a connectedness that that makes us more individuals rather than less. (I am in eastern europe (Romania) as I write.) We do not join a collective to lose our individuality, but rather, seemingly paradoxically, to become yet more our own individual selves within the team.

Within the dualisms we are used to thinking in, this sounds a paradox. But it is the truer organic reality.

Learning how to do this can be painful, but, as the song says, and as every mother knows, a deeper pleasure is on the other side. (See http://www.metrolyrics.com/save-room-lyrics-john-legend.html for the lyrics, if you are interested. Good song too.)

One team recently was going through this pain. One wondered how long it would take. One wondered "will they get to the other side?" Still, one has confidence that people learn from scraping their knees.

Fearless Change

Mary Lynn Manns is visiting Agile-Carolinas in Charlotte next week.

As many of you will know, Dr. Manns is the co-author of Fearless Change, along with Linda Rising. This is a great book about getting people to adopt a new idea (eg, lean-agile-scrum).

So, I wanted to take this opportunity, in thanks, to praise the book and to write about one pattern in the book. In this case: "Fear Less".

This pattern is first about how we fear the skeptic. And the first advice is, as other wise teachers have taught us, love your enemies.

This is in part saying "accept that you are an imperfect human". Meaning, again in part, that while lean-agile-scrum may be very very good, my own interpretation of that might be less than perfect for a specific usage. And a good skeptic can keep bad things from happening.

We must also understand that many people, quite normally, resist change unless they can clearly see that it will help them.

It is also, I think, a recognition that each person is free. Our opposite is not required to agree that our new, brilliant idea is good for them. As we are, they too remain free. Their freedom is a very good thing.

OK. So, what to do about it?

The advice, in my words: "If you have lemons, make lemonade." In the books words: "Turn resistance to the new idea to your advantage." And then, maybe more specifically: "Ask for help from resisters."

We can't go any faster Captain!

For many Scrum teams, they reach the point of attacking all the obvious impediments. And they are fixed. And they say, in effect, "we can't make it go any faster Captain!" As that actor with the Scottish accent would say in the original Star Trek.

What's wrong with this picture? (for the Team)

Well, many things. I will name a few below.

1. Not so obvious impediments.

What I often find is that lots and lots of not-so-obvious impediments still need to be fixed. Things that they overlooked. Or someone didn't see. Often they are the "elephant in the room" kind of impediment. One example has been a command&control ScrumMaster. And there are many others.

Some people assume all impediments must be technical.
Some think all are to do with Continuous Integration.
Some think all are facilitation issues.
Some think if we take care of expresso and baby-sitting we are done.
Some think that disruptions by managers are the only impediments.
Some think think that the initial setup of the infrastructure for the Team is the only impediment.

But, the biggest impediment can be any of these, and more. Technical debt, for example. Or not building new technical debt.

2. Impediments that seem immovable.

I am not in favor of attacking impediments that simply can't be changed.

But, what I usually find is that teams assume that 3 or 5 impediments can't be fixed or improved, and they give up trying to work on them or even asking anyone else to work on them.

And, usually a you need something to "juice" the team to get them to even think of working on these kinds of impediments. Often, the impediments are actually easy to move, eg, after talking to the right manager. Not always, but often.

3. "We're perfect now."

There is this deep human desire to be perfect, to be done getting better. To feel we are the best, and can't possibly improve.

But the wise and even 6 year old know, no one is perfect.

So, we must ask the Team to always say, even though we won the Super Bowl last Sprint, we have to get better….so, what is the biggest impediment now?

The relentless pursuit of perfection. But always a perfection that eludes us.

The Lean people say that when we approach our earlier definition of perfection, we become wise enough to define a new, tougher definition of perfection. Which we can then pursue.

* * *
There are many more issues around this, but these three are a start.

Release Planning & the Early Warning System

Building complex innovative products is, of course, hard.

So, in that context, what is the purpose of Release Planning in Scrum/Agile?

We will not provide a complete explanation here, but we will give a few key ideas.

1. A consensus view of the 'same' elephant. We want all the team members to see the whole product and to start to see the same whole product. We think this is typically the most valuable thing.

2. Think first, but not think too much. This is a neat trick -- getting some people to think enough before they start, and also helping others not get stuck in 'analysis paralysis'.

I find that many people want to know 'perfectly' a certain set of information before they start. Meaning: They want to wait and study too long. I find this seeking for 'perfection' is mis-guided. It typically does not include enough consideration of what it costs us not to know 'X' before we start. (If the cost could be real high, then slowing down to learn 'X' makes more sense).

I think each team should have a good fight about how much to 'study' before starting to Sprint.

3. Establishing a project plan, with a date estimate for the first release and a cost estimate. In most organizations, something like this is usually needed. My experience is that, aside from the discussions about risks and impediments, this is usually the least valuable output. But it establishes a starting point for improvement. So, for several reasons, it is necessary.

4. Establishing an Early Warning System. I was just working with a large client who has a big, multi-team and multi-year effort. Some on the team think they will get done 'early'. And some think they will be 'late' as usual (this is said from my own personal experience that most waterfall projects are late...and this organization is just transitioning from waterfall).

In this case particularly, the group (everyone in the group) needs an early warning system that can tell them whether they are likely to hit the date or not. (A date and a high-level scope has been defined, but the detailed requirements are undefined.) For example, the earlier the group knows there is a problem, the earlier it can take counter-measures to address the problem.

So, the Release Planning sets up the ideas (velocity, story points to be completed, Business Value of the features, etc) that go into the Release Plan. And the Release Plan, with its implied 'ideal velocity', can become the Early Warning System.

Since, in this case, the Chief Product Owner is leading this effort, this gives him great incentive to get the whole group to do professional Release Planning now. So that, for example, refactoring of the Release Plan will take less effort later. So, the CPO needs to explain and explain again why the whole group wants a good Release Plan sooner rather than later. (Only if they want to do it, will they do it well.) Not an easy job. Do-able, but not easy. Especially for beginning Product Owners.

Respect

I just led a course in Charleston. To mostly people working in/on government or military projects.

I was asked many good questions, and I was not able, in the time allotted (2 days) to answer them all as well as they deserved.

I have other clients who have also very difficult situations to deal with, but I was and remain very sympathetic with the difficulties they (this government-military group) face. In implementing Agile, for example. Still very possible. And still I believe it will yield very clear benefits. But also difficult. Perhaps especially given the surrounding 'culture'.

So, first, if my answers ever appeared to be disrespectful of the difficulties and challenges you face, my apologies. This was never my intent.

I, like you, have struggled and sweated or worried about how to implement lean-agile-scrum in specific situations. It is indeed hard. In fact, always it feels hard, in part because one wants to do it perfectly. So, again, if my comments seemed to be flip, they were not said with that intent.

So, what was I mainly trying to say?

1. Sometimes, we worry too much. Yes, sometimes we get all in a sweat about a certain issue and in fact that issue will resolve itself easily in good time (sometimes that means quickly, even). (This one is not #1, so much as easy and quick to say.)

2. Mindset, ie, the first and often hardest thing to change is our own mindset about the problem.

a. In part, this means we must start by seeing we are 'right', and they are wrong. Not in an arrogant way, but more in the core of our being. We hold the truth and therefore the real power, and we are patiently waiting for them (maybe a manager) to get a clue and get out of their fantasy world.

This attitude, if not done arrogantly, they can still feel. And it makes them realize, sub-consciously, that they are in the wrong place, and must change. Now, we sympathize with them as persons, but not with their wrong ideas.

b. We must understand that we approach certain ideas and issues with very different premises than they do. And so, understanding the mindset shift, we look for statements from them that reveal the old mindset so that we can attack it. For example, we know we want to optimize delivery to the customer. When they say they want to keep the workers busy, that opens up a good conversation about the goals of management.

Sp, often I did or will answer your question with something, maybe a sports metaphor, from left field (as we say). The reason often is to focus on the mindset shift. Not to diminish your issue or question.

3. Time.
Often attendees ask very good and very difficult questions. A good answer would really require 2 hours of Q&A to be sure I really understood the specifics of their situation. And probably then another hour to formulate and explain 10 approaches to dealing with a hard issue. In the CSM course, understandably, I do not have time for 3 hours devoted to one good question.

So, I say something brief. And I often worry later that it can be taken the wrong way by the questioner. I do usually ask "did I address your question at all or well enough?", but maybe in specific situations I need to say more to be better understood.

4. Self-sufficiency.
One of the properties of complex adaptive systems is that they 'solve' their own problems. Not always in isolation or fully or completely. But they can learn and can adapt. So, in part I am relying on you to use the values and principles we discuss (and maybe even some of the practices) to devise your own answers to the problems you pose.

I have confidence that you can and you will.

5. We always have impediments.
Meaning: We can still be successful even with lots and lots of impediments. Success with waterfall is one example of that. But, more generally, even though none of us ever reaches perfection, still we may say we are having many successes (eg, with lean-agile-scrum).

So, I know from experience, that even though your question may be about a very big impediment for you, still, even if we do not even address it, almost surely (I have seen this so many many times) you and your team can still have better success with Scrum than with what you used before. Even if that impediment is not addressed at all.

Now, yes, a few people might have had an impediment that does stop them in their tracks. I think this is possible. But, honestly, I have been doing and talking about this for a good while with many people, and I never seen such a case, I think. With the exception of 'people', which is indeed very difficulty to deal with. ("Our manager won't let us use Agile.")

Anyway, if I have seemed less than sufficiently concerned about your issue, it was not that I did not have sympathy, but maybe that I did think you could work through it or be successful despite it.

I did respect your question.

King of Anything!?

Sara Bareilles, whose music I have enjoyed a lot, has a new song: King of Anything.

I think you will like it. http://www.youtube.com/watch?v=eR7-AUmiNcA

You might well ask: Why is he talking about this song here?

And the answer: In work, we must recognize the importance of freedom, of self-organization. For their own sakes (these are human rights, after all). And because work actually gets done better if we recognize and operate on those principles.

Some of you will recognize that these are, in one way or another, key principles of Lean-Agile-Scrum also.

So, as we all make mistakes, watch out for when (not if) you treat others as though someone died, and left you king of something. The people that we do this to (we must forgive first, ourselves; we are only human)...they are usually too kind to sing us this song, or their version of this song.

Little's Second Law

Little's Law is a nice idea that tells us: we want small batches of work. Smaller, always smaller.
See here for a start: http://en.wikipedia.org/wiki/Little%27s_law
This is from a John Little at Case Western Reserve. And it is fairly old.

One day this phrase came to me: People are remarkably good at doing what they want to do.

I call it, in fun, Little's Second Law. And I have mentioned it before.

A friend said: You must talk about this more. But is it not obvious?

This law has two sides. On the one we have: Where there is a will, there's a way. If they really want to do it, they will overcome any obstacle. These human values of persistence and wiliness are both Odyssean and Protean.

The other side is what I call the Ebet principle. My now wonderful sister was once 12 when I was 15. Her older brother, in his wisdom, would remind her that she (a) should clean up the den, (b) do the kitchen dishes, (c) finish her homework, and (d) clean up her room. And by the age of 12, she already knew 1500 ways to assure that anything her older brother asked her to do would (1) not get done, and (2) mostly likely the lack of action would be blamed on her brother.

When they don't want to do it, they can often make sure it fails.

As a practical matter, this has one specific meaning (among many others): The ScrumMaster must get the team to want to do Scrum.

We do well to remember these basic laws of human nature.

Freedom and Responsibility

Now I wanted to start talking explicitly about freedom and responsibility. The twins.

For most normal people, freedom and responsibility come together. That is, we are only free when we accept responsibility. This may seem a paradox, like saying, "we are only free when we become a slave." But it is not.

So, if we are free we must take the responsibility to decide and act. In the team, for example.

And we must take the responsibility to explain this to managers. "Leave us alone until the end of the Sprint" is a phrase we must be adult enough to repeat often. (And forgiving enough to be willing to repeat again and again.)

Now, managers, contrary to what you were typically taught, God gave them freedom and you have no right to abrogate it.

In a relationship, no decent person wishes to be loved by a slave. One wishes the love, each day, to be truly given. Not required.

In a roughly similar way, in work the magic of the team operates at a higher level when they are free to give what they want, what magically comes to their heads. In the team soup.

Now, this is not foolishness. If the Team goes for a good while and comes up with nothing much, a manger might need to add something to the soup. But she is looking to add a simple constraint or an idea that will juice the team to freer creativity. Not to put an iron box around them to make them work hard.

So, let me repeat a few key ideas:
1. Workers are, by and large, worthy of freedom and responsibility.
2. Managers should be ashamed to assume, tacitly or explicitly, that workers have, even for one moment, given up any freedom.
3. Both managers and workers are human and make mistakes.
4. Neither managers nor workers, in general, are evil. (Yes, there are many managers who are poorly taught in the arts of managing. Yes, there are a few evil managers; but all managers do not deserve to be blamed because of the faults of a few.)

Very good people often misunderstand these ideas, when they try to put them into action. We saw this in what is now called the Place de la Concorde, with the guillotine. It is for us to forgive them, forgive ourselves, and remind.

Thank You!

I am back now from a visit to Lima, Peru. And from New York, and Newark, and Saratoga Springs.

Freud said that life is about Arbeitung und Lieben. Work and Love. And, to me anyway, these words have started to intermingle. I love my work, and I work to express my love.

At the deep level, I think we first wish that those we love know that we have tried to express our love for them. And of course, we never express this well, or just as each person would want. But we want each person to know that we *tried*, in our actions or words, to express it as well as we could to him or her. And particularly, of course, those that we care about most.

So, this is what I want to say today. Thank you!

Thank you to my family for putting up with my travels. And me.
Thank you to my friends (you know who you are) for helping me. It is my wish that you know how grateful I am.
Thank you to my course attendees and my clients for letting me do the work that I love so much. And, I hope, for being a small part of your life getting better. And increasing your ability to make others' lives better. This is to me a great satisfaction.

So, this also an admission of partial failure. None of you can know how much more I would have wished to express that well of water (as I will call it) that has been given me. There is so much more there, and I know how poorly it has been expressed.

And I know that what I have expressed or done has, oft times, fallen on deaf or partially deaf ears. It was not the right time, or the right phrasing, or it was too physical, or too dramatically stated, or too abstractly stated. It was said in metaphors that fit my culture or my nature, but not that fit your culture or your nature. Or was too quietly stated.

Each of us wants and needs things to be expressed or done in just a certain way and in just a certain time. And I know, too well, that I am not always able to do that. It is a sadness to me, that my actions or words could not have been more just what you needed. But a sadness that is just part of being human. I can accept it well. But today I do feel it.

But again I say, more happily: Thank you!

One can say it as: Muchas gracias! Merci beaucoup! Vielen Dank! Mille grazie! But in my own mother tongue it is: Thank you!

Happy Independence Day!

First, a word about happiness. I am sure I don't know everything about happiness, but I am still quite sure it is important. Mr. Jefferson included, in his draft, "life, liberty and the pursuit of happiness". And Jeff Sutherland says "if they aren't having fun [with Scrum], they aren't doing it right."

Serious fun, fun that comes mainly from work. But still fun.

Umm. I think there may still be some of us who feel that things are good only when we are in pain. I guess if that is fun for you, go for it, as long as you don't hurt anyone else. Anyway, do not put me in the camp of ascetics or stoics. Pleasure, if done right, can lead to creativity.


But the main subject is freedom! Freedom! What a great word. The second greatest word in the English language.

This is the day on which we celebrate the Declaration of Independence. A declaration for freedom. "We hold these truths to be self-evident. That all men a created equal. That they are endowed by their creator with certain unalienable rights. That among these are life, liberty, and the pursuit of happiness." What glorious ringing words.

And still we are not free. In ways big and small, others try to enslave us. In ways big and small, we enslave ourselves. As Rousseau said: "Man is born free and everywhere is in chains."

Managers: Never, never, never, never enslave your associates. They do not belong to you. You did not create them. Even if they ask you to, do not abrogate their freedom. God gave them freedom for many mystical reasons, the source and meaning of which you haven't the least idea. You are a manager to help them fulfill their lives, not to take their freedom away.

Let me be yet more honest. You have been taught, and it is in the bones of most of you, to enslave your associates. I, as one, do not blame you; you have been taught badly and you are human (imperfect). I too have committed these sins. But do not be complacent with your imperfections. Try hard to stop doing it.

Workers: Never, even for a second, give up your freedom. You freedom of action, of speech, of association. Your freedom to be yourself. You never said "I agree to be a slave to this firm or this manager." Don't do it. In fact, most managers can feel in their bones the sin of abrogating your freedom; do not let them sin more.

Yes, you do not have to tell me all the temptations you face to give away your freedom. On some days, it seems a good trade, and it seems that we might pawn it and get it back later. It is hard. But having fun is hard too. You, your freedom are worth the pain of this hard passage.

[Yes, of course, there are certain social constructs that limit our freedom. We don't yell "fire" in a crowded room, etc, etc. It is a complicated subject. So, study it!]

So, how does Scrum instantiate freedom. Well, one way is that each person reports for himself or herself in the Daily stand-up. One way is that the Team gets to choose how many Product Backlog Items to commit to in the Sprint Planning Meeting.

More broadly, in Scrum we accept (well, more) that a person brings everything he or she is to a Team. And thus has much more to offer a team (yes, and, well, maybe a bit more to deal with too). We are free(er) to be who we really are.

Immediately after mentioning freedom, we must also mention responsibility. If you are free, you are also responsible for yourself. This is a great lesson of life. Mysterious, just as God gives us responsibility for ourselves, he also makes the sun to shine and the rain to fall on both the wicked and the good. Consider the lilies of the field, we might say. In a free economy, much is magically provided for us. Still, we must work, we must learn that it is more blessed to give than to receive. We must learn that we must still get along, in business, with even quite disagreeable people (the simple version of "love your enemies").

How does this work in Scrum? So, in Scrum, the team at the end of the Sprint Planning Meeting commits to 8 or 12 or 15 Product Backlog Items. They become responsible for delivering those by the end of the Sprint. They are free to do it anyway they want, but they have committed to deliver. They are responsible.

"That whenever any form of government becomes destructive of these ends, it is the right of the People to alter or abolish it..." Yes, and this is the slow, painful path we are on in abolishing Waterfall and all its associated bad thinking. We have this right. We have this duty even. We must fix it. May it be that the lean-agile-scrum with which we wish to replace waterfall are worthy successors and worthily practiced by the players.

So, on this beautiful day (and are not they all beautiful) send not to know for whom the bells toll. The bells of freedom toll for you. The fireworks of freedom are lit for you. Whether you are in Demorest, GA, or Ottawa, or Bangalore, or Paris, or Amsterdam, or South Africa, or Lima. No man is an island, because each of us is involved in mankind.

An Intro to Business Value Engineering

On June 30th, while I was in Montreal giving a CSM Course, I also joined the Scrum User Group and gave a new, somewhat different, presentation on BV Engineering. They seemed to like it more, so maybe I am making the points in a somewhat more practical, concrete way.

Here is the link to the PDF: http://www.slideshare.net/jhlittle/intro-to-bv-engineering-montreal

Courage

We have suggested in other posts that a tremendous amount of improvement can be made in, to over-simplify, 5 areas:
* ScrumMaster leading the removal of impediments
* Product Owner executing the 85-33% rule (like the 80-20 rule)
* Team having more fun!
* Team reducing Technical Debt all the time
* Continuously better Business Value Engineering

And why do we not see more improvement if there is indeed so much improvement there to be had?

How much improvement? Easily 5x - 10x over not that long a period of time.

So, why not?

Well, first, it is hard. It takes some hard work, but mostly hard thinking and hard conversations.

Second, we must actually believe that serious improvement is possible. Not so easy when we see so much baloney (I was sorely tempted to use a more technical term) happening all the time.

Third, we must actually want serious improvement (this is a key place where fun comes in). You must want it in very part of your body, almost. All of them must want it (well, many of them).

And then, we must have courage. To fight our own stupidity. To persevere against some hardships and some ups and downs. To fight others' stupidity. And to fight all the slings and arrows and natural shocks that come into a daily lives.

And we must focus. Maybe that means working on only one of the 5 areas above at any one time.

It is there. Go for it.

Suggestions for a better Daily Scrum

It is our view that the main problem with doing Scrum is that we don't 'feel the music' while we do the dance. That is to say: we don't understand the values and principles underlying the practices we are doing.

In general, this is true of all of us. So, there is no reason to get obnoxious about 'I get Scrum better than you'. Still, in any case, someone has to talk to someone else, to the effect that, 'I don't think you are getting the values and principles well enough'. Sometimes this starts as a question, such as: "Why do we do the Daily Scrum?'

My answer: It enables the Team to land the airplane at the end of the Sprint.

Put another way, it enables the Team to get enough visibility about 'everything' that is going on, to identify the biggest problem(s), deal with them some, and then complete the Sprint successfully. Meaning all promised 'stories' are completed ('done, done' if you use that phrase).

Some smells or issues:
1. 'We are reporting status to the ScrumMaster.' OK, raise your hands anyone who enjoys reporting 'status' to any manager. Ummm. No hands. Shocking. No, dudes, you are not reporting status to any manager. You are enabling yourselves (the whole team) to be successful.

2. 'No one is talking about anything useful.' Then do the five Whys about the root cause of that.

3. 'People want to hide.' Well, it is natural to hide from pain or expected pain. Virtually 120% of the time, the implementers have been beaten up, harassed or at least disrupted if they told the truth. So, naturally, it takes a long time of not getting punished before they believe they won't be punished any more. Figure out how to deal with that. Talking helps.

4. 'Everyone says "No impediments".' Yeah, like that is true. First, explain that we are always removing the top impediment (that is happening for your team, right?). Then, emphasize that people themselves and their normal mistakes are not impediments. Or maybe better to say that we ALWAYS expect people to make a normal number of human mistakes. That is part of being creative. Then, ask them to identify 'anything' that is slowing the team down. (Sometimes they have too limited a view of what an impediment might be.) Then, tell them that each person must identify his biggest impediment. (And we all have one, since nothing is perfect.)

5. People arriving late. Umm. Sometimes a difficult one. First, review why you think the Daily Scrum is valuable, its purpose, stuff like that. Does that person agree? If yes, then why is he late? Ah, he has something more important almost every day? Does he really feel he is a team member? And continue on like this. But sometimes it just takes 'tricks'. The 'put a $1 in a jar' one is well known. (The Team takes the money and buys donuts every so often, for example.) Or, try having the late person sing a song after the stand-up. Very effective for many. Or, have the person eat a pickle (in the morning). I have not done this, but I hear that a pickle tastes bad in the AM.
Now, if a team member sends in one's answers to another team member before the stand-up, then one is not 'late'.

6. They only answer the 3 questions. The 3 questions are only a help. The Team should talk about the most important stuff in 15 minutes (max) to land the plane. Together. Especially if some Sprints have failed (not gotten all stories done) and poor daily info feels like a root cause, then explore this.

7. Have the Daily Scrum around the Scrum Board. Finally, a positive one. I strongly encourage teams, especially beginning teams, to have the Daily Scrum around the Scrum Board, and to move the cards in the meeting. It is magic. (Lots of studies and theory explain what the magic is, but do you need to go there?) Yes, the works a lot better if the team is collocated.

Why do we have a daily Scrum?

Well, it's just like Fred Brooks said in The Mythical Man-Month.
'How does a project get one year late?'
'One day at a time.'

If we take and address the top impediment each day, we are much more effective as a team.

New Courses

All up-coming courses are posted on LeanAgileTraining.com. And you can see the calendar in the widget to the right.

We are excited, for sometimes different reasons, about each of these courses. We have enjoyed the people we have met (so far) in each of these cities. We enjoy working with the co-leaders. And each of these cities, each in its own way, is meaningful to us. And of course, we are always delighted to be talking about, and helping others with, Lean-Agile-Scrum.

As a quick summary for the next 2 months, we have the following:

May 11-14: Ottawa: CSM & Workshop (Sold Out). With Catherine Louis.

May 18-19: NYC: CSM Course

May 25-26: Charlotte: CSM Course

Jun 8-9: Atlanta: ScrumU: CSM Course. With Kristine Shannon.

Jun 15-16: Washington, DC: CSM Course

Jun 29-30: Montreal: CSM Course

Jul 13-14: Lima, Peru: CSM Course

Jul 20-21: Charlotte: CSM Course

Please contact us if you have questions.
We have other courses 'in the works' which we will announce shortly.

The hardest thing about Scrum?

to hold as 'twere the mirror up to nature: to show virtue her feature, scorn her own image, and the very age and body of the time his form and pressure.

What is best thing about Scrum?

Wow. There are so many good things, hard to choose the best.

• That we get to be ourselves (less than we pretended sometimes, more than we showed before)
  
• That we get to help others more effectively
• That we get to tell the truth
• That we deliver more business value (pretty important in a recession)
  
• That we can see the truth better
• That we can see the progress we have made (eg, by removing impediments)
• That we have more fun
• That we get to enjoy being in and contributing to a respectful team
• That we can have more pride in our work

OK, fine, but what is the hardest thing about Scrum?

Well, at first, it seems like figuring out all the practices is often the hardest. All the fine art of doing Scrum.

Then, Scrum makes more apparent all the problems we have doing our work. And new product development is always hard. And our organizations, it becomes quickly apparent, are beyond stupid in how they support the team. So, these painful truths are hard.

Then there is the relentless pursuit of perfection. It is hard, everyday, to admit that you and the team are not perfect yet, and there are more impediments to remove, more Kaizen to do, more change. Relentless. And hard on the ego. One wants to believe one can plateau out, one has reached perfection, and can mentally rest. Accepting this never-ending road is hard (although, once accepted, more fun).

Finally there is the mirror. "Hi. I am Joe. I am a recovering waterfallic." We have to admit that deep in our hearts, Scrum values and principles forever elude us. Yes, we get them some, maybe more on some days than others. But even the best of us want to follow other values and other principles sometimes. Even I (whomever "I" is).

I want a silver bullet.
I want to tell people how to do it.
I want to make the Team self-organize. [Is this an oxymoron or what? But we, in effect, say these things to ourselves.]
I want to be seen as the smartest (as though that were relevant to the Team's success).
I want to have a contract, not accept that collaborating through change is more valuable.
I want to prove that my box/silo, which I can fully control [quite an illusion that one], is successful. Rather than accept that I only influence the success of the team. And that the only meaningful success is team success, really customer success.

And many more.

It is so easy, so normal, to think we 'get it' when we don't.

I think it is very hard to see, and hard to accept, that we ourselves are stupid and revert back to 'wrong' ideas.

How to deal with this?
Umm. Very hard. Only simple things can be said. Continually question whether our thoughts and suggestions are consistent with Lean-Agile-Scrum values and principles. Allow others to continually question that. Assume that we are making some errors in this way, and ask ourselves "where are the areas where I am most violating the values and principles of Lean-Agile-Scrum?"

Let us struggle with this, with some compassion for ourselves. But with some renewed energy also, to, for example, ask for feedback.

PS. And we hope you like the Picasso. Girl before a mirror. Museum of Modern Art, NYC.

What does a PO do?

We say a Product Owner (PO) can have a tremendous impact on the success of a team, of the team's work.

Say, double the productivity in 6 months. With the recession, we could use that about now.

Sounds nice. How is the PO gonna do that?

Well, this is a constant study, but let's summarize the summary here:

* continually improve the BV Engineering theories and practices
* improve the deliver of the Business info into the team
* become better at correctly telling the team what the customers really want
* optimize, continually, on the 80-20 rule
* identify the minimal marketable feature set, and always yet more minimal
* express the value of the customer solution so well, that the team is totally psyched to do the work
* continually integrate the Business and Technical information to make the best possible trade-offs (such as minimizing Technical Debt)

And lastly, seeing and explaining to many people how every one of these activities, when done well together, inter-link and support each other. (Why? A subject for a later post.)

Take a CSPO course and learn more.

Certified Scrum Product Owner course Apr 27-28

For the team's work, a good Product Owner is very important.

A decent PO should be able to double the value delivered by the team, just by their own efforts, in 6 months. (This assumes a normal team, as I see them.) This can make the lives of many real people better: customers, the team, managers, shareholders, etc.

There are too few of these Certified Scrum Product Owner (CSPO) courses, in my opinion. And too few really good POs.

Why our course? Many reasons. What we will say quickly here: we have an MBA and a deep interest in Business Value Engineering.

See here: http://bit.ly/bAwwFb

CSPO, Charlotte, Apr 27-28.

If you wait for perfection, ...

If you wait for perfection, you might wait too long.

There are some similar quotes, but so far as I know, this quote is mine. As the father, I kind of like it. But most parents love their own children. (If I am not the father, tell me now.)

This applies to all of life. And to Scrum and Agile and Lean. As the guy said to Jack Lemmon in that famous movie, "Nobody's perfect." In fact, not a single thing is perfect. So, my advice is: Don't wait for perfection.

Still a big problem out there. Too many people doing it. I usually don't do it more than 3 times per day.

Use this quote to work on 'em. Make life better now, before it gets to 'perfect.'

One of the biggest business problems we have.

A re-write....

I have taken an article out of context, and re-written it below. Here is the original:
http://www.only-positive-news.com/archives/1232

See how you like the re-write:

If social psychologists have proven anything during the last 30 years, they have proven that the actions we take leave a residue inside us. Every time we act, we amplify the underlying idea or tendency behind it. Most people presume the reverse: that our traits and attitudes affect our behavior. While this is true to a certain extent (though less so than commonly supposed), it is also true that our traits and attitudes follow our behavior. We are as likely to act ourselves into a new way of thinking as to think ourselves into a new way of acting.
There is a practical moral here for us all. Do we wish to change ourselves in some important way? Perhaps get better at Scrum or convince people of the principles behind Scrum? Well, a potent strategy is to get up and start doing that very thing. Start doing Scrum. And ask them, as Coleridge said, to willingly suspend disbelief. Don’t worry that you don’t feel like it. Fake it. Pretend that you want to do it. Feign optimism. Just do it. Do it as an experiment.
In doing Scrum, they typically find that all the fears of how it won't work melt away, or at least become much less. And they also experience all the good things about Scrum (one example: the building of trust between the technology side and the business side).
Yes, telling people to act or talk positively sounds like telling people to be phony. But, as usually happens when we step into some new role–perhaps our first days “playing” parent, salesperson, or teacher–an amazing thing happens: The phoniness gradually subsides. We notice that our uncomfortable sense of being a parent, for instance, no longer feels forced. The new role–and the new behaviors and accompanying attitudes–have begun to fit us as comfortably as an old pair of blue jeans.
The moral: Going through the motions can trigger the emotions. Surely you’ve noticed. You’re in a testy mood, but when the phone rings you feign cheer while talking to a friend. Strangely, after hanging up, you no longer feel so grumpy. Such is the value of social occasions–they impel us to behave as if we were happy, which in fact helps free us from our unhappiness.
Granted, we can’t expect ourselves to become adept at Scrum overnight. But rather than limply resign ourselves to our current practices (waterfall?), we can stretch ourselves, step by step. Rather than waiting until we are utterly and completely confident that we *know* Scrum will work in our new special situation, we can begin. If we are too anxious, modest, or indifferent, we can pretend, trusting that before long the pretense will diminish as our actions ignite a spark inside–the spark that will lead to happiness.
* * *

Changing people (that would include you)

I am involved with Scrum as a coach and trainer. And occasionally (well, more or less daily), I get the question: "I would really really like to do Scrum (better), but I need to change X, Y, and Z." And X, Y and Z are people or groups of people at that person's organization.

And, just to remind us of how utterly impossible it feels, let me add. "People don't resist changing; they resist being changed." ("Zen master, why such an impossible koan today?")

(We must also remember that it is not only "they" who must change. We must change also, starting with our blindness to our own need to change. Arrogance is not charming.)

And I totally sympathize. I too would like to see Scrum used more and better (or better and more). And to me the key impediment is in the mind of man (or particular people).

Or is it in the mind?

I take Hapkido, and I truly like and greatly greatly respect the master of the dojo. An American. One of his favorite phrases is: "Fake it until you make it." And of course that has many applications.

Then, look at this article: http://www.only-positive-news.com/archives/1232
Or maybe better, look at this re-write of that article: http://agileconsortium.blogspot.com/2010/03/re-write.html

I am not all into some of the touchy-feelly stuff in the original article, but the basic point rings truer and truer to me. The action teaches the mind what the values and principles really are. Well, it would if they were paying more attention. And, even when not, it does teach them some. Reality is a great teacher. And then the wiser teacher can teach based upon experience, not upon mere ideas in the mind.

So, today I heard this saying: "We do not think our way into a new way of acting, we act our way into a new way of thinking." (A version of this saying is used in the article.)

Surely this saying needs some explanation, especially for those who are strongly (and only) rationalists. And surely it is not complete. But I can tell you from my experience that a man who is only convinced in the head will do the practices of Scrum in a very weak manner, while a person who "gets it" will do them so much better. ["Gets it" is the simple, opaque and yet totally obvious phrase some of us coaches use. If you have not experienced it, apologies, because it will sound totally stupid.]

I call Scrum a "drama-in-real-life". By which I mean that in enacting the drama, the people will learn. All the parties. And, with a wise teacher, over time many good things will result. Many good things will be learned in enacting the drama.

So, one answer to "how do I change those people?" is: start the drama-in-real-life of Scrum, and use that to enable them to change. Wait for the teachable moment, and show them what they are almosting in their knowledge of agile. You can observe a lot just by looking, Yogi said. And learn a lot just by acting, Kert said.

Additional Value from the Scrum course

In the prior post, I spoke of a simple way of measuring the value of a scrum course. And the real subtext was: You must measure velocity (productivity) and you must increase velocity dramatically. (And, oh, by the way, a course might help you do that.)

But aside from velocity, does the CSM course provide other values?

I think yes.

So, what might they be? I would be very interested to hear how you would put this (or these).

X has already mentioned that it bring a common terminology. This is very helpful. In many ways, and to many different people.

I have heard a senior manager say: "If they only thing I get is greater visibility into where we are, that's plenty. I don't have to have anything else get better." And while the Scrum course won't guarantee that, one of the main benefits of Scrum is that, if you do it right, everyone gets greater visibility. [Now, we are concerned that some managers will meddle more, in a hurtful way, if they get greater visibility, but almost always the meddling goes down some, at least.]

People work less in isolation. I think this is a big improvement. It is a more humane way of working, in this way. Less lonely.

Teams are held accountable for something important, rather than an individual being held accountable for something fairly unimportant and outside his/her control. This is, in general, a big improvement. There are issues, and there are ways that Scrum still holds (appropriately, I think) individuals accountable, so this needs further discussion, but in general, a clear improvement.

More fun. Scrum says that the team must be having fun (well, mostly fun) or its not being done right. And, if it is done with "right" limits, it is always more fun (or so I have found). To me, this is a value on its own.

More focus on impediments. The PMI folks might argue that we always were working impediments, and of course in some sense this is true. But Scrum brings a lot more rigor and effective action and focus on the top impediment, one at a time. Everyone can contribute, the team can identify and prioritize them and devise a plan to remove each one. Even if we don't measure velocity, this is a big value add in many ways (eg, more satisfying and less painful way to work).

So, that's a start. Hardly a complete list of the value. But a start.
You could say that these start to explain how Scrum "magically" leads to greater velocity and a higher delivery of Business Value.

Value from the Scrum course

I wanted to reiterate views I have expressed elsewhere, I think.

My best guess is that a typical development team of 7 or 8, including the product owner and the scrummaster, costs about $1 million per year. Including all related costs. (In my opinion, every team should know their total annual cost.)

My best guess is that a typical development team can produce about $3 million per year in Net Present Value. Based on what they develop; ie, their share of the "earnings" from the product. This is discounted over the 3-5 year typical time horizon. (In my opinion, every team should be given an estimate, and some data after the fact, of the value of the work they will be doing, say, over a year. This concentrates their minds wonderfully.)

From a Business Value viewpoint, the goal of the Scrum course is to significantly increase the productivity of each team. So, let's assume the whole team comes to the Scrum course. And some related managers. Let's assume the team can double their productivity (their velocity) within one year. Let's assume in years 2 and 3, they continue to improve. So, saying we go from a NPV of $3 million per year to $6 million per year is not a stretch.

Let's say that there are other costs/factors that also contribute to the doubling (coaches, impediments removals, etc). So that the Scrum course, which teaches 3 teams, only gets 25% of the added value. 25% of $9 million is: $2.25 million. (Does the scrum course deserve more or less than 25%? You judge.)

Now, get out your spreadsheet and calculate the value for yourself, with your own assumptions. See XLS file here. Let me add that there are many other benefits, but let's ignore those for now.

By the way, a decent team (not a great team) in Jeff Sutherland's opinion should be able to double velocity in 6 months. Many do in 6 weeks. And some companies are seeing an improvement of 5x-8x for every team and it happens quickly.

A couple more things to say:

1. The purpose of the course is not to convey explicit knowledge, although that happens. The key purpose is to get the people willing, wanting, and waiting to change. "It's the Tacit Knowledge, stupid." (To play with a political quote from the past century.) Without this change, which always happens somewhere else than the brain, no worthy improvement will take place.
2. The team must be having fun. I won't explain that more here.
3. The team must be working reasonable hours (40 or less in total).
4. Thus, the way to velocity improvement is by impediment removal.
5. And thus, managers must be removing some impediments (and letting the team self-organize) or the full amount of improvement won't happen.
6. Finally, this is still not a silver bullet. Teams can be dysfunctional and projects can still be impossible. (The good news is that these serious problems can be identified very much sooner.)

Now, our challenge to you. Have you achieved a measurable and believable increase in your own baseline velocity? How much?

You owe it to yourself, your teammates, your company, your customers, and right now to the world economy, to get your team going. You can do it. If you feel you can't change your organization, first, don't believe yourself. "The culture" can resist one or two people. It cannot resist a fired up group that is right.

Still, if you can't change your organization, then you must change your organization. And then double there. You will be proud of yourself when you do it. You know you can. We know you can; we cheer you on.

Doubling is not enough, but like 12 lawyers at the bottom of the ocean, it's a good start.

Business Value Communication

In March I did a short workshop on Business Value Engineering at ScrumGathering in Orlando. Very interesting to me, although it was mainly about the work that the attendees did.

As I commented to them, it certainly was not about what I said. It was not even about what they learned in the session. It is about what they will do. Later.

What did I learn? Well, there is always so much more to learn about this subject.

One thing that became obvious to me is the importance of BV communication.

One of the main reasons to do Business Value Engineering is so that "everyone" can talk about it. So, it needs to be a set of words and ideas that everyone finds interesting, fairly simple, and compelling. Everyone starts to talk the same language. I find this currently very rarely.

Just to talk about it enough so that the basics feel, well, basic and well-understood.

I guess it is useful now to talk about the larger purposes of communication, at least in this context.

So, let's put this in the context of Scrum and talk about the following people:
* Product Owner
* ScrumMaster
* Implementers
* Stakeholders (to the PO, in this case; typically people in the business side of the company)
* Managers (too broad, but we'll leave it at that for now)
* Customers

And of course we can have other groups of people also.

Now, let's restrict this further for now, and say we want a common understanding for this effort (say, next 2-3 releases for a given product) of what Business Value means (and, implicitly, how we will measure it).

So, what are the benefits of communication in this restricted context?

Well, my quick answer includes the following:

• getting everyone on one page
• getting several hands on the elephant, to help discover more fully the true nature of BV for this effort
  
• affecting concrete team actions; eg, what each implementor does
• reduce conflicts amongst stakeholders (since they can see clearly where the greatest BV is and isn't)
  
• minimize the PO as a single point of failure
• by becoming clearer in expression, we become better able to identify flaws in concepts and theories
• as suggested earlier, once we clearly and more concretely conceive of business value, we can then work harder on measuring it (which is typically hard)
• motivating the team

Do any of these need further explanation?
Aren't all of these fairly obviously compelling?

To clarify the bullet point about metrics, let me use words that my 6Sigma friends like to use. They say it is fine to have a general definition of a metrics, but then one must have also an 'operational' definition that allows one to actually measure. Some people need the wordy definition, some people do better seeing exactly how you will measure it.

These are some benefits; no doubt others to add and better ways to express them.

Your thoughts?