What to do first?

I just got an email from someone who recently went to one of our Scrum courses. [Note: This is a long but, I think, interesting post. Bear with it, if you can.]

QUOTE
Hi,
Let's say one is going to work as a team lead for a software project in an organization that currently does not use Scrum and that may or may not in the future.

Let's assume that the org currently uses a matrixed structure where developers are shared between projects and their time is allocated via some sort of resource manager to individual projects.

Let's also assume that you, as the new team lead, can't just unilaterally say that you are going to manage the project using Scrum but have to peacefully coexist in this matrix environment.

Let's also say as the team lead you wanted to introduce Scrum but realize that trying to initially go 100% Scrum wouldn't be organizationally possible.

Finally, the question ...
As a team lead in such an environment, which Scrum/XP practices would you try to introduce first, in which order and why?

Thanks,
Robert
UNQUOTE

This is what I wrote him quickly, slightly edited. (Sorry, can't promise such a long reply to every question. And, as a wit said, "sorry for the long email, I didn't have time to write a short one.")

QUOTE
Hi,

The situation you describe is classic. (With of course a million minor variations.)

So, let me start with the story of the American couple who flew to Dublin in early Dec. They rent a car and travel around the countryside. At 4pm that day they are in a small village, lost, and need to get back to Dublin before dark. They go up to a little old man and ask, "how do we get back to Dublin?" He says: "If I were you, I wouldn't start from here."

We all of course say this. Almost every day. And it is useful to chuckle at ourselves when we do.

Now, I do not mean to minimize the difficulties you rehearse. They are hard. And life itself is sometimes hard. But that's why we do this interesting work.

My brother has also reminded me that there are two times not to give advice. When someone asks for it, and when they don't. Nonetheless, I will give this advice.

1. Start from where you are.
2. Believe in your own power to influence the situation, in large part by recruiting the help of others (up, down and sideways). As you know, to get another person to do what you want, you must help them see with their own eyes why they want to do it (usually positive reasons are best). You win by showing them the truth (perhaps slowly). You can never win (in the long term) with power, so do not pine for your own lack of so-called power. Your power is in being truthful and being right. Be happy that people will all the more readily tell you what they really think.
3. Find an important project and a good team. Including a good PO. (Assuming you will be the SM.)
4. Start working on a round of influencing to a core team of stakeholders, to this effect: Getting them to support you on the project, to make it a success, by using Scrum, and by removing impediments.
5. Get a minimal level of buy-in from this stakeholder team. Perhaps just enough to start the effort with Scum for a couple of months. Get them to buy-in on principle that the new team needs to NOT do things the old way.
5a. For example, I would hope, given your own great personal powers of persuasion, that you could convince them for this one team, that the "pigs" will be allocated at least 80%. Partly because this is such an important project (ah! that's why you wanted an important project). 20% allocation to doing old stuff or helping out other (new) projects.
6. Do a product backlog with business value and story points, etc.
7. Get a Team Room and collocate (as much as possible). It is so much easier for them to learn Agile that way. Maybe this is step 12.
8. Pick a Sprint length (I like 2 weeks almost always...more feedback, faster).
9. Focus on all the core Scrum things: the 3 roles, the Daily Scrum, the Sprint Planning Mtg, the daily work, the Sprint Review, the Retro. And the Scrum artifacts: Pro Bklg, Sprint Bklog, Scrum Board, Burndowns (or Release Burnup), the "potentially shippable product increment". The Impediments List. Fix the top impediment (over and over again). And the values and principles behind them.
Note. There will never come a day when they (and there are many people in "they") totally understand Scrum (or even you do). They will forget. You will always be explaining Scrum, and why each piece is useful.
Ex: George may understand the Daily Scrum for awhile, and then he will forget, or stopping doing it as well. The SM must explain it to him again.
10. Deliver something meaningful, at a reasonable date. Let's say in 2 months (4 Sprints). Release 1.0. [Note: This period can vary a bit...but remember the business side is your friend (or will be soon)...they want stuff now!]
11. Once you start to make the business side happy, work with your PO (a business guy, right? well, typically)...to gather their buy-in to helping you push down impediments. Now you start to have some real power behind the changes you want to make. IT managers can drive you nuts, but magically they often shut up when the right business guy is in the room. Funny how that happens. Explicitly or implicitly, the senior business guy is saying "we have business goals to accomplish, and all that IT political BS is not helping. Get the heck out of the way of my effort."

Notice a few things:
1. I kept all of bare simple Scrum in the initial "big change".
2. I did not suggest big changes to engineering practices first. Planning Poker, yes. User Stories, yes, probably. Anything else from XP that I can get "for free". But my political capital is not put there first.
3. I bent them, but did not break them.
4. I did not even talk about how you convince the team itself. Sometimes that is an issue.
5. Lots of things might be issues. But you won't get all issues throw at you in a specific situation. Only fight the issues you really have today.
6. If you have to compromise on Scrum (team allocation, interruptions, etc), make it clear/visible (in a nice way) and keep asking...is this the best way we can do things? With matrix, I am betting the slide about doing 3 projects at once should be compelling. Discuss that.

Here is another mantra for you to some managers:
"Let me do what I want with this team for awhile. Just think of it as magic. Hold me accountable for getting more results out, and don't ask how I do it, and why I do it this way. Just help me do it." A colleague tells the story about getting expresso makers. "Just think of it as magic. I pour expresso into the room and out magically every 2 weeks pops working software." (Your team may not care about expresso, but you get the idea.)

The Agile community has not scientifically proved this (that Scrum is the minimum), but it is emerging that Scrum is probably the bare minimum that you need to start. That's my answer to "why". There is no better Agile answer to the bare minimum (that has much support). Like all the good Scrum people I know, eventually you want all (or almost all) the XP stuff and all the Lean SW Dev stuff also. Just not on Day 1.

Does this help?
Did you have an "oh, $#!&" moment? Yes, it ain't easy and you have some hard work to do. Go get that Dale Carnegie book (How to win friends and influence people)...or something similar (Fearless Change).

Best regards, Joe
UNQUOTE


Depending on your situation, one of the following might also be helpful.

1. "When you come to a fork in the road, take it." Yogi Berra. (A little humor always helps.)

2. See The Road Not Taken.

3. Keep cranking the sausage maker. You (and they) learn most by seeing what comes out. (Scrum helps instantiate the sausage maker.)

4. In most situations, take a decision. There are few things worse than no decision. However bad the decision was, you can inspect and adapt shortly, and make an improved decision with more information. (This is almost a quote from Ken Schwaber.)

5. If you wait for perfection, you might wait too long. (I guess this is my quote. Said with a smile, since I find that nothing is perfect. And, as Yogi Berra so rightly says, if the world were perfect, it wouldn't be.)

The Nokia Test (6): Estimates created by the Team

Another installment on the Nokia Test.

Before we begin, a quick mention that Jeff Sutherland has done an improved scoring on the Nokia Test. See here.

So, the next item on the test says: "The Product backlog has estimates created by the Team."

Why is this important and what does it mean? Meaning first.

So, normally in Scrum estimates mean estimates of relative size/complexity in Story Points. See Mike Cohn's book:


Each story (or at least any story in a Release Plan or Product Roadmap) needs a story point estimate. You can't bring into Sprint Planning any stories without Story Points. No, no, no. (If the Story is discovered in Sprint Planning, that's a bit different.)

And these estimates are created by the Team of implementors. Those who will do the real work.

Why?

Well, estimating my own work gives me much more motivation. And responsibility. And a reason (well, another reason) to appreciate how my work interacts with the work of others. If the Story Points come from some other person or group, they don't have the same feeling.

Yes, there is a downside. Not every Team is equally good at estimating. Yes, it's true. But we are convinced that the negatives are more than offset by the positives.

Another key reason for this test is how we will, later, use Story Points to know velocity. And how we will use velocity for many things, from which I will highlight three:

• Tell some managers: "Look at our velocity. We are going at 20 work units per Sprint. Stop hoping and dreaming that we will go at 40 work units. It's magical thinking and it ain't happening. And your trying to make it happen is just making things worse."
• Tell ourselves: "Folks, we're going at 20 Story Points, but we need to do better. Let's identify a top impediment and FIX IT. So that we can go 22 or 25. Now! (But not by working harder.) "
• Face the truth. Velocity is a way to help us all face the truth. And take action. (Ex: If you name an impediment, someone is going to ask: "Ok, what do we do about it?")

OK. That's some commentary to start with. Now put your thoughts into action.

Agile Portfolio Management - 2

OK, so we got started earlier.

What next?

Ummm. One of the goals of Agile Portfolio Management is making sure the most important things are done first. And that all of us are only working on the highest priority things.

One of the goals of Agile Portfolio Management is to enable us to harness change for our competitive advantage.

[Note: Agile Portfolio Management is distinct from Scrum, but I will talk about APM in a Scrum context. In a different context, one would need to explain it differently.]

OK. So how do we do that?

Well, if we have a bunch of teams, let's say 5 Scrum teams of about 7 people each, we name a Chief Product Owner for that whole group. The CPO prioritizes a high level Product Backlog, and assures that all 5 teams are only working on the most important stuff. The CPO must organize the "Product Owner team" so that great "stories" are given to each team. So that lots of Business Value is realized in every release, much more than before.

The CPO is not trying to make individual teams efficient per se, but trying to identify and get the Business Value released (and get the cha-ching, the dollars rolling).

The CPO (and the PO team) is always surveying the winds of change, to enable our company to adapt faster (or to minimize bad impact).

Every month, the PO team is looking at all efforts and teams, and asking: How can we adapt faster so that more BV is realized? They recognize all the different learning that is going on, and see where it leads them. The monthly cycle is largely because this is the typical frequency with which senior stakeholders can engage and participate. So, the PO team is looking across all the teams and saying: Ok, where is the best place to invest now?

Many consequences could arise from these conversations:
* any month a significant effort could be decommissioned
* any month a new effort could be started
* the direction of any team could be changed, perhaps in a minor way, perhaps in a more major way
* the master Product Backlog is refactored with input from all stakeholders
* stories are eliminated, modified, added...and the impact of this is understood and socialized

Thus, at a fairly high level, the overall direction of this group is adjusted. Then, at a lower level, the CPO gives specific stories (maybe larger ones) to each Team. The PO for each team typically will need to organize the refactoring of the (large) stories into smaller ones that can go into an individual Sprint for his Team.

The PO team does not attempt to micro-manage at a level below the Story. And in general, the PO Team does not have time to deal much with small stories, unless there is conflict or important learning needed about such things as: "how does this story fit with our overall direction?" "how does the story in team X fit with another story in team Y?"

More later...

Agile Portfolio Management - 1

A few people have been asking about "Agile Portfolio Management". Or at least about "how do we manage this stuff?" and what they mean is what I call Agile Portfolio Management.

Agile Portfolio Management is of course distinct from Scrum, but for simplicity, I have assumed a Scrum context.

First, Scrum is relatively silent on this subject, which is well and good. It is an advanced subject. And one can't implement "all" of Agile in a single go. So, better to make it an advanced topic.

Still, I have heard others say that if one gets "demand management" down (controlled) in an Agile way, then all the Team stuff (eg, all the other Scrum stuff) becomes so much easier to implement.

One might say: Mura, muri, muda. That is to say:
* Establish an evenness of flow first
* Do not overstress the system
* Then remove waste (or, one might say, other wastes)

Let's unpack these for a moment.

You can't get evenness of flow if the team is constantly being interrupted (for example). So, demand management means you have to control the flow of demand (new features) into the team to eliminate interruptions (and allow change).

You have to get business (and the team) willing to identify each team's capacity and NOT over-stress the team by asking them to deliver more than their capacity. When you over-stress, you actually reduce the real capacity of the team.

Then, removing waste, in simple terms, is removing the impediments identified by Scrum.

Next, some discussion of "single product backlog" (for multiple teams) and "chief product owner".

Note: Apologies for typos in the earlier version.

Reading List CSM Sutherland/Little course

We recently led a course in Atlanta.

Suggested reading included the following:

    

And....

The New New Product Development Game by Takeuchi and Nonaka. hbr.com

The Contradictions That Drive Toyota's Success by Takeuchi. hbr.com

The Concept of "Ba" by Nonaka and Konno.

Comment: For the books, I think it is more colorful and more useful to provide you with a picture of the book and access to Amazon's info about the book. Hope this is not otherwise a problem; I am slightly concerned that it may appear too commercial.

Note: I 

Scrum Certification Test

The Scrum Alliance has recently announced a Scrum Certification test.

Two cheers. This is a minor, good thing.

And it gives us an opportunity to say what makes someone good at Scrum.

Hint: High scores on the Scrum Test probably have very little to do with it.

First, Scrum is a team sport, so how good one person is is almost irrelevant.

Second, explicit knowledge, while somewhat useful, is not the main deal. The juice is in the tacit knowledge.

Third, building unused inventories of explicit knowledge is probably NOT going to help.

Fourth: Courage.

It takes courage to come in each day and face one's own imperfections, and force oneself to get better. Similarly, it takes courage from the team to come in each morning, tell the truth, and face their own imperfections. Every day. (It's fun too, but I think courage is the key.)

And it takes courage to tell the managers of the organization you are in that things need fixing around here.

So...

More book learning about Scrum. Yes, good. Hey, and let's add a minor test just to encourage that.

More courage. Much more useful.

Small teams

I was just looking at The Discipline of Teams by Katzenbach and Smith. These are the same gentlemen who wrote The Wisdom of Teams.



First, my strong bias (which I find is reinforced in many places, including this book) is that all "real work" these days takes place in teams. (Yes, Virginia, I need to add some caveats, but it's still basically true. IMHO.)

Chapter Five of their book is titled: Applying the Team Discipline: Number & Skill. Subhead: "A small number -- ideally less than 10..."

They then give 6 long reasons why large groups are not teams (or, at least, don't have the discipline of a winning team, as they [and I] see it). I will summarize:

1. Large groups cannot easily or frequently meet together.
2. Large groups are biased toward efficient meetings. [Why is this a bad thing?!?! Well, efficiency is not creative, for one.]
   
3. Large groups are biased toward hierarchical leadership.
4. Large groups are biased toward stable roles.
5. Large groups usually fail to build common understanding and commitment.
6. Large groups often subdivide ...[and] create smaller teams [sub-teams].

If your culture does not immediately know that a team is 9 or less, you need to study in this area. [IMHO] Get all the help you can to knock down this impediment.

All business is personal

We are in the political season, sometimes called the silly season. I will avoid discussions of politics, but I said that to introduce a well-worn phrase: "All politics are local."

Whether that is true or not, it led me to the observation that "all business is personal." That phrase and a note on this blog by Shannon Wagner. And a discussion with my sister-in-law in the mountains.

Business is a revealing of who we really are. Business is an acting out of "love thine enemies". Business is the 12-step program to becoming a mature person. Business is how we really help our grandmothers, our kids and those members of our families who have known hard times. Business helps us appreciate that it is more blessed to give than to receive.

Yes, Virginia, there is much evil and much failure in our being and our doing. Business is that process of refining that out, however slowly it may drip out, drop by drop.

Some people think business is about money, as though it were a zero-sum game. This is not so.

Yes, making a reasonable return for capital investors is a constraint. Like side-lines in a football game. But it is not the game. In business, you score each time you make someone happy. Make just one someone happy...(if you remember that song that Jimmy Durante sang).

Agile is personal, for example. It's between persons.

A personal note

In 2001 I was living in NC working as a consultant in NYC.

I remember early on a Tuesday morning, getting on a plane in Greensboro and flying to LaGuardia. I stopped to get some beanie babies for my kids.

And took a taxi to the World Trade Center at about 8:25am.

It was a beautiful September morning, crisp, clear. The taxi driver said there was some smoke at the WTC, so he turned on 1010WINS ("all the news all the time"). "A small plane seems to have lost its way and crashed into the WTC." I needed to take the PATH trains to my client in Jersey City. I told the taxi driver to keep going. I lived in NYC for 20+ years; we don't stop for minor things.

He left me off at Bowling Green. I rolled my luggage toward the WTC.

And the second plane roared past my ear. Or so it seemed. And crashed, with a loud explosion, into some everyday normal people sitting at their desks drinking their morning coffee.

Everyday between 8:30 and 9am there are (were) about 100,000 people in the WTC Plaza area, half in the World Trade Centers and half in transit. You can be sure they wanted to kill at least 50% of those people.

As you are reminded of this event, remember that it affected real people. People just like you. Directly. It isn't about the TV or the radio or the movies or the newspapers or the books. It was real people.

I was there. So I must tell this story, this too true story again. I worked many years in the WTC or going through the WTC mall day after day. They bombed my living room and people I knew.

If it tells me nothing else, I tells me what my mother told me long ago. Be alive now, have the courage to do it now.

Hyperproductive Distributed Scrum

Back on July 21, 2008, Jeff Sutherland gave a talk on Hyperproductive Distributed Scrum at the Googleplex in NYC.

Here is the video.

Self-Organization in Scrum

Last Thursday, Sept 4, 2008, Jeff Sutherland gave a talk on Self Organization in Scrum at Google in NYC. The talk also covered some of the associated contradictions (or perhaps, seeming contradictions).

Here are the slides from the talk. Google video to come soon.

Toward a general theory of business value

I did a presentation yesterday at Agile2008. Here is the link to the slide deck.

I hope it would be accurate to say that being there would have been more useful than just reading the deck. But here it is.

Two key ideas.

Business value is about learning. As a team. BV is always changing (on many dimensions) and we learn, in part, to keep up with that change.

Business value is about communicating to change behavior. As in a lot of situations, it takes some effort to communicate successfully. It might not happen very well the first time you do it. Inspect & adapt.

In addition to trying to reveal all the ideas and assumptions around our use of "Business Value" (or at least many of them), the deck also talks about:
(A) definitions of business value
(B) relatively specific actions during the course of an effort where we can improve our business value engineering

This is a quest for mastery in a very difficult skill. Even intermediate skill levels take a good time to achieve. It is my belief that the effort pays real dividends. So I think I have seen and so I think others have told me is their experience.

The deck uses a circular and episodic approach. All the interconnections between the ideas are not spelled out, and it is for the observer's mind to actively engage and discover them for themselves. The whole is more than the sum of the parts. At least in my opinion.

One hope you can use with benefit.

The Nokia Test (5): A prioritized Product Backlog is essential

We started a series on The Nokia test some time ago. This is the fifth explanatory post about the test. To find the others, search above (left). And here is the original post.

The second item in the second section of the Nokia Test is this:

• There is a product backlog prioritized by business value

Seem obvious? Well, maybe you don't want to say so quickly.

First, if we are doing Scrum, we must have a Product Backlog. A Product Backlog is a list of all the work items the team is expected to work on. If the Team is doing software, most of them will be features at a high or low level of granularity. In Agile, the growing preference is to put these Product Backlog items in User Story format.

This part of the Nokia Test does not require you to use the User Story format. Or any particular format.

"Prioritized": Ummm. What does that mean?

Well, I think it means that the Product Backlog has been put in order of Business Value.

The Nokia Test does not give us any hints about what Business Value is. My opinion is that this itself is a complex topic. But I think the implication is that the Product Owner (who owns the Product Backlog, and makes all final decisions about it)...the Product Owner will put the items in business value order.

Does the test imply that Nokia always wants to work the highest business value items first?

This is open to some debate. My view is that one can still pass the test if one also uses "cost" (or story points as a proxy for cost) and dependencies/risks as additional factors (bits of information) in helping the Product Owner to order the work.

Let's put this some other ways.

The technical team does not have the final decision about what order to do the work in. Sometimes it is better to be inefficient and get some high Business Value item(s) out there in production.

Since all Product Backlog items are not of the same size (let's call this "amount of work" for now...although one must tread carefully here), and not of the same Business Value, the Product Owner must do cost-benefit analysis to determine (implicitly at least) business value per unit of work for each PB item.

Why do we prioritize by business value? We are always trying to discover and release business value (eg, increase customer satisfaction). Quickly. Only if we use Pareto's 80-20 rule can we do the most important stuff first. Ordering the PB items puts Pareto's rule into play.

And I think the Nokia Test says the Product Owner cannot cop out and say each PB item has the same amount of Business Value.

Similarly, this part of the test does not prohibit some team members (developers), where they have useful knowledge, from influencing the Product Owner about business value and about the order of the work. (Still, Scrum says the Product Owner gets the final say.)

* * *

Well, that's a start on the implications from this one part of the Nokia Test.

Please see our other posts on the Nokia Test.

Note: The picture of the story card above was stolen from here: http://www.pragmaticsw.com/newsletters/Newsletter_2008_05_SP.htm

What's a team?

Let's review what a team is in Agile.

A small group: 7 plus or minus two.
Motivated by the vision of one person.
Dedicated (ideally 100% but certainly a lot).
With almost all the skills needed to realize the vision.
The team works together daily.

A team is not:
* Lots more people than that (that's a collection of people).
* Motivated by multiple visions (if there is some similarity in the work, that might be a department).
* Following multiple people (that would be confusion).
* Some folks who work together from time to time.

We give a Team a mission, and we expect them to figure out how to deliver it.

For an interesting discussion about how small teams work in warfare, see Maneuver warfare.

Why are teams important?

This may seem obvious to many of you. But even for those, it may be useful to review.

1. No simple problems. We now need a team to figure out almost any problem. We need the knowledge from multiple people.

2. Creating knowledge. The team is the unit that creates the knowledge. The convert tacit knowledge to explicit knowledge. They brainstorm. They convert ideas to something more real, and examine whether they are achieving the vision.

3. Has "it". We can't describe everything that makes a winning team. One day knowledge. One day skill. One day motivation. Every day something different. But they get it done.

4. Motivation. Creating something brand new is hard work. The team members need to motivate each other to get past all the problems and issues. The team has to find its heart. Once it has it, you can let it run.

5. Clarity. If we have a real team, then when we examine what it produces each Sprint, we have clarity about that. The problems are much more obvious. There is much less confusion. The best actions to make further progress are clearer.

6. Fundamental to make Scrum work. Scrum is built upon a team concept. To get the real value from Scrum, you should start with a team. (I have not thought about it as much, but I think this would apply to all or almost all of Agile.)

* * *

Is your team reaching its potential now?

Kaikaku or kaizen? (2)

I recently did a mail/internet survey, asking people what kinds of training they might be interested in. (If you would like to respond to this, please tell me.)

Someone responded, "how about adopting a continuous improvement approach?" Now, we don't know what the writer had exactly in mind (although maybe I will learn more). One assumes the writer meant something like: "continuous improvement is at least as valuable as more training." So let's play this out some.

In my view, training should be part of Kaikaku...which is a rapid, large, revolutionary change. In my view, there are times to make large changes. For example, when starting Agile. Or perhaps a new project. And there are also times to make small incremental improvements (kaizen or continuous improvement).

The preferred pattern is to have occasional large Kaikaku and many, frequent small Kaizen.

Now in general I am in favor with learning that is closely tied to, and proved by action. Which is to say. "The learner has not learned unless the actions become more effective."

So, training should be used to prepare for action right away.

But let's also talk about what action is. Not as simple as it might appear.

The hardest action is to change one's own mind. The next hardest is to change someone else's mind. (Proper action in the realm of the mind can lead to tangible improvements in satisfaction for real customers.)

Let's look at one example. One can imagine sending someone who is "resisting" agile to an agile course. The resulting action might be no more than a willing suspension of disbelief, so that the team can move forward without active resistance. So, while from a certain viewpoint nothing is accomplished, yet because the team can now be more functional, much has actually changed.

Agile Leadership - 2

This series on leadership arises from a talk by Mary Poppendieck on Agile Leadership. See our earlier post.

Now let's consider leadership in Scrum. In theory. And then later, in practice.

We are reminded of Yogi Berra's quote: "In theory there is no difference between theory and practice. In practice, there is." (A nod to Nancy Van Schooenderwoert.)

Some in Scrum will say that there is no leader on a Scrum team; everyone self-organizes themselves and things emerge. (See the High Moon video, here.) In a very healthy and capable team one can imagine that things might seem that way, but we rather doubt that is the truth. Or at least, not the whole truth. We suspect that subtle signals of leadership are being given and received within the team. (And then we fall back to...what does leadership really mean??)

We also have had teams that, well, demand a "leader" if not a boss, to guide them in (or perhaps even tell them) what to do. In theory this is not good, but there you are sometimes.

Some in Scrum will say that the Product Owner is the leader. She decides the team's priorities by choosing the Product Backlog items to be worked now and by deciding when they are done. Thus, she is the leader. Or at least a leader.

Others might say the ScrumMaster is the leader or a leader. He is not command and control (as stated in the book), but with his Jedi magic, he is nonetheless in effect leading the team toward higher productivity. Clearly it is an important role, since the ScrumMaster's main job is to manage, and see that action is taken on, the top items on the Impediments List. The role is not a mere process coach for a few Sprints or an MC for meetings.

My own view is that Scrum does not really specify leadership. And that this is a good thing.

First, we need to remind ourselves that there is a whole range of essential things about which Scrum remains silent, expecting the team members to add the appropriate things needed to get the job done in their specific situation. I think leadership falls in this category also.

This is good, because no one-size-fits-all set of answers actually works in all situations. It is good because not all teams require the same dimensions of leadership, and not all teams have capable leaders in the correct roles. This is also partly because not all teams have good followers. (By which we mean not sheepish followers, but those people who can see good leadership and support it.)

Let me remind you (although some may already have inferred this) that when I talk about leadership I tend to mean that group of things relating to vision (purpose, meaning, value), inspiration, and people skills.

Another important area (sometimes included in leadership) is to have the right person make the important decisions. To me, who the right person is must be determined decision-by-decision (or area-by-area). The right person to have the last say on the business value of a story is probably not the same person who should say whether some java code is written well enough.

So, the team should probably define norms about how the various team members will lead. And I would recommend some flexibility in that definition. My bias is that everyone on the team is responsible for leadership in one area or in some way.

Here is the crux, in my view. When the chips are down, on that day when things look worst, who carries the heart of the team? Who encourages that team to stick to it? Who comes up with that one useful, inspiring idea? Who won't let the team fail? Who let's the personal issues get discussed, but then gets the team back on track?

My experience is that this leadership can come from many types of people. It all depends on the people involved.

Although we have no simple answers, the team still needs leadership. (Dang, again we are missing that Agile Cookbook chapter that people can follow and check off to see whether they have a good "leader".)

Agile Leadership - 1

I was pleased to help arrange a talk by Mary Poppendieck at Google in NYC last week. The topic was: "A History of Leadership". The talk will be out in video soon. The slide deck is here.

This is an important topic. And, if I may say so, Mary Poppendieck makes a number of great points. I will emphasize a few below.

To me, the first thing is to tease out the various meanings of leadership, leader, leading.

Sometimes we mean decision-making, as in "who should make this decision."

Sometimes we mean boss-ship, as in "she's my boss."

Sometimes we mean guiding and coaching, as in "he helped us discover this."

Sometimes we mean domain knowledge, as in "she is the leader in x-ray tomography."

Sometimes we mean inspiration, as in "I would follow him anywhere." I will include providing a vision and resolving people issues in this category, although they might easily be placed in their own categories.

It seems to me, as I will discuss a bit below, we need to be very careful about these different meanings (and others).

It also needs to be said that there are principles and patterns of leadership, and then there is taking a group of people, forming a specific team, and discovering that specific leader of that team. Even if he leads only for one day.

This is to say that leadership arises from specific needs, and for specific followers. Another set of followers might be in a different situation and need a different kind of leadership. A good leader in one situation will not necessarily be successful in another situation (or as successful).

For amusement, you may wish to peek at one of Churchill's famous speeches. Here's one.

Perhaps the most useful thing to say right now about IT efforts is that they are ultimately business efforts. And success to a large degree depends upon making the right trade-offs between a fluid technology situation and an evolving business problem shared by a customer-base in flux. So, we must visualize the problem and see where technology (with other things) can make a great contribution. In concrete terms, Mary Poppendieck puts the technology leader and the marketing (business) leader into one person, based on the Toyota pattern of a "chief engineer." Certainly this addresses one of our key problems: a "technical success" that it not a market success.

Now, what do we do if we don't have such a single person?

Mary Poppendieck says (rightly in my opinion) that we need two people in the team joined at the hip; a marketing leader and a technical leader. This of course is not always possible either, but then at least the problem is clear.

And this also makes clear the more general knowledge-creation problem. The people in the team with business knowledge must learn how to collaborate in creating combined knowledge with those on the team who are technically expert. And vice versa. Only when the two domains (to make it very simple) are fully engaged can a truly successful and innovative product be created (or emerge).

More about leadership in the fog of war in a later installment.

Kaikaku or kaizen?

As you know, kaizen means continuous improvement. Implying a bunch of small improvement over some period of time.

Small continuing improvements have many virtues to recommend them.

But what if we need a big change? What if we can make a big change? What if a big change is the only things makes sense? (eg, small changes in isolation won't show any improvement until bunch of other changes are also made.)

Then we have kaikaku. A rapid, large, revolutionary change (as distinguished from a set of small evolutionary changes...kaizen).

In Agile, one example is a 2-day Scrum course for the whole team, followed by immediately diving into doing Scrum.

Even kaikaku does not attempt to change everything at once. But it does make a group of changes "at one time" that together are major.

All the time, the Agile coach is asking..."is it time for kaizen, or time for another kaikaku?"

Services We Provide

My boss (that would be me) tells me I must make some money in order to afford to spend time on this blog. So forgive a short post with advertising.

We provide Lean-Agile coaching. See here. Or contact us (contact info is at that site). From one day to 400 days. This is what we do; we're good at it. We do many varieties of coaching.

We also provide Lean-Agile training. In fact, we just opened a new site, http://leanagiletraining.com/ We have been doing training for years, but this site is new. Not as pretty as we would like, but that will be improved iteratively. And more content to add to it.

Within training, we provide both public courses (see that site) and in-house courses (contact us). The public courses are being updated all the time (we have some scheduled that are not showing yet).

You may wish to subscribe to our training course newsletter (monthly)...see on the right-hand bar (Can we help you?) or see the mailing list page at leanagiletraining.com. The newsletter also includes 3 or 4 new ideas each month, which we hope you find useful even if the courses are not interesting at the moment.

...well, maybe not as good as a Super Bowl ad.

Now back to our regularly scheduled programming.

Up the creek. Without a paddle

My friend Mike Vizdos has a blog with cartoons called ImplementingScrum.com.

His latest cartoon is titled "Up the creek. Without a paddle." See here. The idea is that, if you want a specific change to happen or even to stay, you have to keep paddling.

Very simple idea. Very true.

Agile (Lean, Scrum, XP, etc) is a change. A hard change, although also fun a lot too. If you do not keep paddling, then Agile will be viewed as "the flavor of the month". And things will revert to the mean (probably not good Agile, would be my normal guess).

If you stop paddling, things will continue to change. But not in the direction of better and better Agile.

To me, it is a shame to see people stop paddling in the direction of their dreams. Doing one's best is hard, but it is something to be proud of. Something to live for. It may not always be fun, but in a deeper sense, joyful. Every success you have is an example for every other person who feels partially defeated. And the customers around the world need the great stuff you can create. Real customers. Real people. Kids, grandparents, mothers, brothers, sisters, fathers.

(As an aside, let us admit that even customers are not perfect. Many can be pretty bad sometimes. But we still feed even the lesser ones despite their weaknesses. Let us not pray for justice, for who would escape whipping. Let us pray for more generosity than that. The wiser ones have told us: It is more blessed to give....)

So, I hope you will see the value of Agile (of Scrum, XP, of Lean, and related ideas). If you do (and of course it is your choice), prepare yourself for the relentless pursuit of perfection. Prepare for the long march (my phrase for it). Keep paddling.

And have fun doing it. We should enjoy even the struggle part, as it makes us better.

What is the scope of impediments?

Last night at Agile-Carolinas we had Israel Gat, VP of Distributed System Management at BMC Software. He spoke on "Leading the Disruption". He is giving this talk also in Austin, TX (and maybe elsewhere). If you get a chance, I urge you to go. Or just contact him.

After that meeting, I had several conversations. And then thought about them this morning. All that results in this post. Or at least, this question?

What is the scope that defines what might be an impediment?

By definition in Scrum, an impediment is anything that keeps the team from being more productivity. And I personally add that everything is imperfect, so by my definition everything is an impediment to some degree, and the trick is to identify the one or two biggest impediments today.

Scrum has also said that the scope is wide, including such diverse things as engineering practices and personal issues.

What I have not seen talked about much is the scope from an end-to-end Value Stream perspective. So, I would argue that anything that reduces the business value of what the Team produces (or the speed with which the value is realized) is an impediment.

So, as a simple case, imagine you have a Dev team in Charlotte and an "implementation" team in Chicago. (In this context, implementation means all those services around the software that make it actually useful in production.) The Dev team completes their work. The Implementation team is not ready (certainly not as ready as the runner to the right). So no business value can be realized.

I am suggesting this is an impediment. Perhaps the top one for that Dev team. And that Dev team (and their ScrumMaster) need to assure it is fixed (understanding that "a dead ScrumMaster is a useless ScrumMaster"). They probably can't fix it themselves, but they can make many efforts to get others to fix it. Perhaps they need to enlist a manager's help.

To me, this is similar to what Toyota found, ie, that to get the full benefits of Lean, they needed to aggressively train their partner firms upstream and downstream from them in the Lean ideas around flow, pull, JIT, etc, etc.

Does this make sense to you?

The importance of Velocity

I had an interesting conversation about Agile metrics yesterday, and wanted to share one insight.

Why is velocity so important?

Well, first we should say, that in many ways it is not. Honestly. Velocity can be unmeasured, used badly, up, down, sideways, misunderstood. Whatever. As long as the team produces some business value (eg, software in production) that is seen as a positive multiple to what they cost, that is all the counts. Of course, we customers always want it sooner, but as long as the effort realized good business value, then it was not too late. The product helped that customer set; it probably helped society more generally.

Still, in most real situations is also really need velocity. Why?

First, for those new to Agile, the typical operational definition of "actual velocity" is the number of story points from the stories (features) completed in an iteration, based on the team's (robust) definition of done. (Describing a robust definition of done is a good topic for another post.)

Three words.

1. Defense: The team needs velocity because almost surely some manager is going to ask them to do the impossible and go a lot faster (eg, complete more story points in an iteration) than they can go. Velocity is what the team uses to help that manager accept the true.
2. Challenge: While we do not crucify the team based on demand for magic, at the same time, the team needs to be challenged to make their velocity get faster. This means identifying impediments. And getting them fixed (maybe after management approval, maybe by someone else).
3. Justification: "What was it you wanted" is the name of a Dylan song. People forget. Managers will lose interest in Agile if we don't have some data to show them and to explain to them why Agile is important. Velocity is one of those key numbers. It helps explain why good teams, good Product Owners, good ScrumMasters, good coaches are needed. It helps keep Agile from being "the flavor of the month" (if you are persuasive in explaining the numbers).

What do you think? Helpful?

What is a ScrumMaster worth? (2)

Based on comments, I made a few changes to the original post, here.

The specific numbers used in the post are not that important. The approach to logically identifying the value of a better ScrumMaster is. Take the approach, and fill in your own numbers. Help the right people think it through, using their own assumptions.

Your Business Case for Agile

My friends at Innovel have a blog entry titled "Build Your Business Case for Adopting Lean Agile". Take a look.

As you try to get a revolutionary idea adopted, remember that you must always be selling the idea (see John Adams to the right). (Note: You don't even need 50% of your countrymen to agree, if you would succeed.) Your idea may be brilliant, may even be one of the best ideas ever to appear on this planet, yet you must still sell it.

To start anything in business, you need a business case. And given that everyone has a say and an opinion, in fact you need to have a good feel for all the benefits involved, so you can explain the WIIFM to anyone. (WIIFM = What's In It For Me)

And given that change is happening all the time, you even need to keep your business case up-to-date, since Agile will always be challenged with some equivalent of "what have you done for me lately?" People change. People forget. Attention gets re-directed.

So, what is the case?

Well, coincidentally Israel Gat of BMC is giving a talk this week at Agile-Carolinas (and another at APLN-Richmond). "Leading the Disruption". The idea that for BMC, Agile was so successful that it was disruptive, particularly for downstream processes. Such as sales and marketing. In a prior presentation he had shown hard data that to me proved that Agile had given them double the productivity for a large IT shop, compared to essentially waterfall (compared also to what they were doing before).

There are many people to whom we must make the case. Let's assume for now, to a senior business manager (maybe the CEO?).

BMC so far has doubled productivity. Umm. Impressive. In fact, Scrum (the main flavor of Agile that BMC use) was built to increase productivity by 5x to 10x. And it has been proven to have done so with some teams (the community has data in various papers). We don't (yet) have the broad based data to show whether "some" really equals many, most, likely, X%, for certain types of teams, etc. , etc. Based on the anecdotes I hear, most teams are clearly better even when not doing "most" of Agile. And teams that adopt Agile well are typically very much more productive.

Let's look at this a different way. The multi-functional IT teams (including business people, etc) are producing: more, faster, cheaper, and better. All at the same time. As in, higher quality, more accurately what the business needs (not just what they said), faster time to market, etc. What's not to like?

Another benefit senior managers like is visibility. They can tell whether an effort is on target or having problems. (More on this later.)

As Jeff Sutherland says, the ability to change directions quickly, and to focus this fire hose of productivity on a competitor's new feature is very valuable.

As an aside: One thing not to like is people doing cowboy agile. That is, people saying they are doing agile, but who really are not. At the extreme, this means people whose definition of agile consists of "we don't do documentation". Cowboy agile makes your audience more skeptical of real agile.

OK. One more thing on this topic.

How do you prove this for yourself?

Take people to the Gemba; show them the team room, the team, the product owners of successful teams, the working software. (Gemba is a Japanesee word, famous in Lean, meaning "the place where the truth may be found.")

Also, gather metrics from day one. I will talk about other metrics later. Today let's talk about velocity. Gather velocity (the sum of the story points of Product Backlog items completed in an iteration). Show that it is reasonably consistent from sprint to sprint. Then show the velocity increasing. Remove some more impediments. Show it increasing more. Impressive. A blind man can see this stuff.

If the velocity increases by 50% and the business value of new stories is not diminishing, then clearly you've got something going on. All you have to prove is that Agile is a good investment compared to other investments. Not hard if you work at it.

Will every team succeed? No. (Actually even failure is a success with Agile...topic for another post.)

Can fairly good people generally show impressive progress? Yes!

Developer Abuse

Here is another video that talks about why we do Agile. These two (this one and the one just posted) were the top two vote getters (from a perhaps somewhat biased large audience) at the Agile 2007 conference.

It's a bit serious, I think.
Perhaps a bit overdrawn, but I do think developers have a better life with Agile.

My view is that in Agile, we are trying to make everyone's life better: customers, managers, team members, business guys, end-users, our own families. One would hope, that after all those people are helped, that society more generally would be better.

Being Agile is our favorite thing

Here is a fun video from Thoughtworks, titled "Being Agile is our favorite thing".

It might be used as some "evidence" to use to start a retrospective.

The Nokia Test (4): You know who the product owner is

In this series, we are going over each question in the Nokia Test.

The first section of the Nokia Test is a quick determination: are you doing incremental development? Then second section is: are you doing Scrum?

We are now up to the first question in the second section is: Do you know who your Product Owner is?

Clearly, it is not just "do you know his or her name?"

The Product Owner has these responsibilities in Scrum:

• Defines the features of the product, decides each release date and content – gets product backlog ready
• Is responsible for the profitability of the product (ROI)
• Prioritizes features according to market value
• Can change features and priority at next Sprint
• Accepts or rejects work results

A few comments.

The Product Owner is the main voice of the business side into the Team. She is responsible to assure that the team understands everything the business can tell them about the effort (high level and low level).

The Product Owner is the main risk manager, since most risks are business risks, and must be managed as trade-offs against other things (values, risks, etc). At the same time, the team members are seen as business people also (they signed up to deliver business value), so in some ways managing risk is a collaboration. But when the final decision must be made, she must decide (at least, if it is decided within the team).

The Product Owner is part of the team. (This was debated for awhile in the Agile/Scrum community; the best advice now is to treat the PO as part of the team.)

The Product Owner also has outward facing responsibilities. Most of the team members work within the team, in most senses of that word. She is also responsible for understanding the customers (eg, end-users). This takes constant work, since the customers are always changing.

The Product Owner manages the stakeholders. The stakeholders are people outside the team who have a stake or a say in the product being created. Maybe the product is mainly for external customers, but operations must use it also. Maybe Legal or Compliance has some say, etc, etc. In large corporations, these stakeholders take a lot of work (or so it seems to be required). A key area in managing the stakeholders is getting down to one prioritized Product Backlog, at least the Product Backlog items for the next Sprint.

So, how much time does the Product Owner spend with the Team? There is no precise answer to this question; it depends and it varies. But the Product Owner should work with the Team at least as much as the Team wants. And the Team should want the PO as much as having her will improve the product (speed, accuracy, more value, better, cheaper, etc). It is seldom that one can learn too fast or too much.

The typical situation I find is this. The Product Owner person and the Team start out not used to working together. And not seeing a lot of value in working together much. But they learn about the value over time. Toward the end of the first effort, the PO will usually say "Wow, this takes a lot of my time to be with the team, but it pays such great benefits! It is well worth the effort."

Perhaps this Nokia Test item should read: "The Product Owner and the Team collaborate well"

Mura, Muri, Muda

These are Lean words. In Japanese. And I always get them confused, especially the first two, so I am doing this post partly to have a place to remind me what each word means. They are all in the negative.

Mura: unevenness of flow. Thus, the first thing to do is establish a reasonable pull, an even flow.

Muri: overburdening the system. (System being the overall thing you are talking about; generally not a computer system.) Thus, once you establish a production "pipe", don't try to force more through that pipe than it can handle. As a fluid dynamics person will tell you, if you overburden the pipe, it means even less liquid will travel through the pipe in a given time period.

Muda: waste. This is further defined by Type I and Type II muda. And by the classic 7 wastes. "Muda" is an ugly work in Japanese. Kind of like an earthy but dirty Anglo-Saxon word, I think.

The classic definition of Type I muda is necessary waste, ie, something that does not add value in the customer's eyes, but we feel, as a business, that it is necessary. (Compliance with government regs might be an example.) I call this "waste we have not yet figured out how to live without" (maybe not true of all things in this category).

The classic definition of Type II muda is unnecessary waste. I'll call this obvious waste (as soon as you put yourself in position to see it).

There is of course an inter-relationship between the three (mura, muri, muda).

In general, I find these ideas very similar to things we say in Agile, Scrum, XP, etc.

Jim Womack suggested that Lean thinkers practice those in that order, ie, focus on mura first. Then muri. Then muda. Perhaps this is good advice for Agile. (BTW, if you don't know Jim Womack, get one of his books: Lean Thinking. Recommended.)

Two cheers for the Nokia Test (2)

A comment by Kelly Waters and a discussion yesterday with Peter Smith prompts me to add another comment.

Some are attempted to come up with a long list of all the practices involved with Scrum (or Scrum plus other parts of Agile). And then score each team.

I don't think the long list replaces the simple short list. First, for many people, the simplicity is important and necessary. They need a quick, bright line to guide them back on to the road as they start to veer off. The short list does that better.

Regarding the long list...

I have done this (or was required to do it), and found one aspect of it very useless and another aspect very useful. And I just thought of another useful way to use the tool.

Useless: I think generally scoring each team is not very useful. Do I care that one team is 63 and another team is 72? You might do it, but I would not make too much of the number. Each practice is not equally important (and probably the importance varies by situation). I think it would be useful to tell the team "well, you answered 'yes' on 30 out of 40 of these items...what does that tell you?"

By the way, we found it useful for an external coach to walk through the long list with the team (ie, not the team's ScrumMaster/coach).

Useful: Asking the questions, some as yes/no and some with a sliding scale answer, is useful in generating great conversations with the team. The trick is to help them identify one weakness or root cause as the highest priority impediment, and to act on it. ("We need a half-day Scrum refresher course, with a focus on the principles" might be one example.)

Useful 2: I think it might be useful to pull data across many teams, and determine what are the practices that teams generally are doing least. That tells me the "Scrum Center" (if you have one) has done a poor job in communicating the value of the least used practices. Or at least that is a likely root cause. Then the Scrum Center can consider how to communicate why that practice is indeed valuable.

I hope these are actionable comments for you.

Two cheers for the Nokia Test

I am an advocate of the Nokia Test, up to a point.

Why do I like it? I think it is a simple way to set some sort of lower boundary on Agile (Scrum) and it tends to make two problems more visible: Cowboy Agile on one side and Agilefall (aka Wagile) on the other side. Cowboy Agile is where you are doing stuff you are making up on the fly (mainly not doing things you personally don't want to do). Agilefall is where you are doing Waterfall (or mostly waterfall) and calling it Agile (or Scrum). [Alert: Those are my definitions of those terms; others may proclaim somewhat different definitions.]

If the Nokia Test causes people to say, "oh, gee, maybe we aren't really doing Scrum", I think that is a good thing. Especially if they think about it, and decide to do Scrum better.

As with almost anything, it can be misused.

As one example: If people use it as just a checklist, and say "oh, we have 'em all checked off; so we must be doing Scrum well", that would not be helpful. In my opinion.

The Nokia Test only defines an absolute minimum set of things regarding Scrum.

Use the Nokia Test to start some conversations around "Are we really doing Scrum and really getting value from it, or are we just playing at Scrum?"

Passing the Nokia test does not say you are doing Scrum well. Among other things, to do Scrum well, you must really understand the principles and the values of Agile. So, for example, the Nokia Test does not talk about principles. The Nokia Test, in my view, does not even cover all the important practices.

So, it is a test more to determine who is NOT doing Scrum than who really is doing it. It establishes a lower guard rail; if you touch it, you should think a bit.

What does it mean to fail the Nokia Test? Well, whatever you are doing, you should stop calling it Scrum. Does failing the test say you are "bad"? No. Does failing mean you are less productive than before? Not necessarily in my opinion. BUT...although you might be more productive than your waterfall days, I think you are likely to be quite clearly less productive than you could be if you followed Scrum a good deal more closely.

One final thought. I really think using Scrum well can make your teams a whole lot better. But the real point of Scrum is not to brag "I'm doing Scrum just as they told me", but to say something like "Scrum is helping us produce a lot more business value each month....". You should want to do purer Scrum to get more business value, not just to be a purist for its own sake.

The primacy of learning

I am taking the view more and more that learning is the central thing about business.

What does this mean?

First, learning by itself is not that meaningful. It is learning combined with action. And then that simple seeming dichotomy (between thinking and action) is really not so simple; for example, one of the best ways to learn is to take action and inspect the results.

But is we stick with the simple dichotomy, we want more and faster cycles of thinking and action. Learn, act. Learn, act. (A slightly modified version of the Deming cycle.)

So, in business, my bias is that the key action is providing the best solution you can to the customer's (customers') problem. And learning, in various ways, makes those actions better.

And since the customers are always changing and their problems are changing every minute, there is much to learn. So, what do we need to learn?

• what the customer's problem really is (now) (which means walking in their moccasins)
• what they want as a solution
• who we (the solution providers) are, and what we are capable of (now)
• how are proposed solution fits into the context of the firm and of society (eg, can we pay our shareholders a good return)
• what technology we should use and how to get the most out of it
• how all the changes in people, business, technology and society are affecting this situation (both at micro and macro levels)
• how to prioritize the things we need to learn now

My premise is that if we consider learning primary, how we organize people and how we do work changes. But I find, even though I have had this thought before (that learning is primary), it has not yet affected my work and my thinking nearly as much as it should.

The team that learns the fastest wins.

To me, this connects to ideas about the Knowledge-Creating Company and to the concept of Ba.

What do you think about all this? Is learning a key principle as you use Agile to produce customer solutions?

Respect People

"Respect People" is a key tenet of Lean. Of course, who wants to disrespect people?! Still, when people study why Lean works in one company and does not work in another company, the answer the some of the best people give is: Respect People is truly realized at the successful companies.

Jim Womack leads the Lean Enterprise Institute. Go to lean.org.

Womack & Jones wrote Lean Thinking, which you must read.

Last December Jim Womack wrote a letter, in which he talked about what "Respect for People" means in a Lean context. Here's a key quote:

Managers begin by asking employees what the problem is with the way their work is currently being done. Next they challenge the employees' answer and enter into a dialogue about what the real problem is. (It's rarely the problem showing on the surface.)

Then they ask what is causing this problem and enter into another dialogue about its root causes. (True dialogue requires the employees to gather evidence on the gemba – the place where value is being created -- for joint evaluation.)

Then they ask what should be done about the problem and ask employees why they have proposed one solution instead of another. (This generally requires considering a range of solutions and collecting more evidence.)

Then they ask how they – manager and employees – will know when the problem has been solved, and engage one more time in dialogue on the best indicator.

Finally, after agreement is reached on the most appropriate measure of success, the employees set out to implement the solution.

This is not simple. It does not say that one person knows everything. And it is not mere consensus building. It is engaged and committed knowledge creation. With some healthy "intellectual fighting".

How does this sit for you with Agile? Does this approach make sense with managers outside the team working with team members?

I will guess that it provides more respect to the team member than many actually get now. And also more engagement with a manager than many get now. At least that is what I have typically seen.

Do we need a coach? Do we need a coach now?

Here are some questions that come up again and again: Do we need a coach? Do we really need a ScrumMaster? How much time should a ScrumMaster give a team? How good do they need to be? Will we always need one?

I am a coach, so perhaps I am biased.

Still, bear with me as we look at a recent example, and see if we learn anything.

Earlier this week the Kansas Jayhawks won the NCAA Men's Basketball Tournament. What do we see?

• They have a coach, Bill Self. (We notice in fact that every team in the Tournament has a coach. Umm.)
• He makes a lot of money (I heard $1.2 million per year. Fact checker!?)
• Kansas is not firing Bill Self now that they have won. (And why not? Those kids clearly already know how to win.) In fact, they are going to pay him about $1 million more per year than this year (I think it will basically double his salary).
• Bill Self does not play basketball; no NCAA coach does. (Very rarely the NBA has had a playing coach.)
• The team of pigs is small; only 5 people play at one time. Plus some chickens. The total roster of Kansas was 17. Kansas played 8 people in the final game.
• The team plays about 2x per week for maybe 24 weeks.
• The team nets a fair amount of money for the school, especially if they go to NCAA's and do well. Consistently. I will guess in the $10-20 million range per year in total. (Can someone fact check this for Kansas?)
• The winningest teams tend to have the best coaches. (Or at least so people think.)
• The more successful coaches tend to be disproportionately successful (ie, success does not appear to be random or reliant on one lucky pituitary case.). Although a coach is by no means the whole picture. As one simple example: Since 1979 very seldom does the same University have back-to-back championships (exceptions: Florida & Duke).
• The coaches run the show at a given University; they recruit players, they hire assistants, etc, etc.
• The basketball coach is a full-time job, year-round.
• In fact, many teams (all?) have multiple assistant coaches (Duke has 3 famous assistant coaches, presumably very good in their own right).
• Basketball is a highly adaptive sport. The point guard is often called the floor general for the team. Plays are invented on the fly.

* * *

So, what do you infer about Agile and coaches from those comments? Or from other things you know about basketball coaches?

I infer that coaches are very valuable. In basketball. And in Agile. And probably more so in Agile than they are generally given credit for. (In Agile, we don't talk much about a continuum from ok to good to very good to great coaches. We should more.)

In my view, a ScrumMaster should be at least aspiring to be a coach. And probably on her way to being a coach.

How do I start an Agile project?

I have been teaching Agile courses for a while now.

One of the persistent questions is: "Enjoyed the course, but I want more help on actually doing an Agile (Scrum) project?"

In part this question arises from a wish to have a "cookbook". This cookbook notion is something most of the smart people (at least people I think are smart) want to avoid. Agile is there to make everyone think together; it is not there to stop you thinking and let you just follow the checklist in the cookbook.

In part this question arises from a wish to understand everything in two days. While Agile is simple in some ways, it really is far too complex to be fully understood in 2 days. In my opinion, there is still much I need to learn about Agile; much I can get better at. Even after years working at this.

OK it's an awkward question. Still, beginners need some help in starting. (Now, as you learn these dance steps, remember that you will never be a good dancer without feeling the music. In Agile, this means you must let the Agile principles become gut instinct. This will take a long time; keep listening to the music.)

So, what are the basic steps?

At one level, they are Deming's Plan-Do-Check-Act. In fact, at several levels. (See the Deming Cycle.)

But let's take it to the next lower level. This is what I tend to do...

1. Confirm that you have a meaningful effort to work on.

Many times, someone "says" we have a project, but often it is a bunch of nice, somewhat useful work. Don't accept that. You want work that is very valuable. You only have one life on this earth. Do something meaningful with it. And let the team have something truly meaningful to work on.

[Note: I assuming "you" are a manager responsible for a large set of work (eg, a project). But really "you" could be any team member. Or other people.]

2. Gather a team.

It is always good advice to get the best people you can. Recruit them. (Note: it helps to have a juicy piece of work.)

3. Assure that the team is on the same page, and agree on a definition of Done.

Important step. Many parts to it. Often forgotten or minimized. Agree that the definition of done will change later.

4. Prepare a Product Backlog of user stories (and other work).

Identify the stories, identify the Business value of each story, identify the story points on each story, identify other factors (risk, dependencies, etc.)...and then order the work. Do initial Release Planning (for now, I will say that means laying out the work into Sprints, and seeing when the first release will be).

This does not have to be perfect and complete; you will revise, add and improve as time goes on. As you understand the effort better.

5. Work on Iteration Zero.

Prepare the infrastructure that the team needs to do its work. (In some ways, this step could start earlier.) This work does not have to be completed before starting a real Sprint 1. And later Sprints might also include some infrastructure work.

Do I need to say that every Iteration is time-boxed? Yes, even Iteration Zero.

6. Start Daily Scrums (standups).

Start them in Iteration Zero.

7. Do Sprint Planning.

8. Do daily Sprint work and Daily Scrums.

Completing the stories. And this includes refactoring the Product Backlog and preparing Agile specifications for the stories in the next Sprint. And other things.

The ScrumMaster always has an updated Impediments List and is working on the top item. (In effect, this list started on day one.)

9. Do Sprint Review.

This always includes a demo of some sort. We want feedback. We want to learn faster how we were wrong.

10. Do Retrospective.

This meeting must identify actions. And some actions (with some impact) must be taken before the next Retrospective. The actions should be addressing one or two top items on the Impediments List.

11. Repeat steps 7-10 until effort is finished.

When you repeat, you must use Velocity to adjust how much work to bring into the Sprint. And the team must, almost immediately, be thinking of every way to increase their velocity. Every way but working more hours than, say 40 per week.

* * *

Those are the basic steps. There are a hundred questions about each step. The questions (and answers) vary depending on the situation. And usually there are some standard, expectable impediments that arise very early. So they in effect add more big steps in the beginning (or whenever they are discovered).

As with dance or sports, there are lots of variations on the steps, depending on the situation.

"Solve no problem before its time." A catchy way of saying, as you start, don't look for extra trouble. Work on only the most important impediment affecting team velocity. If you worry about every problem that is affecting, or did or will affect the team, you can become too discouraged. (The team can actually "work around" more problems than you probably think.)

More on this "getting started" topic later.

"Kids, careful trying this at home." Some say they actually did try this at "home" without help from an experienced person. With success. Usually, if they had much success, they actually did have lots of help from people experienced with Agile, although perhaps less help than other large firms got.

A metaphor. Kind of like NCAA Final Four basketball, it looks easy until you actually try to do it yourself. It's hard on the body, the head, the mind, the will. Still, if you want to, you can be a winner with Agile. Certainly lots better than where you are now.

The Nokia Test (3): Agile Specifications

The third line in the Nokia Test is: "The Iteration must start before the specification is complete."

What does this mean?

The first practical goal was to eliminate the analysis paralysis and delay associated with waiting until the specification was "complete". I don't know all the details at Nokia, but I have lived them at many other firms.

What is wrong with this old waterfall process? (at least in my opinion):

• too much delay
• a pretense that further change (or learning) won't happen
• a magical belief that the customer can really fully understand a spec (I have seen it happen maybe once)
• a magical belief that "all the questions are answered by the spec", when we know that people learn much better in a face-to-face Q&A format

As an aside, anyone who has made Waterfall succeed of course does not rely on the spec alone; we use agile-like conversations and other agile-like tricks to make the meaning clearer.

So, what are we advocating in Aglie (Scrum) to replace this broken process?

Well, it turns out to be a Goldilocks idea. We have some wish to make the team efficient and at the same time we know we are learning all the time. So, we advocate an Agile Spec. Not too much, not too little; just right.

What does this mean?

Well, at a minimum it means that the business person involved (in simple terms, the Product Owner) at least thinks he understands the story (let me assume the team is using User Stories). And at least thinks he can answer all the questions. It is also a good practice for the Business Analyst (or someone) to write down a page or two or more of notes. In the course of doing that, she (the Business Analyst in this example) will ask the PO several questions, and find out that he doesn't have the answers yet, and so new learning will happen.

But the Agile spec is very short. Maybe a bunch of diagrams. The good stuff is not buried in wads of paper.

Who decides what the Agile spec looks like for a given team? The consumers. Primarily the coders, the testers and other team members who must use it. Different projects and different teams (and even different situations) may require somewhat different Agile specs.

Let me be clear. The Nokia Test does not say "use an Agile Spec". I (and others) are recommending an Agile Spec as a best practice.

And Scrum does not say "use an Agile Spec". Scrum does say "improve your engineering practices" and I (and many others) would suggest that one improvement area would be around "requirements", and more specifically, one would be using Agile Specs.

Be aware that some in Agile would advocate no written spec at the beginning of the Sprint. Nothing written; just have conversation in the Sprint. This has worked, although I think it typically is not optimal (ie, the team usually could have done more if they had used an Agile Spec). While I agree with the importance of the conversation, face-to-face with Q&A, I also think the 1-5+ page Agile Spec per Story is also helpful. As long as there is discussion between the writer and the readers about what in it was useful or in the way, or just missing (and needed to be written down). (Answer to a question: Yes, all the Agile Specs developed so far could be in one document, if the team found that useful.)

I would suggest that about 5% of the team's total time in this iteration should be used to prepare for the next Sprint. This includes building and discussing (at a high level) the Agile specs for the next Sprint.

Remember that we are always learning. Just because something got put in an Agile spec does not mean it can't change (if we now know better). At the same time, an unprofessional attitude about learning ("oh, I'll just let myself learn about that later") is not allowed either. We are trying to learn as fast as we can. By putting all our minds together.

{Note: To find our previous posts on The Nokia Test, you might search on that term in the Blogger search box at the top of this page. We have 3 earlier posts.}

What's a ScrumMaster Worth?

You may have noticed that some people are feeling a recession out there. So money can be a bit tighter.

So, can you afford a good ScrumMaster?

The answer is obviously yes, and in fact they are even in greater need (since there is greater urgency).

Now, let's unwrap this from a financial viewpoint. We will use a simple example, and provide a simple spreadsheet. Hopefully you can take these ideas, use your own local numbers, and have a good conversation so the right thing happens.

A caveat: This post is not suggesting that the ScrumMaster is the end-all and be-all. We are asserting that the ScrumMaster can have a big influence on the productivity of a team. And that better ScrumMasters can have a lot more influence. And that the best ScrumMasters are rare.

* * *

Imagine a team of 8 that costs $1,000,000 per year. Including the Product Owner and ScrumMaster.

That team produces Business Value at some multiple of its cost. Let's take the case that that multiple is 7x. So the team produces $7,000,000 in BV per year. (One can think of BV being NPV (net present value) but it could be measured, originally at least, many other ways.)

Let's take the case that the team has an "ok" ScrumMaster, but the team is increasing velocity at only 10% per year. (Assume at the beginning of the year they are running at 150% of waterfall velocity.) Assume the "ok" ScrumMaster is making, all-in, $125K.

Now assume a "better" ScrumMaster who can double the productivity of the team in one year. (He does this by removing impediments or having them removed.) And assume that the better ScrumMaster (if he is available) costs $250K per year.

(NB. I hope you are noting that the numbers we are using are simple, round and convenient. You have to identify your own numbers. Nonetheless, I will call the numbers in this post, hopefully, inspirational.)

My, my, my. Very expensive dude, isn't he.

Should we invest in the better ScrumMaster?

Well, let's look at this some more. We assume that the Product Owner has or can discover new Product Backlog items so that the average BV of stories will not decline over the year. And let's assume the better ScrumMaster does not improve productivity by helping her (the Product Owner) discover more business value. Let's further assume the better SM improves (enables the team to improve) velocity roughly equally over the year. So that, over the next year the team will produce $10.5 million in business value (rather than $14 million, if the jump were to happen immediately).

I have also assumed the situation (the team, the managers, the company, etc) will allow the better SM to help enable the team to reach a 2x level.

(N.B. The conversation is about value in relation to cost. It is not, and never was, purely a cost consideration.)

So, for an added investment of $125K, the firm will get an extra $3.15 million. Is this a good business decision?

Well, we don't quite know yet.

Let's assume the better SM finds impediments that cost $1 million to fix (training, SW, HW, etc), so that, in simple terms, the firm must invest a total of $1.125 million total to get $3.15 million.

What do you think? Is this a good business decision in a recession?

One could discuss my assumptions endlessly. Discuss a little if you must; then do an experiment where you are. We are all interested in your results.

(To update this algorithm with your own assumptions, download the XLS file here. And revise it.)

N.B. Scrum was built to help teams get 5x to 10x productivity gains. I think a 2x gain in one year is conservative (low, easily reached in a normal situation). So, there is more juice in the orange. There is also the possibility that you have a "dead core" and further productivity improvements are not possible. More on this in later posts.
N.B. A key principle of Agile is sustainable pace. So in Scrum, the gains are not made by driving the team through a "death march". Unfortunately, this still has to be said for some people.

Suggested Reading - For 2 CSM courses last week

Here are some of the resources we mentioned in the courses.

Caution: "Words, words, mere words, no matter from the heart." W. Shakespeare. Ground your learning in the heart, and in the fire of experience.

The New New Product Development Game by Takeuchi and Nonaka. Let me ask you to go to www.hbr.com and look it up. It's a Harvard Business Review article. It costs $6 (softcopy). If you need to see it before you buy it, contact me.

The Knowledge-Creating Company: How Japanese Companies Create the Dynamics of Innovation by Takeuchi and Nonaka. This is the stepping-stone to their discussion of "Ba".

The Concept of "Ba" by Nonaka and Konno. This article gives an introduction to this subject. "Ba" is the place or context where great teams perform.

Extreme Programming Explained: Embrace Change (2nd Edition) (The XP Series) by Kent Beck and Cynthia Andres. This may be the best written book on Agile. Certainly XP has a lot to add to the game.

Extreme Programming in Practice by Newkirk and Martin.

Working Effectively with Legacy Code by Michael Feathers. Great book if you have to work with legacy code. And who doesn't.

Ssh! We're Adding a Process by Mark Striebeck at Google. Story of how Ad Words (arguably the highest business value piece of software ever written) adopted Agile/Scrum.

Agile Retrospectives: Making Good Teams Great by Esther Derby and Diana Larsen. Retrospectives will normally be extremely valuable if you follow their advice. (If you just talk, and take no action, retrospectives could be a waste of time almost.)

Fearless Change: Patterns for Introducing New Ideas by Mary Lynn Manns and Linda Rising. One could argue that, since Agile is still new, we need these tools to influence others to adopt Agile. I think a better argument is that we need these tools to influence others because we are always learning what Agile really is. Extremely useful book, whether you are a team member, a Product Owner, a ScrumMaster or a manager.

Rolling out Agile in a Large Enterprise by Gabrielle Benefield. This is about Yahoo. Many good suggestions.

Software by Numbers: Low-Risk, High-Return Development by Mark Denne and Jane Cleland-Huang. This book explains what you should go to Minimum Marketable Feature sets to get incremental funding. Or...it pays to go Agile.

The Mythical Man-Month: Essays on Software Engineering, Anniversary Edition (2nd Edition) by Frederick P. Brooks. It includes the famous essay on No Silver Bullet.

User Stories Applied: For Agile Software Development (The Addison-Wesley Signature Series) by Mike Cohn. Key stuff.

Agile Estimating and Planning (Robert C. Martin Series) by Mike Cohn. Again, key stuff.

* * *

There are many other great resources. This is a start. You may also want to look at earlier posts of this sort. Start here.