Public Impediments List !!!

This is essential in Scrum.

Why public? Well, so everyone can see and offer feedback on what are our team's biggest impediments.

Oh, and the list is prioritized. If the priorities are not obvious, then the ScrumMaster breaks ties.

And the real juice is that the SM is making sure the top impediment is always getting worked.

And there never comes a day when there is not a top impediment. (We never become perfect.)

Now, it may also be that the public impediment list reminds the SM (and everyone else around) why the heck we have an expensive person over there *not* doing "real work." (By the way, I think the SM easily pays his board by removing impediments. But you do the math. Of course, that assumes that the company culture does not stifle all the impediment removal efforts -- which has been known to happen.)

The exclamation marks in the title are there to suggest that way too often we find teams without a public impediment list.

Your thoughts?

Technical Debt

Here is a wonderful video by Ward Cunningham about Technical Debt.

http://www.youtube.com/watch?v=pqeJFYwnkjE

Thanks to my friend James Collins for finding it on his iPad.

You may want to 'wikipedia' Ward Cunningham, if you don't know him well. There is some irony here, since Cunningham invented the wiki concept (aka wikiwikiweb) and implemented it first, and his c2.com wiki is still considered, by those 'in the know' as the 'mother of all wikis'. It was the first wiki. Wikipedia is now perhaps the best-known wiki, of course. There are many other things worth knowing in re Ward Cunningham.

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/

Little's Second Law

One day I was writing down quotes to be printed in a HUGE font and put in the team room. On that day, I thought it would help (and actually, I think for that team, it did help).

Anyway, this sentence came to me:

People are remarkably good at doing what they want to do.

Apparently no one has ever said that, so I now, for fun, I call it Little's Second Law. To be honest, God gave me the phrase -- I did not work to figure it out; it was just there in my brain in one moment.

Again, to have a little fun with Little's Law (which I agree with, but definitely did not invent), I call it Little's Second Law.

The other day I was doing a workshop, and someone remarked that people were having fun and being a lot more creative. They implied, somehow, that if a person really wanted to do something, they put a lot more energy into it. And the results were always better. Someone said 5x more new ideas (of equal value) come out in that situation.

Of course, to many of you, this is obvious. And obviously, intellectually I have had that same idea before. Hence Little's Second Law. BUT...it's remarkable how dumb I can be, and I never quite fully made the connection. Or, at least I can say that that conversation in that workshop was an "AHA!" moment for me.

So, two key ideas result for me for Scrum teams:
1. Product Owners: It is up to you mainly to get them to feel that they want to do your (or the customers') stories.
2. Maybe, at least some of the time, we should (we=everyone, including the team) let them do just what they want to do. And see what happens. This is kind of the idea with the Google 20% time.

Tell Her No

Once upon a time, a long long time ago, there was a song called "Tell Her No" by the Zombies. See the video at the bottom.

I like to play it sometimes in the courses.
Here is the YouTube link: http://www.youtube.com/watch?v=6cYdH46HqpE
A simple and stylish song. With quite a message.

I like to let the music tell the message. I think it reaches a different place than my mere words. Some of the guys just want to think, and some get annoyed a bit, but that's ok.

And I like to make the attendees in the course practice saying "No" to some "big, bad" manager. Whom I pick out from the attendees.

I also strongly try to get this message across: "The team must explain the consequences of technical debt to the product owner. The product owner has to use good business judgment in listening and questioning."

We've all lied. But it's better to tell the truth. As your mother explained....because there's less to remember. God, it takes courage sometimes.

I recommend "The Power of a Positive No" by William Ury. (He co-wrote "Getting To Yes", which you probably read.) If you never say "No", the "yes" starts to be meaningless.

Intermediate CSPO and Workshop

Thanks to Maria Diaconu and Dave Muldoon, and with the help of Catherine Louis and others, we have significantly revised our Certified Scrum Product Owner course.

This has been in progress in a way for years. I have long thought that the CSPO course should be treated as a post-CSM course, an "advanced" course.

We have decided to call it "intermediate" because, well, attendees are not advanced yet when they take the course. We are basically assuming attendees have taken the CSM, or done something else roughly equivalent.

Here is a description of the course:
http://leanagiletraining.com/RDUCSPO/RaleighCSPO+WS.html

Others and I think this is important. Because very often our biggest impediment is "PO is not good enough". Not that the person is not a good and capable individual. But the person is relatively weak at playing this new and unknown role of Product Owner. As any newbie would be for the first 2 years.

It is a difficult and also very important role. Much of the success of a Scrum team relies on the abilities and the execution of this role.

Workshop
Catherine Louis got us introduced to workshops, and now the attendees have totally convinced me this is the right way to go. Two days of 'course' is as much as they can take at one time. But the learning does not become nearly as 'real' until they do the workshop, for 1 or 2 days.

For the intermediate CSPO, we are modifying the Workshop a bit. It will work like this.

1. We will tell attendees in advance what their options are.
2. One option is to take a real project and do Release Planning (3/4) and Sprint Planning (1/4). If we do not have a real team, then the person with the real project becomes PO and forms a 'team' from workshop attendees. The ideal is to bring your real team that will start the project on Monday.
3. One option is to take all or part of the Business Value Engineering process (explained in the course), and work on that. As a team. Again, this must be real life at least to the PO leading the team in the workshop. Note: In the course we gave BVE theory and tools and some experience, which the team can then apply.
4. One option is to work as a team in solving real life impediments. We teach the A3 method for impediment removal, and typically the team does some part of the A3 process. Or something very similar. Sometimes a time spends some time doing #3 and some time #4.
5. Within reason, we are open to breaking any of these rules (above and others), so long as the person(s) has a good chance of achieving some better value.

How and why does this work?
Perhaps it is already obvious to some readers.

In the act of doing real work, all the real problems of life come up. And are either addressed by the person, by the team, or the coach (eg, me).

Sometimes it seems funny to me, but in effect they say, after we talk, "oh, so, you were really serious when you said XYZ [about Scrum] in the course?" In other words, the real work in the workshop forces them to make real connections between the ideas of Scrum and the reality of day-to-day work and getting the working product out the door to the customer.

Again, these are not my insights or assumptions. This is what attendees of the workshop tell me repeatedly. Everyone who has talked to me about it says it is very valuable. Often the most valuable thing!

People work as teams, and all the issues of teamwork come up. (Not always happily, just as in the real world.) And they learn from the team experience. They experience that they can mostly do what we talked about and did exercises on in the course (with maybe minimal help or reassurance). This gives them much more confidence in facing the real world after the course.

We coach from the sidelines. That is, I think we are smart enough to sit down and get out of the way. We are available whenever anyone has a question. (Occasionally if it is a question others will be interested in, we stop the workshop briefly to discuss with all.)

We also interject when teams are doing something new and when we know they need a bit of coaching. Or when the team is obviously 'stuck'.

Please tell us if this answers most of your questions about what the workshop is.

Lame Scrum Implementations

I was talking to a colleague about one problem, and then said, "but this is not our biggest problem -- our biggest problem is lame scrum implementations."

So, I thought I would discuss that.

First, truly, our biggest problem is not Scrum or anything to do with Scrum. Our biggest problem is to figure out what "the good life" is, and then to live it. (A nod to Socrates.)

But, if we take the premise in business (which I do) that Scrum helps us live the good life, then anything that hurts Scrum, hurts us.

And I think Scrum, unfairly, is getting a bad reputation because of lame Scrum implementations. And, more to the point, people are suffering with 'less good' lives because of bad Scrum implementations.

Now, in every case I have seen, a bad Scrum implementation is better than what they were doing before. Still....

OK. What are the root causes of bad Scrum implementations? Here are my top 5.

1. Bad team.

By this I mean a team that is fundamentally not competent for the work that they have to do, or is fundamentally dysfunctional.

This is pretty darn rare, but I have seen it happen.

2. Bad company.

This is a company or company culture that apparently does not allow any impediments to be removed. Or almost none. Or only at great human cost.

I find this issue to almost always be there, to some degree. Except that I feel (and yes, Virginia, it is hard to call this more than a feeling based on lots of experience) that people feel more powerless to change the company than they really are.

Now I have companies so bad that I have said "well, if you can't change your organization, you have to change your organization."

Still, as the key root cause, overall I rate it fairly low (second).

3. Low knowledge.

Mainly this is low knowledge of Scrum, or of how to make a business case to managers to fix the impediments around here.

I find this very common, bordering on universal. But the main root cause of this cause (ie, the reason is does not get fixed sooner) is a lack of aspiration. IMO.

People always misunderstand Scrum to some degree. People always do it wrongly (at least for the first two years), as any beginner does with any sport or any musical instrument. We have knowledge decay. Etc, etc. This is not so hard to fix once we recognize it and mitigate it.

4. Serious technical debt.

I won't try here to define technical debt. But let's just say that legacy systems are hard to change. So, the team that works with a 'bad' legacy system can seem to have a lame Scrum implementation and get almost no velocity of new story development.

And the underlying problem is serious technical debt.

Again, this can be fixed in due time. If there is the aspiration to do so.

5. Not sufficient aspiration.

So, this ends up being the classic problem of leadership. How to...
a. Get them to see a common problem that they really want to fix, and
b. Get them to feel that it is not impossible to fix it.

Or...how to ask for something, but not too much.

So, earlier I have almost said that lame Scrum implementations arise, fundamentally, because of lack of aspiration. Either people don't see the possibilities or they don't want them enough.

I think Scrum holds a lot of potential. In every dimension of improvement that we want.

So, why is this not seen better? I think there is no one person to blame. We can all get better. The 'Scrum guys' (such as I am) can explain it better. The leaders can lead better. The teams can have more courage.

And the teams will have more courage in time, as they start to believe we actually really mean 'self-organizing' in a sensible way...that it is not just another of a thousand meaningless slogans.

Does this breakdown of root causes show you a path to action?

The Four Key Things

In my courses, I strive for 4 key things.

1. I want you to believe "I can do it".

2. I want you to have some clue about the direction and what you want to do.

3. I want you to be scared. Yes, scared. At least some.

4. "If you wait for perfection, you might wait too long." So, don't wait. Start now.

Why scared? Well, I want lean-agile-scrum to be so important, so good, so useful in your opinion, that you are anxious that you won't do it well enough. You know you don't know enough to do it perfectly. While it is simple, yet it is complex. You know it is hard. And yet, you still do it.

So, you can see that balancing 1 & 3 is hard.

Of course, you know the definition of courage. It is: Doing something even though you are afraid. If you do something with no fear, then there is no courage. You might be overly-confident, or you might be foolhardy. But you are not courageous.

And I know you have courage.

Let me end with two Yogi-isms. (Yogi Berra, that is.)

When asked "what time is it?", he answered: "You mean now?"

He also said: "The future ain't what it used to be."
I like to think he had become more optimistic. With every mistake we must surely be learning.

"Leader's Guide to Radical Management"

Being a bit too busy, I only just got a copy of The Leader's Guide to Radical Management by Stephen Denning.

I recommend it.

It is not so hard to learn, for example, Scrum, and apply it to one team.

But I always hear that, in any large-ish organization, "we need to change the culture".

Ok then. One way is to read and apply Steve's book.

Another way, as you may have heard, is: "Be the change you want to see in the world." Use your experience as one good Scrum team. It may be that, alone and by yourself, your one change will have little effect. But action speaks a thousand words, and others will come beside you and dance the same dance, if you dance it in joy. And once you have two or three, or 7 or 14, then it is amazing how powerful you all together become.

As a small group, you quickly can become amazingly powerful. You know this; you have seen this this year, you have seen it in 1989. You have seen it in 1776. You do not need to see it again to take action.

So, Steve's book will help you see the broader picture of where we are going. Where we want to go.

Creation myth

It is Sunday morning as I write.

I like to read different bibles, from different cultures. It is my intuition that while they are all different, they are also all trying to give us pointers towards the truth. Sometimes the pointers are a bit rusty and bent, but if we use a bit of imagination (thank you Mr. Blake), then we can find our way a bit better. Even with the bent and rusty ones.

In the Hebrew bible, there are several creation myths. How the world was created, and maybe why, and maybe a hint or two about 'what is it all about, anyway?'

And the Christian bible has a creation myth too. "In the beginning was the Word." And a few lines later: "In him was life, and the life was the Light of men". And then a few lines later: "And the light shineth in darkness, and the darkness comprehended it not." An interesting progression. All Agile advocates can understand that last phrase, at least in the mundane way, that we try to shine what we think is a light, and often it is not comprehended.

Now, for those to whom the past is not prologue...

In the New Yorker, Malcolm Gladwell has another creation myth he wishes to describe. (I think he means it in not as profound a way as the Bible. Certainly I am not suggesting that it is as profound.) It has to do with Xerox PARC, Steve Jobs, and the creation of the Personal Computer. And of modern warfare. He is really talking about creation, invention, innovation, creativity. Which is what our Agile teams do. So, I think, a very important topic.

Read it here: http://www.newyorker.com/reporting/2011/05/16/110516fa_fact_gladwell
Or at least an abstract. And decide whether to read more.

Here's what I think he says or implies, over-simplified into 2 points. (Which is usually one more point than I can remember for more than a day.)

1. We can win more and faster as a team. Meaning: If we pick the right diverse mind-sets (individual people), and put them in a team and let them fight about the product in multiple dimensions, we can get better innovation faster.

2. We win by being like the tree in my front yard. Meaning: We throw out many many seeds, most of which will die. Most will be "failures". But those failures are good because they mean more possibilities will be considered, and we will discover those few possibilities where the new tree can truly flourish.

It feels risky, it feels wasteful. Yet, it is the way to win. And to have fun. But it does make me sneeze. (Literally: I have allergies now, as I am older. Symbolically: Probably still true.)

No, no: It is the way to make people's lives better. Maybe even yours.

Malcolm Gladwell is, I think, a wonderful writer, and you may take different conclusions from his story. Please do.

Courses Coming Up

We have several courses coming up.

Certified ScrumMaster (CSM) course - This is the basic course, which we recommend for everyone and for teams. We are now almost always including a 1-Day workshop. Strongly recommended. And, occasionally, a 2-Day workshop.

Places: Charleston, Knoxville, New York, Charlotte, Ottawa.

Advanced Certified Scrum Product Owner course - In this course we insist that everyone who takes this course already have taken the CSM course. And it deals with more advanced topics. And we also include a workshop.

Places: Montreal.

Certified Scrum Product Owner (CSPO) course - This is the course for beginning Product Owners. With a workshop. In this case, we expect to be in the Rally offices, which is kind of cool. (Rally Development makes the Rally tool.)

Places: Raleigh.

Scrum 201 - This is an advanced course. We must have a CSM and some good experience with Scrum. With a workshop. The purpose is to help you move to the next level. And to try to answer (or help you answer) all the detailed questions that come up when you implement Scrum.

Places: Charlotte.

For more details (dates, etc.) see: LeanAgileTraining.com

We like to do in-house courses, and we could do any of these courses at your firm.
And we have other courses in the works.

Some of these courses are co-taught with my colleague, Catherine Louis. She brings a different viewpoint and a wealth of experience leading an agile transition at a large corporation.

And don't be shy about asking me or Julia Hill (julia.hill@leanagiletraining.com) questions.

"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.

Leadership - 2

"To lead people, walk beside them ... As for the best leaders, the people do not notice their existence. The next best, the people honor and praise. The next, the people fear; and the next, the people hate ... When the best leader's work is done the people say, 'We did it ourselves!'" —Lao-Tsu

This quote, perhaps relatively well-known to some in several different translations, was found on the Tom Peters blog. Maybe you will enjoy it.

Simple is hard. Staying 'out of the way' is hard, for example.

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

Leadership - 1

Takeuchi and Nonaka have written an article on Leadership in the Harvard Business Review. The latest issue.

Since they are the godfathers of Scrum, one feels compelled to discuss leadership in the context of Scrum.

First. we must note this is a big topic, and with somewhat different issues depending on the size of the firm. Also, leadership is separable from lean-agile-scrum.

Within the context of Scrum, let's over-simplify and consider leadership at three levels. Within the team, immediately around the team, and top-level leadership.

Within the team.

We find that the most important thing that a team does is create knowledge. (Knowledge creation has been one of the main topics for Takeuchi and Nonaka throughout their careers.)

We find that power and knowledge creation do not go well together. Let's mention some words that go with knowledge creation: innovation, invention, creativity, discovery, seeing new, finding creative unexpected solutions to tough technical problems, intuition, prescience, sympathy.

And the innovation, the new new product, must be not only clearly new, but also relevant to the customers. And, usually, something that can also make money for the firm. And we want all three of these (new, for customer, brings bucks) to the utmost degree.

So, inventing a new product is somewhat like magic. Certainly in some degree, it is magical when successful.

So, perhaps you can see now why power and creativity do not work well together. We want all the team to contribute together, to try to see, like blind men, the full elephant together. Acting from power, or even just perceiving power, can inhibit this creativity. Or so it can usually. And the inhibition is hard to see or feel.

Leadership and power are not the same thing. Of course. Although they are often thought to be related.

The Product Owner and the ScrumMaster are often thought to be leadership roles. And I would agree. This means, when things must happen or when decisions must be made, they should make them. Typically, each in his own sphere. (We won't go here into the distinctions between the two roles.)

As Yogi Berra said: When you come to a fork in the road, take it. Or, as Ken Schwaber has said: Few things are worse than not taking the decision. It is almost always better to take the decision and learn from the results. (Not always, but almost always.)

We also recommend each member of the team consider himself or herself a leader in some area (typically, the area where he or she is strongest). Depending on who each team member is, this may not be realistic, but I suggest it is almost always realistic to some degree. In any case, we suggest that team members consider that they are all responsible for the success of the team. This means that. when they see something that should be exploited more, or a problems that must be addressed, that they each have the right and the responsibility to step up and lead in addressing that issue.

The standard leadership style recommended with Scrum is what Robert Greenleaf called Servant Leadership. The simplest version of that is the ScrumMaster who asks the team 'what is your biggest impediment now?' and then goes about getting it addressed.

The more complex version involves a few things:
* caring for the team (so that the team know it)
* trying to help the team be more successful, both in their immediate effort (the new product goal), but more broadly as a team and as individuals, each in his own life.
* being willing to sacrifice himself for the benefit of the team
* respecting the team

Let us stop for today on this difficult and interesting topic.
More soon.