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?
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.
Nice video. 5 minutes. Highly recommended.
Complex adaptive systems. Kind of important.
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.
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.
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:
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.
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.
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?
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.
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.
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.