Agile & Business

What is Scrum?

noreply@blogger.com (Joe Little) — Fri, 17 Jul 2009 14:53:00 +0000

I am excited to be giving a Certified ScrumMaster course with Jeff Sutherland next week. In Richmond.

So, I was thinking: what is the essence of Scrum if you would play the game well?

(Remember that Scrum is named for the Scrum formation in Rugby. We often show a video of the famous All Blacks team doing the Haka and playing Scrum. We think Takeuchi and Nonaka, who originated this metaphor, were thinking of these great teams.)

To me the essence is that team spirit that is willing to face a rough opponent and a difficult situation, and overcome any obstacle to win.

I sometimes call this the Michael Phelps attitude. He is thinking: "I broke world record in each of the last three heats. And now, in the finals, I want to jump in the water and break it again."

There are many things from art and science that we give the teams in the course. But we must convey this essence. Without this tacit knowledge, it avails almost nothing to have all the explicit knowledge in the world.

Value of Training (CSPO)

noreply@blogger.com (Joe Little) — Sat, 11 Jul 2009 14:00:00 +0000

What's Scrum training worth?

I am about to lead a Certified Scrum Product Owner course. (2 days, in NYC and a bit later in Saratoga Springs.) The question comes up...what is this course worth?

I explain this in more detail in the course, but here's the summary.

In the course we talk about many things, and hope to get many improvements. Imagine, though, that we only make 2 improvements to a Product Owner. And that PO manages only one Team.

Assume the Team costs about $1 million all-in per year. Team of about 8 people.

Assume the Team currently produces about $3 million per year in NPV (net present value, a core way of measuring business value). (Microsoft seems to be averaging about a 5:1 ratio or better overall.)

OK. We teach Sam, the PO, how to create 20% better stories. So, instead of $3 million per year, the team can get $3.6 million per year.

Now, we also teach him the Pareto Rule, and how to work it all the time. (80% of the value comes from 20% of the work.) Now, we and Sam aren't perfect, so Sam comes back only able to execute the 85-33 rules, ie, 85% of the value in close to double the 20% of the time that Pareto's rule calls for.

OK, this means in 33% of a year, the Team can get 85% of $3.6 million. Let's round down and call that $3 million. We assume Sam (and the firm) can find more work of the same value. So, in the next 33% of a year, the Team produces another $3 million in BV. And in the last third of that year, the Team produces another $3 million in BV. So, now we have $9 million in BV in one year. A 3x improvement. (I will note we assume that the Team did *not* increase Story Point velocity at all. No other impediments removed...very conservative assumption.)

Even if we (the teacher and Sam) don't immediately achieve quite the same level of improvement we assumed (which itself was far from perfection), I think you can see that, a million here, a million there, pretty soon you're talking real money. And, in my opinion, those improvements alone justify the costs for the 2-day course. Even in a serious recession.

What do you think?

Defining Business Value // #1 Risk

noreply@blogger.com (Joe Little) — Mon, 06 Jul 2009 16:34:00 +0000

I hear many people complain that it is hard to define business value. So they won't do it. Or they won't try any harder to do it.

That it is hard and always changing is true. That fact does not, though, give us sufficient reason not to work hard to get better.

I won't reiterate here all the reasons why understanding business value really well is very, very important. Suffice to say that one can argue that there is no more important thing to understand. (Yes, one still has to actually build the new product.)

One comment I hear is "I can't define what risk is worth." So, today, let's take risk as an example.

My main reply is "well, get an actuary...those people define the dollar value of risk all the time. It is called an insurance premium."

Then the response often is: "There is the business loss from an 'event', and there is the harder to quantity 'loss of reputation'."

This is correct, as far as it goes. "Loss of reputation" can often be harder to quantify. But nonetheless, you must take a stab at it. And prove to yourself whether your theory of what it is worth was high or low. Only by taking a stab at it, do you force yourself to learn.

Wide-band delphi. I cannot too strongly recommend this technique. As the Romans said, to predict is difficult, particularly of the future. So, we want to get the best ideas possible on the table so that we improve our odds. By improving our odds, we improve the likelihood of overall business success.

So, risk, as one example. Let's say risk (in several forms) is the main driver of the business value of a large effort. Here is one way to estimate it. Based on assumptions I will not articulate here.

Get Fibonacci cards that go to 987 (several orders of magnitude). The 5 "experts" (the best experts you have) go through the Product Backlog, and use the basic planning poker technique, but this time they are estimating the Business Value of each story. (I assume the reader understands basic planning poker.) For each story, the experts question and discuss the underlying assumptions about Business Value. They take an aggressive attitude that they are tryingto uncover Pareto's 80-20 rule within this population of story cards. The BV is relative to the smallest reference story (marked with a BV=1). Ideally, a small set of reference stories. The experts reach a reasonably close consensus (within 3 Fibonacci numbers of each other), and then average to score each card. By and by they complete all the story cards.

But to make a lot of business decisions, you need to know the dollar value of the "whole" effort. (Discussing "whole" is a rabbit hole we won't jump in just now.) So, having had a good discussion of the stories, we ask the same experts: "Ok, write down in secret what you think this whole pile of cards is worth. In dollars. If you need to do a calculation, do it. If you can't think about it any other way, what is the maximum our business should consider to pay for this stuff? How long for you to estimate this? And any questions now for the Product Owner, before you start?"

They might ask the Product Owner about some assumptions. "How many people will this affect? What is the average size of an account? How many accounts do we project we will have in 3 yeras? What's the largest fine the Federal Reserve has ever given?" Whatever they think is relevant.

Regarding the timebox, anything more than 1 hour is too long, almost always. (If the calculation is really important, and will take longer, then maybe.)

Each of the 5 experts writes down his dollar number on a piece of paper, in secret.

Now the fun. You bring all five experts back together, and have them turn over the pieces of paper. They won't be the same. As with planning poker, you have the 2 extremes talk. Then they all discuss what the best assumptions should be. Like a Scrum. But in some sort of timebox. Typically there is a good "fight". This is good. Also, typically, they each need to go back and re-estimate. You might do a couple of rounds of this.

You want a reasonable consensus, but not perfect. I will recommend that the least degree of consensus is within one order of magnitude (eg, $11-99 million). Ideally a good deal more than that. Normally, once within some reasonable consensus, then average the numbers they give you.

Example: 3, 4, 7, 8, 9. The average is $6 million or $6.2 million. (I would not pretend we have more precision by extending the number of decimal places.)

Sometimes it is good to go to the next higher level of management and discuss how the $6 million BV estimate was arrived at. And ask them: do you think this is a reasonable estimate? If not, how would it be improved?

Is the number derived perfectly accurate? Of course not. There is no end to improving our BV estimates.

Is the number better than we currently have? Almost always.
Is the number useful enough to make business decisions with? Yes.
Is the number good enough for us to start learning from? Yes.
Should we revise the number later? Certainly. The key question is how many times.
Should we try to do an experiment in the real world that tries to prove that the estimate was (or was not) reasonably accurate? Yes.

***
Note: The diagram about risk management is borrowed from techrepublic.com. The point, for me, of the picture, is only that it is about risk management. I am making no point now about whether the ideas embedded in the picture are good or bad. Still, the fear of risk often leads people to take no action ("deer in the headlights"). This is often the worst of several options.

Freedom

noreply@blogger.com (Joe Little) — Sat, 04 Jul 2009 17:36:00 +0000

Man is born free, and everywhere is in chain.

Rousseau, certainly a man of some well-known weaknesses, was brilliant to say this, just a few years ago now.

Of course it was then far from literally correct. And he said this as a citizen of Geneva, arguably one of the places on this planet with the most freedom in that day (~1762). Still, it was more true than literal physicality, both then and to this day.

Today, July 4th, it is most appropriate for any Virginian, and indeed any citizen of the world, to honor the Declaration of Independence and a certain birth of freedom in this nation. This is arguably the one document that has given people more freedom than any other single act of mankind. And, of course, not just people in the USA.

We know several phrases well.

When in the course of human events...
...
We hold these truths to be self-evident, that all men are created equal, that they are endowed by their Creator with certain unalienable Rights, that among these are Life, Liberty and the pursuit of Happiness.
...
...appealing to the Supreme Judge of the world for the rectitude of our intentions,
...
with a firm reliance on the protection of divine Providence, we mutually pledge to each other our Lives, our Fortunes and our sacred Honor.

We too must continue to fight for freedom. We may fight for it using Scrum or Agile or Lean, and certainly this is an important fight. But we cannot say that the courage these daily fights require of us can measure against the courage of a red-haired man in Philadephia in 1776. He and John Hancock and their fellows knew, for a certainty, that if they did not win the war, they would be killed, probably hung in public.

Let us learn again from this. Let us rededicate ourselves to the fight, that freedom, which can so easily in the search for security in a difficult world roll backward, will with our arms, and backs, and voices, continue to roll forward.

New, special Classes - I'm excited

noreply@blogger.com (Joe Little) — Fri, 03 Jul 2009 16:09:00 +0000

I am particularly excited about the following courses or workshops.

One: Jeff Sutherland in Richmond, VA. Certified ScrumMaster (CSM) course. Dr. Sutherland (he has a PhD) is a great guy and of course the co-creator of Scrum. I always learn more when I do these courses with him. This a great advanced course for many people. Great for managers, too.

If you do not follow Dr. Sutherland's blog, you should.

Two: Poppendiecks in Chicago. New Leading Lean Software Development workshop. Mary & Tom Poppendieck are of course the thought-leaders in Lean Software Development. Again, I always learn when I help with their courses. This course is new, and will be based on their new book (coming out soon).

For an outline of their new book, see here.

Three: CSM for ScrumU at Notre Dame. ScrumU is a group of people who do SW dev (etc) for the universities...using Scrum (and other Lean-Agile stuff). This is a special course only for those kinds of people, at a "university" rate. And it is for professors who teach IT subjects. Kristine Gianelli, leader of ScrumU, is the mastermind behind this course.

Metrics & Velocity

noreply@blogger.com (Joe Little) — Sat, 27 Jun 2009 12:37:00 +0000

I have received a few comments, both recently and in the past, that tell me some people are uncomfortable measuring velocity. And they are uncomfortable measuring the Team.

They are usually not that clear why they are uncomfortable.

Let me state my position, which I believe is also close to the position of Jeff Sutherland and Ken Schwaber.

First, as a memory device, I say: "Velocity: Don't leave home without it."

Second, any decent Team wants to know if they are really successful.

Third, the Team must measure velocity and it must aggressively be trying to improve it. Doubling velocity in the first 6 months should be a goal. In Scrum, the larger goal is to get the Team to be 5x - 10x more productive than the average Team. (Good data tell us that the average is about 2 Function Points per man-month.) Scrum does not guarantee that every team will get to 5x-10x. But none will if they don't go for it.

Improving velocity means removing the top impediment, one at a time. It does NOT mean working harder. In fact, often one of the top impediments is that we are already working too many hours per week. (To some, this will seem a paradox. Explanation another time.)

How do we use velocity? Many ways, but I will emphasize three. (1) In planning, to plan the release, for example. (2) To push back with a pattern of numbers when magical-thinking managers ask the Team to double their velocity in one Sprint. (3) To challenge ourselves, as a Team, to get impediments removed so we can enjoy some real success around here. (And often we have to ask managers and even senor management to get involved with the impediment removal.)

What are the push-backs that I hear?

Several. This post is getting long enough that I won't state them all hear.

But the cartoon represents one of the major ones, I think. People are concerned that we are putting human lives in the hands of some stupid bean counter (as we say in the South "bless his little heart"). Certainly not a happy thought.

So, a few assertions about metrics (not time here to discuss them):
* the Team does the metrics themselves, honestly because they want to use the numbers
* there should be no "managing from behind the desk" (as Lean would say)
* velocity does not reflect one single factor, but the result of all factors
* when the Team evaluates velocity, they use human judgment (Ex: "the velocity dip last Sprint was mainly due to Vikas being out sick 4 days; he's fine now")
* people want to see clearly and show that they are successful
* velocity is not supposed to be a tool for Dilbert managers to beat up the Team with
* while every metric will eventually be gamed (eg, due to Dilbert managers), these issues are part of the larger imperative of honesty and transparency in Scrum. Occasional gaming is not a reason to never do any metrics
* Velocity is not the only important metric

Fun & Success - Learn Scrum - Durham and Montreal

noreply@blogger.com (Joe Little) — Thu, 25 Jun 2009 14:33:00 +0000

Fun & Success? In the same sentence?

"You are doing Scrum right if and only if you are having fun. Serious fun."

"You are doing Scrum right if and only if you are having clear success."

How can these both be true? Pushing through success is so stressful. Fun is light-hearted, like laughter.

Well, this is one of the paradoxes of Agile that we explore in the Certified ScrumMaster course. It is only a 2-day course; it is doubtful one could be a true "master" of anything in 2 days. But we do promise you will learn a lot (more than you can possibly take on-board) in 2 days. (Ok, 3 days if you include the Team Start-up workshop.)

Oh, about the Dilbert cartoon. Seriously, we recommend that you have at least some training before starting Agile. The whole team, in fact, is what we recommend (sounds self-serving, I know, but that is the best recommendation). On the fun side, we love to hate Dilbert managers as much as the next guy, but some of them managers actually drink beer and eat pizza like normal people. Who knew they could actually help remove impediments? And lead us toward a more fun life with more success.

For almost everyone, Scrum is a serious paradigm shift. Get ready. (Koan: If you think you have made the shift, you haven't.)

And get ready to have some fun. (Yes, even the course is mostly fun, with, for example, a bunch of exercises and a PG-rated Richard Pryor joke. We leave no stone unturned to help you flip those bits in your wetware. Wetware is the hardest thing to refactor.)

For Durham (Jun 30 - Jul 2), see here and here.

For Montreal (July 8-9), see here.

We have other courses on the same site.

Completing a Release

noreply@blogger.com (Joe Little) — Wed, 24 Jun 2009 14:04:00 +0000

OK, so we have a known velocity in Story Points. And, having that, it is an exercise for a 6 year old to figure out how many more sprints until the release.

Example: We have a velocity of 20 and the stories in the backlog for this release have a total of 100 story points, so QED, we have 5 sprints remaining until we can release.

[QED is from my old school days, meaning "which was to be proved".]

Fine, for a shark, a simple project manager or a 6 year old.

What's the problem, you say?

In real life, we need to be cleverer than a shark.

It takes a clever, determined Product Owner (in Scrum terms) to land the release.

We know from long experience that the Product Backlog will (or should) change. New features will be discovered, the customer will "know it when he sees it" (a law of software "requirements"). And "stuff will happen" such that the current known velocity will change.

Most importantly, the PO (Product Owner) will be executing the Pareto Rule, which says that 80% of the value comes from 20% of the stories (maybe better to say 20% of the story points). Maybe not a perfect 80-20 rules, but all those stories slated for the release are NOT required.

Side note: What can happen to velocity? First, it should improve as we remove impediments. Second, "stuff happens" and the foreseeable problems (which we refused to foresee) happen. And the completely unexpectable happens with known regularity (and perhaps some unknown frequency as well).

Let me emphasize again: The PO should dynamically be looking at the product as it grows to determine the Minimum Marketable Feature Set (MMFS) to release. This is a very dynamic process of discovery. Or should be. When you are creating something for the first time, there is always plenty to learn. (Or, if you waited for the "perfection" of the so-called requirements, you probably waited way too long.)

For a given product, we hope there will never come a day when we are finished improving it. When all the stories are done. We are always discovering what they want most NOW. Customers always want more (although the "more" that they want is often less...example: less complexity).

Breaking the world record

noreply@blogger.com (Joe Little) — Mon, 22 Jun 2009 13:19:00 +0000

My younger daughter has her last swim meet of the season tonight. I am excited (and still a bit affected by Father's Day yesterday).

When I talk about Agile & Scrum & Lean, I often refer to Michael Phelps' attitude. Not his attitude in SC, whatever you may think of that. (Not that I begrudge him some relaxation.) But his attitude about swimming. He broke the world record before the Olympics, he broke it in the first heat, again in the second heat, and he intends to break it again in the finals. He is relentless.

We ordinary humans must take the same attitude.

Just about now, your colleagues would be encouraged by seeing you break your own best record.

Just about now, the other teams would be encouraged by seeing your team break its own best record.

So, what do we mean practically?

Well, first, we mean sustainable pace. We mean that we will break records in our new product development work, not by working harder, but by working more creatively. By creating knowledge -- faster, better, with more certainty, and more power.

Second, we will admit that half of what we know is wrong. (Cf Taiichi Ohno in "Workplace Management".)

Third, we will double the team's velocity. In 6 months or less.

Doubling velocity (story points done-done in each sprint) usually means we must improve several things:
* a clearer definition of done (or "done, done" if you prefer). Usually we let this be too vague. Vary it must for some stories, but for most SW dev stories it must be very clear and can be consistent. And in my opinion, it must mean "no [known] bugs escape the Sprint". And testing must include at least functional testing.
* we must measure velocity. I still can't believe how many teams I find that don't have some measure of velocity. More on this next time. For now: "Velocity: don't leave home without it."
* we must prioritize the impediments, and keep removing or reducing the top one until velocity is doubled. Hint: We might want to prioritize the impediments by how much the removal/reduction will increase velocity. 25% here, 30% there; pretty soon you're talking a real increase in velocity.

Hint: Improving quality and reducing technical debt are almost always important keys to seriously increased velocity. Not the only keys, but very important.

Who is gonna feel better when the Team doubles velocity (with sustainable pace)? Yes, the Team, perhaps first and most importantly. And customers. And managers. And the widows and orphans who own the company.

Is velocity the only metric in town? Ok, good question, but for another day. Increase velocity now. Show yourself you can do that professionally. Then we talk.

"But, things are so good around here, we can't possibly double velocity." Ummm. My first thought is that your biggest impediment is that people are hiding from the truth. Every place I look, we are using such a small percentage of the potential of people, that doubling the velocity is a task any team can accomplish. Look again, and take Michael Phelps' attitude.

If you really think you can't get any better, declare yourselves the best team in the world, write-up your success, and challenge other teams, anywhere, to beat you. You might just learn a thing or two. And have some serious fun.

What is Business Value Engineering?

noreply@blogger.com (Joe Little) — Thu, 11 Jun 2009 14:50:00 +0000

I made a post in AgileBusiness (yahoo group). That I thought I would repeat here:

QUOTE
I have been asked to start a conversation about BV Engineering. So, here's a
start...

What is it?

It is a framework for looking at the delivery of business value. It is called BV Engineering for two reasons. First, instead of hand-waving, we believe that BV Engineering should include qantitative measures (although not be dominated by metrics), and, second, it is called that so that it is approached like other engineering practices in Scrum, as something that is not prescribed, except to say one must always have them, identify them, and improve them. And BV Engineering becomes one of those engineering practices.

Where do we start?

We start with a grossly simplistic franework that says: we have
* a box of customers (external and internal typically),
* a box of Business (customer facing people, internal groups like legal and compliance, and perhaps others), and
* a Team (eg, the Scrum team that will produce or improve one product for those customers).

We also start with an assumption that BV Engineering is a round-trip set of experiments that are continuously trying to prove whether our hypotheses related to BV Engineering are useful. Or, more accurately, it is a feedback loop that continuously shows us how far off our hypotheses are. (And since stuff is happening all the time, we are always at least somewhat off.)

And what do we do next?

Next, based on that simple framework, one does a simple drawing, as with Value Stream Mapping, and describes what BV Engineering is in your specific context.

The flow between all the people is diagrammed. The assumptions and hypotheses are described. The business value model is described. We lay out the current state.

Why?

So that, being visible, we can all see it, and make suggestions, little tests, for improving it. Constantly. That is, so we can continuously move toward a future state.

So, what kinds of things are you including?

Well, anything that helps or hinders us from delivering stellar business value to our customers instantly, at a lower price, solving exactly their problem (or fulfilling their need) with no adverse side-effects. And fulfills all our constraints (eg, a good return to capital, etc, etc).

The approach also works if you make the simplifying assumption that "we only want to make money". As Drucker would say, not the correct basis for doing business, but one that some adhere to.

Back to the things. These things include, or might include: communication (who, what, how, when, etc), gathering requirements, the BV model and its assumptions, frequency of release, feedback from the release, how much we do the telephone game, who needs to understand the customer, the role of tacit and explicit knowledge (about what?), how and where we do knowledge creation, how we balance customer needs with legal/regulatory needs, how we do portfolio management, how we start and kill efforts, the Kano model, prioritizing across multiple customers (or customer sets), priority poker, value stream mapping, personas, use cases, etc, etc, etc.

For example, the use of any one of these things has one or more assumptions tied to it. One hypothesis is that these assumptions have often never been articulated, much less challenged, and even less have they been confirmed as accurate for our specific situation.

Two more observations, each fundamental. As soon as one sees this as a feedback loop (or PDCA cycle) that is trying to prove whether our theories and practices are on target, one immediately asks about the frequency of feedback. And almost always it is not fast enough (GM anyone?). And, second, one then looks at this not as a static model, but as a dynamic model that is always adapting to change. So, one asks "how are we building into our BV Engineering appropriate mechanisms for it to be continuously adjusting in a useful way?"

Lastly, let me add a "personal bias" (which I find empirically true), namely:
virtually every team member needs to understand how we do BV Engineering in our specific situation, and where they fit in on the process.

Well, that's a start.
Comments or questions?
UNQUOTE

Your comments, here or on AgileBusiness, would be welcome.

Poppendiecks: Designing a Lean Development Process

noreply@blogger.com (Joe Little) — Sun, 31 May 2009 20:22:00 +0000

The Poppendiecks have a new advanced course (all welcome, but people already experienced in Lean-Agile will get more from it).

Designing a Lean Development Process.
Mnpls, June 9-10

Based on their new book (about to be released).
More info: See here.

AgileBusiness - new yahoo group

noreply@blogger.com (Joe Little) — Sun, 17 May 2009 01:51:00 +0000

Quick notice that we just started a Yahoo group called Agile Business.
See here.

Key words might include: Agile, Business, Business Value, Agile Project Management, Product Owner, business analyst, Lean, Product Management, Marketing, Executive, Manager, Agile for non-SW projects, etc, etc.

Come and share your questions and your comments.

How do we know we have a good idea?

noreply@blogger.com (Joe Little) — Tue, 05 May 2009 14:58:00 +0000

I was reading the new book by Bas Vodde and Craig Larman recently. Recommended.

In the beginning of the book, they give lots of ideas about "how to think". At first, I found this curious, although the suggestions were very good.

Only today did I connect it to what I think is our biggest problem.

This is how Yogi Berra (and Nancy V) put it:
"In theory there is no difference between theory and practice. In practice, there is?"

Or -- how do we know any idea is really any good?

We could assume, but as we know, that can have bad consequences.

In other words. In my mind, my ideas (and your's and your's) are always perfect. But only in reality do we find out they are always less than perfect.

So, how do we discover the stupidness in every idea? More quickly.

So, this applies each Sprint.
And this applies in changing from waterfall to Scrum. (Yes, Virginia, even Scrum will be a little rough around the edges when applied in real life.)

So, Vodde and Larman, at a high level, are helping you discover all the stupid "truths" you currently think are right. And helping give you a means to gently convince others that their strongly held truths are just plain wrong.

A respected colleagues says: Assume half of what you "know" is wrong. Seems good advice.

I think: There will never come a day when we are finished rooting out stupidity. In ourselves (so be a bit compassionate), in any one person, and certainly in the whole team and the larger firm culture. Toyota has gone further: they are rooting out stupidity in the flow of value from one firm to another.

Taiichi Ohno started implementing Lean at Toyota in the 1940's. He was not finished when he retired in the 1980's. I am thinking with Agile, while we can be a bit impatient, we also need to take a longer view. But maybe I'm wrong.

Yahoo Groups - 4 easy lessons

noreply@blogger.com (Joe Little) — Mon, 04 May 2009 21:25:00 +0000

Apologies to those used to Yahoo groups. This is for beginners.

First, why should you care? Because lots of really smart people use Yahoo groups (and ScrumDev in particular).

Second, why should you worry? Because lots of people hear stupid things or get into flame wars on Yahoo groups (and similar). You must Think For Yourself.

1. How to get there.

Go to http://groups.yahoo.com/
In the search box, type in Scrum (one example)
Click on Scrum Development

2. How to join

At the home page, click on Join This Group!
You will be asked to Sign In or Sign Up (become a "member" of Yahoo...it's free)

3. How to read

From the home page, click on Messages (upper left)
In your Edit Membership (or when you join a group), you can say if you want single or daily emails when posts happen. I like Daily.

4. How to Post

One way: Under Messages, click on Post. That gives you a window to make a post.
Or you can send an email.
Or you can reply to someone's post.

OK. Now change the mindstream.

Introverts and Individualists and Collocation

noreply@blogger.com (Joe Little) — Wed, 29 Apr 2009 15:21:00 +0000

I am seeing a general trend (in several small things I am seeing lately) ...where the logic of what people are saying is (at the extreme): we should bend over backwards because implementors are introverts. (Yes, way over-simplifying a complex issue, but bear with me.)

OK, we must say that a good team always has (at least somewhat) talented individuals. Mastering the machine is probably a skill set and an interest more common among introverts than extroverts.

But we also know that people who are very good (maybe even the most talented on the team) can ruin the productivity of a team by being too much an individual. We see this in sports (Tyrrell Owens maybe), in life and even in our work.

OK, fine.

Let's unpeel this a bit further.

We have lots of geeky guys (yes, usually guys) on SW teams who prefer to "talk" to real people via technology. Almost exclusively.

And we have lots of managers who feel that distributed, or even disbursed, teams are best. (Disbursed is every person in a different location. Distributed, ideally, is a team composed of two pods, each pod composed of collocated individuals.)

And it is true that there are some disadvantages to collocation. People chit-chat too much (actually useful up to a point), you get more "people issues" (or so it seems), more interruptions (controllable if people want to), etc. (Yes, I am not very impressed by these disadvantages.)

Note that, in a face-to-face team it is much easier to see people-issue impediments. When not F-T-F, it is easy *not* to see people-issue impediments. If there is a will to fix impediments, it is better to see them.

Now, I am fine to accept and work with a distributed team.

And, I still think there is a strong argument for more collocation and more face-to-face conversation.

Yes, we have to accept that each person is different. And make some accommodations to that. It is silly to try to make introverts into extroverts (or vice versa).

But that does not mean that everyone should stay in their comfort zone all the time.

To some degree, for the good of the team, we need to ask the introverts to "step out of the cube, dave" some too. (I hope that phrasing injects a tad of 2001 humor. If you know that movie.) And we need to ask the extroverts "could you shut up a moment, please."

In a broader sense, there should always be a tension between individualism and "the team". We contribute everything that we are, as individuals. We do...so that the team can have a greater success as a team than any one of us alone. Or so it is when we play team sports, like new product development.

I say this as a bit of an introvert myself (per Myers-Briggs).

One more thing...

Why do we seem to think that a distributed team is so obviously best for our situation?
(Some introverts like distributed teams because of lower interaction with those pesky people. Not normally an argument I find compelling.)

I am distressed when I see firms "assume" a distributed team or partly offshore team, without any analysis of whether it beats a good alternative (eg, a collocated team). Each time it must be analyzed, in my opinion.

Quite often (most of the time?), if you get a diverse group of 4-7 people in one location, given a bit of time, they should be able to beat the pants off a distributed team. Even a distributed team with better skills or knowledge at the beginning. (Certainly this is *not* true at the extreme: low quality individuals collocated vs very high quality individuals distributed. But that's an extreme comparison I seldom see out in the wild.)

So, I am assuming you can often get 4-7 people with good skills/knowledge in your product domain areas. That could be collocated at relatively low cost. I posit that usually the special knowledge or skills or lower cost that distributed people bring, at first, is less important than the knowledge creation, and skill creation and team "emergence", that a collocated team can create.

Remember three things:
* knowledge is useless unless it can be turned into effective action (in the context of a team)
* knowledge decays rapidly
* the best way to convert tacit knowledge into explicit knowledge (or into tacit knowledge in another person on the team) is to work together, collocated

Reactions?

PS. Some reminders:
* I have worked, and still like to work, with distributed teams
* To me, it has been proved that distributed teams can be hyperproductive (if done right)
* Scrum works fine with distributed teams
Nothing I said earlier contradicts these statements.

CSM Course, Durham, May 6-7. And May 8th

noreply@blogger.com (Joe Little) — Sun, 26 Apr 2009 20:04:00 +0000

We are looking forward to a good class in Durham, NC. Certified ScrumMaster Class.

We hope that people will get enough out of it to double their velocity. (We know there is enough there to do that, but there are several other issues.) The course will address BV Engineering, Agile Estimating & Planning, and other issues.

On the third day (sign-up separately), we will have a Team Start-up session. All are welcome at this May 8th session. This day will get more practical about the issues in starting up a team. All the different kinds of issues.

See LeanAgileTraining.com or contact Julia.Hill@leanagiletraining.com.

Shock Therapy

noreply@blogger.com (Joe Little) — Sun, 12 Apr 2009 16:22:00 +0000

Back in September, Jeff Sutherland spoke at the Googleplex in NYC.

Topic: Shock Therapy. Also called: "Self-Organization: The secret sauce for improving your Scrum team".

About 90 minutes.

Here: http://www.youtube.com/watch?v=M1q6b9JI2Wc

Recommended.

Summary: Shock Therapy is a technique for a special and experienced coach to work with a Team to help the team boot up so that they can self-organize to a better life and hyperproductivity. Like many things in Scrum, it sounds paradoxical, but is not in practice.

Business Value Engineering - 3 questions

noreply@blogger.com (Joe Little) — Wed, 18 Mar 2009 03:18:00 +0000

I want to slightly change my definition of BV Engineering (see earlier post).

It is the values, principles and practices that we use to help us continuously improve the Business Value we deliver.

Some questions and answers:

Q. "Business Value". Ok. Always good. Why add the word "engineering"?

A. Scrum says you must always improve your engineering practices. I think the most important set of engineering practices (typically) are around BV (business value).

Also, engineering implies that metrics and rigor are involved. This is important as an attitude. I see too much hand waving and vague ideas.

Q. What is the relationship of BV Engineering to Scrum?

A. Umm. To me BV Engineering is best done in the context of Scrum, but Scrum is not required.
And, you would think that Lean and Scrum implied or would foster a whole set of approaches to BV in software development, but in practice, this does not seem to be the case.

To me, it is fundamental that a Team is producing the Business Value (whether using Scrum or some other approach).

Q. What is the first thing to do in BV Engineering?

A. In my opinion, the first thing to do is "draw a clear picture" of what BV Engineering means for your team (area) currently. This typically makes more concrete and specific three shapes: the box of Customers (external and internal), the box of Business (the customer facing groups and the internal groups that, for example, have some input about features), and the circle of the team. Then diagram how the BV practices actually work together as you flow between and through these shapes. And then describe the values and principles, theories, models, and assumptions behind the BV practices.

One makes this specific to your situation. Not in infinite detail, but with some flesh on the bones.

The purpose of this simplistic "picture" of your BV Engineering is to enable the Team and the right people to identify where the biggest improvements can be made.

More later.

How honest should you be in Scrum?

noreply@blogger.com (Joe Little) — Tue, 17 Mar 2009 12:33:00 +0000

First answer: Completely.

Ah, if only the answer were that simple. Sorry, George, but Scrum and Agile provide no cookbook answer to this question.

Some people use "honesty" to mean they get a right to be brutal to others (and also to ignore their own imperfections).

Much more often, the de facto thinking is "honesty means I won't say anything obviously incorrect and I will speak up more than I did before." (Well, I don't want to hurt anyone's feelings. And I didn't say much before anyway.)

So, for most people, the operational answer is: Be a LOT more honest than you were before. Both with good news and with bad. And even about yourself.

It turns out that once there is trust on the team, this is not so hard.

Still, like most things: Easy for me to talk about here. Always challenging for a team to do at the highest level in the real world.

Identify your multiple! WHAT?!?!

noreply@blogger.com (Joe Little) — Fri, 13 Mar 2009 03:28:00 +0000

Let's discuss the last post, from the skeptic's point of view.

Simon (the implementor) 1: "OK, I don't want to get fired. But what this "multiple" got to do with it?"

The multiple is the relationship between the cost of the team and the NPV (net present value) of the benefits the Team delivers. As in: "If I invest $1 million in this team over a year, I expect them to (and they usually do) deliver about $3 million in NPV from that work." If you have been doing any investing in the stock market lately, you will appreciate that that is a powerful statement.

Simon 2: "Great. You're asking me to get something I don't understand. And I know we don't have it around here. Thanks for nothing."

Well, if you are an implementor, you have no real need to understand NPV in detail. How it is calculated. You're right about that. Product Owners (or business sponsors) should do that. But you can appreciate that some BV must be delivered, othewise the firm would not invest in the team (or at least should not). ie, You don't have a job.

You think no one has NPV around your shop? Three comments:
1. Yes, this is all too common. And incompetent. (Did I say that nicely enough?) [more on this below]
2. They might have it and not tell you. At least the initial estimate used to justify approval of the project.
3. To me, it is also incompetent management not to inform the team, at some level and frequency, how much BV they are delivering. (more on this below)

So, go ask your Product Owner: "Show me the money. Now." If she can't show you money, she must at least have something.

Simon 3: "I went and asked the PO. And she said it was too hard to estimate. She said: "It's a very important project, trust me." Too much risk involved. Kinda made sense to me."

Well, at some point you must say: "If these guys manage this badly, I should go work for a better managed firm." But maybe not this week.

Yes, doing our work as professionals is hard. Estimating BV is hard. And predicting the future is difficult. Developing software is difficult too. But of course, that should not stop us from doing what is important.

People also make it seem harder than it is by demanding too much precision. All we need is a decent number, with a reasonable bell curve of probable values, and we have enough to make decent business decisions. (Simon says: "Ok, yeah, I remember that bell curve stuff from that stats course in college.")

So, who knows how to convert risk into dollars. Let's see...umm, I just got a bill from my auto insurance company. Oh yeah, they use "actuarial science" to establish premiums (price/value) for risk. So your firm could hire one of those guys.

Simon 4: "I went back to the PO and she said we have no actuaries around here now. So we're stuck. Your idea is a non-starter for us. And thanks for making me feel bad too."

Wait a minute. Let's try another approach.

Can we get about 5 key senior managers who understand the business side of your industry? And also the business side of your effort (project/product)?

Ask them to play a kind of wide-band delphi. They discuss the assumptions and facts around the project (or set of Product Backlog items) to guess at the total BV. Then each independently guesses (eg, writes a number on a hidden sheet of paper). Then they all show at once. If the two extremes are disparate, then the two people who voted the extremes talk about assumptions. And maybe the team asks more questions to get the info for a better estimate. Maybe they vote again (and maybe another round). At some point you declare "we have enough consensus", and average the numbers given.

In case this "team" may be biased (or someone will complain loudly that they are), I suggest you or the PO have them take the number and explain it to a more senior manager. If it passes his "sniff test", then it is good enough for business decision making.

Simon 4: "Yeah. Tried that. They wouldn't bite. Are you wasting my time yet?"

Ok. This happens. Usually I am not happy with it. Sometimes it makes some sense.

So, we have another approach.

Ask the delphi team what the maximum is they would pay for it (that feature set or "the project"). Go through some reasonable consensus building. Then take the numbers and average them. Now you have a number. It may need "rounding up", given that most people want to make a profit on investments. And this number is the max cost, not the max value.

Simon 5: "OK. That sounds reasonable. But what if they don't bite for that?"

At some point you must persuade them. Or leave. Or wait to be fired (worst option).

Explain to them all the ways that not having a decent estimate of BV known by the Team is hurting them. Often this will work.

For example, telling the Team the Business Value will almost always change their behavior. It will affect their motivation. It will get them thinking about what is most valuable to the customers (or various end users) and to the firm. Your best implementors typically don't do their best work until they see the challenge.

Simon 6: : "I will try. But what if they don't do it?"

Again, if they are really incompetent, you should leave. Alternately, show them why BV is important to you. Make a personal case.

BTW, incompetence can be very easy to fix (or very hard). Some people, with just a little training, can become competent. So, we don't mean these folks are evil, or mean harm, or are completely stupid. Probably no one, yet, has made them see how doing things a different way would be better.

Simon 7: "Wait a minute. That remark could apply to me. Are you insulting me?"

Well, the usual case is....we all could be more competent at our jobs. It is more useful to think of this as...not a problem, but an opportunity.

Simon 8: "OK. Let's imagine they give us an estimate of BV. How do I know they didn't just pick it out of [bleep bleep]? I mean, you know what these [bleep] are like!"

Simon, come on. This is the public airways. Please.

Still, very good question. Make them get real numbers that show, after-the-release, whether the estimate was decent or not.

Usually the estimate will be somewhat wrong (high or low). Tease them a little, but don't make them chicken to guess (uh, estimate) the next time. As you know, stuff happens between the time you estimate and the time the software goes live. And insist that they learn how to do it better (and maybe more frequently).

By learning about this, we each can have more successful work. More satisfied customers. This makes for more successful firms. Pretty soon, we might have the economy back on track. And then my neighbor will have a job again, and quit talking to me endlessly about ACC basketball.

This Bus Value stuff is not as much fun as watching somebody make a fool of themselves on American Idol. But it might be more important. To you.

ACTION: Go identify your multiple. Now.

noreply@blogger.com (Joe Little) — Tue, 03 Mar 2009 18:40:00 +0000

Two posts ago, I buried a key idea in a lengthy list.

Here's the gist. When the managers come around trying to figure out who to "re-engineer", would it be helpful to be able to say, "Guys, the firm invested in our team about $1 million last year...and got about $2 million back NPV"...might that allow you to relax if you could say that? (NPV means Net Present Value...your Product Owner should know this stuff.)

By multiple, I mean the relationship between NPV and cost. Usually the multiple is between 3 and 20 (or should be).

OK. Action item. For today. Go talk to your Product Owner and estimate the NPV of your last project as a team or your current set of work (say, next 2 releases). Annualize it (managers think more easily in those round numbers).

Much better if the NPV estimate is based on actual results rather than someone's dream of what the benefits "ought" to be.

Yes, there are lots of issues. Yes, life is difficult to measure. Get the best approximation you can.

Example: "We have a risk project. How can you measure NPV for risk?" Umm, who is really good at putting a price on risk? Auto insurance anyone? Go talk to an actuary and let 'em help you figure it out.

Yes, there are lots of problems with these numbers. Heck, there are lots of problems with helmets in the NFL, but I would not recommend playing without one.

Contradictions

noreply@blogger.com (Joe Little) — Sun, 01 Mar 2009 19:32:00 +0000

I have been noticing the contradictions in Agile and Scrum lately.

Jeff Sutherland recently did a post about persuasion. The the latest post might be summarized as: "To persuade you must be confident and humble." Oh, sorry, I guess no contradictions there. But he does talk about contradictions elsewhere.

And this quote has been bouncing inside my head for several weeks, and wants out:
"The test of a first-rate intelligence is the ability to hold two opposed ideas in mind at the same time and still retain the ability to function." F. Scott Fitzgerald

We are decisive. We delay decisions ("hey, looks pretty indecisive to me, dude").
One contradiction that I am talking about a lot now revolves around this saying: "Velocity. Don't leave home without it."

We use the known velocity to push back on "magical-thinking" managers who want us to "just do twice as much" in the same amount of time. At the same time, we (the team) use velocity to challenge ourselves to triple our velocity. Like Michael Phelps, we are never satisfied with the record we set yesterday. And by doing many small experiments, we can triple.

I do not need to refer to Hegel's Dialetics, nor to Taoism to help me understand that: "Male and female he created them." There is something in our jeans that tells us opposites attract. Only by seeing the "yes, and" will we create something wonderful. Together.

On a slightly different note: please look at Takeuchi's article in the Harvard Business Review, 06/2008, entitled: "The Contradictions that Drive Toyota's Success." (I didn't add the pun. Honest.)

So, if you notice some contradictions, maybe they are there for a purpose.

Is Agile useful now?

noreply@blogger.com (Joe Little) — Mon, 23 Feb 2009 18:20:00 +0000

Why, yes, Virginia, the times they are a-changing.

You may have noticed a few not-entirely-happy things happening out there in the economy. It might even have affected you and perhaps even your place of work.

So, in what ways is Agile relevant? Now.

First, Agile is even more relevant now than before. (OK, just my assertion so far; see below.)

Second, for reasonable firms, it should be easier to implement Agile now, as there is a greater sense of urgency. (Yes, there are probably some areas with people running around like chickens with their heads cut off. Always some exceptions.)

So, in what ways is Agile helpful?

The team is the best unit to manage. (Organize people into Agile teams, and measure the success of the team.)
Agile teams adapt faster. Probably pretty useful in your neck of the woods just now.
For the team itself: Assuming a strong Agile team, that knows its cost, and knows its "multiple" (now much Bus Value it delivers for its cost), it is far easier to justify its existence in the face of layoff. Anyone getting a 200% return on investment these days? Well, a decent Agile team (with a decent Product Owner) should be getting that almost at a minimum.
Progress. Both in terms of increasing BV (business value) and in terms of increasing Velocity (story points of size/complexity) the team should be able to show a record of getting better all the time.
Faster time to market. That is, we get new products to market before our competitors. Or we respond to competitors faster than they expect us to.
Satisfaction. This one is actually for managers. You might be noticing that some of your people are getting demoralized or are lacking in focus. A normal human reaction. Agile does not have a silver bullet, but there is a great deal of satisfaction in working together in a decent team, and the biweekly or monthly Sprints keep the team focused on delivering. Maybe useful in your area just now.

The transformation to doing Agile (or doing it right) is hard, yet cheap compared to the alternatives. Or so I think, and would be happy to prove.

There are a few thoughts. What else do you find?

Should we invest in a better Product Owner?

noreply@blogger.com (Joe Little) — Sat, 07 Feb 2009 14:52:00 +0000

I won't bore you with the calculation, but...

If you assume that a better Product Owner can:
* increase the value of Product Backlog items (stories) by 20% on average
* identify the Pareto curve partially in the Product Backlog, so that an 85-33 rule applies
* and if we assume that the team costs about $1,000,000 per year (all-in) and delivers, before the better PO, about $3,000,000 per year...

...then, what happens?

The team is now able to deliver $3,000,000 "projects" three times per year. Thus, this new PO has tripled the business value delivered by the team.

So, how much could you afford to invest in that better PO to get those results? Probably more than $1,500 (eg, for a Certified Product Owner course). And, while the course is good, I suspect that most Product Owners need more than just the course to get those results (eg, perhaps some coaching from someone really good).

So, what's the first impediment to doing this?

What I find is that most firms think of their IT department as a cost center. And thus they have no concept of BV delivered by IT, much less metrics around that. So, I am suggesting that just getting estimates of BV (and telling the team) and then measuring (even if only roughly) the BV actually delivered would be a big step in the right direction.

BV does not have to be measured in money. At least not initially. Depending on your firm, other direct metrics would be more meaningful. Then you need some experts to give you a rough estimate of the money value of those benefits.

Knowing the BV delivered of each team might be kind of important right now. In more ways than one. Go talk to your Product Owner about that today.