Jeff Sutherland video: Basics of Scrum

Nice video. 5 minutes. Highly recommended.

Complex adaptive systems. Kind of important.

http://labs.openviewpartners.com/videos/a-few-observations-on-the-structure-and-foundation-of-scrum/

"The bad news does not get better with age."

"The bad news does not get better with age."

I use this phrase, this key principle, several times in my Scrum courses.

I say:
"Women get better with age,
Wine gets better with age,
And cheese gets better with age,
But the bad news, in our business, does not get better with age."

Digression: A long, long time ago in a place far, far away I saw Diane Lane act in a play (Runaways) at the Joe Papp theatre in NYC. (Where I lived for a long time.) She was a kid. I liked her then, and I have remained a fan ever since. Anyway, she and other wonderful women have definitely gotten better with age.

And often I talk about the data on bugs, and how the effort to fix a bug grows exponentially with the delay in identifying the bug.

And I think this exponential growth in the badness of the bad news is common throughout our knowledge creation business (yes, that's our business).

And so I say: "You have to slow down to go fast."

As an example: You have to slow down now, and create the automated tests to find the bugs quickly, so that you can go fast over the full course of the project. Yes, it costs a bit to write the automated tests, but by avoiding the exponential increase in cost (time), we are able to go much faster.

Lessons from the trenches (of Scrum)

I was talking to a great person at a firm that will not be named.

He is in charge of a large implementation of agile for a large group within a much larger organization.

They start their teams with agile (Scrum) training and a hands-on workshop. And also provide coaching to each team from a senior agile coach. It is hard (in simple terms, due to overcoming the company culture), but they are making progress.

He said after 18-24 months into the transition, he has two big lessons (for himself).

1. Must have full-time ScrumMasters. And develop them.
2. Must have better Product Owners (and full-time). Specifically, for one thing, must have them take the Product Owner course.

Lots of other things to fix and improve (as is always the case). But those were the two biggest lessons.

One of his big lessons for the product owners is what I will say this way:
"Never do the 100%-100% rule ever again!"

This is a play on Pareto's 80-20 rule. And what he is driving toward is very similar to the Minimum Marketable Feature Set idea (discussed, for example, in "Software By Numbers" by Mark Denne). He is not sure they will ever succeed in doing the 80-20 rule, but for sure they can stop doing the 100-100 rule.

A few key, actionable ideas, not from me, but from someone in the trenches. Perhaps they are helpful to you.

Loneliness

I have a book by Rollo May that I have barely started to read: The Courage to Create.

This seems to me an important topic, creativity, because it is what I am (hopefully) training teams to do. To be more creative. And what he says is that it takes courage.

It seems that one aspect of this is loneliness.

Each human being is unique, and so perhaps naturally because of that fact, we each feel alone sometimes. We feel we do not understand the other person. We feel they do not understand us. No doubt, this often indeed is true (ie, not 'just' a feeling, as we sometimes say). (Note: I am guessing that 'feel' is not considered a 4-letter "F" word in your local culture. If it is, you have my sympathy.)

Lean-agile-scrum offers some remedies for this problem. Not full solutions, but, I think, improvements.

First, it says to management: Don't just do something, stand there (ie, leave us alone). More than just a chuckle, this is a good thing. Although perhaps it still, even today, needs more explaining (but in another post).

Second, it tells us as a team: Don't just stand there, create something. In the form of working product by the end of the Sprint.

And while the product may be crappy, or not what the customer really wanted, at least we have broken through our loneliness and our fear, and started to do something. And enabled some feedback.

And we are doing this as a team. So, in that way we are also no longer alone.

And, finally, we are doing it for "the customer", and so we have broken through our isolation, our loneliness, that way. It is wisely said "it is more blessed to give than to receive", and in the daily acts of lean-agile-scrum the team, with grace, may start to feel whole again as they start to fulfill that prophesy, that idea. They are willing, they are wanting, they are waiting to see if they have given the customer what he/she/they truly want.

EM Forster said: Only connect! And lean-agile-scrum is enabling at least some kinds of connection. Some collaboration. And even if it starts with mistrust and awkwardness, usually we can get both the teenage boys and the teenage girls dancing with each other by and by. It is a bit painful to watch, but by and by they start to even smile at each other. If you follow my metaphor.

Loneliness, perhaps with both the introverts and the extroverts, comes up in many ways as we do our work. As a reminder: Of course some of us need some alone-time. This is not loneliness. But any of us, on a given day, can feel, in our work, lonely and defeated.

ScrumMasters: please consider loneliness more as you strive to help them team remove its impediments.

It is probably not necessary to say this to most ScrumMasters, but for others I will say this. John Lennon said that life is what happens while you're busy making other plans. Which is to say here: One need not make loneliness, or at least the pain of loneliness, an explicit topic in the team room. One should just get the kids off their butts and get them to dance together. Sometimes talking too much does not help. You just have to act quietly. And get them acting.

A wise person taught me that again recently. (Thanks!)

Agile & Religion - 1

I heard recently someone comment: "Well, watch out for those guys who get too religious about Agile. We don't want that around here."

This general topic gets talked about in the Agile community a lot. And, I think, often ineffectively.

But I think it is a difficult topic. It is hard to explain the issues around this well.

So, I will try to do several posts with specific examples and situations.

The first thing to say is that lean-agile-scrum is mainly about results. Results for the individual, the team, and the customers. Results such as: better products, higher quality, more fun, better work.

It is not about doing Scrum just for the sake of doing it. As though purity of Scrum, alone, were a high value.

It is important to say that virtually all the people who are experienced with lean-agile-scrum are concerned that they see too many people doing it "weakly". Schwaber talks about 'flaccid Scrum'. The XP guys talk about how Scrummers don't have strong engineering practices. Others talk about ScrumBut (or ScrumButt). And there are other phrases.

What is important is that they have a sense that playing Scrum 'weakly' means that the people are getting FAR less of the value than they deserve.

In summary for now: lean-agile-scrum is not about religion or belief or faith. It is about reality and testing and real results. That seems to me to be pretty far from 'religion' as most people use that word (when they use it as a put-down).

The next thing to say is: when a Scrum advocate talks about doing Scrum better, we should talk more about WHY 'better Scrum' means a better life or better results. More on this in the next post.

What we do...

Here is an interesting post by Daniel Glyde, about what his team does at wiggle.co.uk

Scrum, and....

http://danielglyde.blogspot.com/2011/03/agile-software-development.html

Scrum, Sprint Zero (NO), and Prototyping

I was talking with some smart people at a client. They said: "We do a Sprint -1 where we do rapid prototyping. We do a Sprint every day, produce a new version of the GUI, etc and review it with the customer team daily. It lasts for 2 weeks, or did last time. It is mainly visuals to help us in discussions with the customer about what they really want. Generally low fidelity, generally throw-away code (to the degree it is coded)."

I am, perhaps slightly famously, against the Sprint Zero concept. I will describe that more fully elsewhere. But the basic idea is that I don't like a Sprint that results in no working software. More generally, I don't like a Sprint Zero because it includes (mostly/only) work about which the team can get no objective feedback from someone useful...did it contribute toward what the customers really want?

So, it is mainly the lack of real feedback that troubles me.

So, how does the situation presented by this client compare to this?

To me, the client is doing an excellent job, at least so far as we can tell from the conversation, in trying hard to understand what the customer really wants. In general, I find abstract conversations with customers are of low value, while conversations that include visuals, and include, where relevant, some work flow, can be much much more useful. This seems to be the case.

That they produce some 'working product' DAILY that can be usefully discussed with the customer to get feedback seems excellent. Yes, this working product is not working software as we typically have in a Sprint in Scrum. But this seems far less important in this case than that they are increasing and tightening the feedback loop with the client.

That they call the 1 or 2 week effort Sprint -1 does not thrill me, honestly. It suggests to others that a Sprint Zero concept is ok, even good. That someone speaks of doing a daily 'sprint' within the Sprint -1...well, as an English major I want to quibble about word usage. (Minor really.)

That the prototypes are throw-away does not seem, on the surface, ideal. But maybe quite appropriate.

To me, the main thing is that they are increasing rather than decreasing the feedback. And tightening (speeding up) the feedback loop. This has to be good.

What is less clear (at least from that conversation) is how well the feedback is happening through the rest of the delivery effort. Perhaps more on that later.

Net, net: Some people feel that every accommodation made between Scrum and reality is necessarily not doing Scrum 'right'...although maybe still the right thing to do. It is true that too many people are subtracting from Scrum (which we tend to call 'ScrumBut'). And in almost every case we find that to be....not good for them, really.

But adding to Scrum, and I want to call the above usage of 'Sprint -1' an addition, adding to Scrum is, in general, necessary and typically a good thing. Yes, a Sprint Zero (as described above) would be a bad addition, in our view, but in general additions to Scrum are necessary and useful.

The key is: are the additions made in the context of lean-agile-scrum values and principles. Such as, the principle of increasing the feedback so that the bad news does not get better with age.

Sometimes, two or more lean-agile-scrum principles will come into conflict in a specific case. Then the question is which principle should have precedence.

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)!

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.

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.

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.

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.