Yearly Archives: 2008

What to do first?

Posted on by

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

 Subscribe in a reader

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

Posted on by
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.

 Subscribe in a reader

Agile Portfolio Management – 2

Posted on by
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…

 Subscribe in a reader

Agile Portfolio Management – 1

Posted on by
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.

 Subscribe in a reader

Reading List CSM Sutherland/Little course

Posted on by
We recently led a course in Atlanta.

Suggested reading included the following:

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.

 Subscribe in a reader

Scrum Certification Test

Posted on by

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.

 Subscribe in a reader

Small teams

Posted on by

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.

 Subscribe in a reader

All business is personal

Posted on by
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.

 Subscribe in a reader

A personal note

Posted on by
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.

 Subscribe in a reader