Empirical Process Control

Posted on May 1, 2013 by Joe Little

Ken Schwaber and others talk of Empirical Process Control ideas as being key to understanding Scrum. I think this makes some sense.

Mr. Schwaber got these ideas from Babtunde Ogunnaike and W. Harmon Ray, who wrote the process bible: Process Dynamics, Modeling and Control. Big ole book, mainly about chemical processes.

We are talking about how to build new products. How to get business results, in the form of new products. Innovation. Some of you don’t even want to call it a ‘process’.

But to process geeks, if you build something in a half-way regular way, then that way that you build things, even if fairly irregular, is a process. Of a sort.

Ken Schwaber uses this (to the Scrum world) famous quote from Ogunnaike and Ray’s book:

It is typical to adopt the defined (theoretical)
modeling approach when the underlying
mechanisms by which a process operates are
reasonably well understood. When the process
is too complicated for the defined approach, the
empirical approach is the appropriate choice.”

In very simple terms, we Agile folks take ‘defined’ to mean ‘waterfall’, roughly as defined by the famous waterfall article by Dr. Winston Royce.

Two things must be said about ‘waterfall’. First, Dr. Royce defines and shows lots of feedback loops, and most people, when they speak of waterfall, do not mean that. Or they mean that those feedback loops are very weak and work poorly, very poorly.

Two, Dr. Royce calls for builders to ‘build it once, throw it away, and build it again (correctly).’ This is virtually never done in real life, and is typically not meant when people say ‘waterfall.’

And by ‘empirical’, we take that to mean, very simply, Scrum, as defined too quickly in the Scrum Guide by Jeff Sutherland and Ken Schwaber.

So, how do we connect the dots? A later question is: have we connected them fairly, usefully, and with as much rigor as possible. And a final question: is there any more light that ‘process control’ ideas can give us, to enable us to do our innovation/new product development work better?

***
Here are what I think of as the basics of process control, as applicable and useful to understanding Scrum better. And the two basic methods or approaches (defined vs empirical).

This is what I think I have been told over the years. By several different people. In fact, I may be adding and subtracting what others have said to me.

It is a very simple theory or set of ideas. Even though it is simple, it is still (IMO) useful.

There is also a lot it does not ‘explain.’ Although perhaps one could start to use these basics concepts to discuss these other things or issues.

In the simplest model, process control consists of a flow across three ‘elements’.
1. Inputs
2. The black box (‘the process’)
3. Output

If 1 and 2 are both ‘in control’ and highly reliable, then 3 is likely to be reliable. Ceteris paribus. These are the conditions for a defined (waterfall) approach.

At the other ‘end’, if both 1 and 2 are ‘out of control’ or unreliable, then 3 is, by the definition of this model, unreliable. (Unless there is some other element that magically makes it reliable.) These are the conditions for an empirical approach.

What does empirical approach mean?
a. We inspect 3 often (this is only common sense — when 3 is unreliable one naturally wants to inspect it more often; one needs to), with the ‘best possible’ eyes, expecting it often, even usually, not to be what we want.
b. When 3 is not what we want, if we can, we pull it back to the beginning, and run it through again. And try to ‘adapt’ either 1 or 2, to make them temporarily more reliable. And pray that 3 is or becomes — after we run it through again — actually what we want.

We are assuming for now 3 (the widget) can be run through again, usefully. Of course, this may not always be the case. For software, this is true. For some physical products, this may be a bad option.

Now, the empirical approach is terrible, obviously. If one (the ‘God’ of the process) had any sense at all, one would change things so that 1 and 2 were both highly reliable. And then 3 would become reliable. That is, one would change things so that one could use the defined approach.

But, what we are saying with new product innovation with human beings, is that we never have 1 or 2 in a reliable state.
We are not God, and there is too much stuff hitting the fan. From every direction.
So, while we might control the inputs and the black box for 3 minutes, after about 3 minutes things are unreliable again. Sadly. So we are always stuck using an empirical process.

But at least we understand the process we do have.

***
Personally, I consider human beings highly unreliable inputs to any process. We humans often compare ourselves to machines, but in fact we are highly unreliable. Now, innovation and creativity are ‘the unexpected’. So, in innovation ‘unreliability’ is actually a good thing. So, humans aren’t that bad after all.

This very simple theory or paradigm seems very real and accurate to me. It makes sense, to me, of the mess that we are in. The tar pit, as Fred Brooks calls it.

I think this is basically what Tunde Ogunnaike and Harmon Ray meant. At least for us. When they compared ‘defined’ and ‘empirical’. But, I will ask them.

***
Now, some questions that this very simple theory does not answer.
1. What if only 1 or 2 is ‘unreliable’? (And the other one is reliable.)
2. How unreliable do 1 or 2 need to be before one uses an empirical approach (as you call it)? One imagines that, at very low levels of ‘variation’ in 1 and 2, …that the ‘defined’ approach would still work or be better.
(As a practical matter for software development, I find that 1 and 2 are so ‘out of control’ that this question becomes moot.)
3. How do you know there is not another ‘element’?
4. What if you can’t adapt ‘enough’ (on 1 or 2)?
(Logically, in the simple case, one stops working or trying to produce anything, since 3 is highly likely to be wrong. Unless one can live with totally random success.)

Is release planning worth it?

Posted on November 28, 2012 by Joe Little

In a word: Yes, if done professionally.

How is release planning, and release plan refactoring…how are they useful?

A few ideas:

It enables the Team to share ideas
It allows the Team to see the same elephant
It enables knowledge creation
It enables cost, benefit, time trade-offs to become apparent
It enables everyone to start to distinguish minor decisions from major decisions

Any professional also knows that planning is not and never will be perfect. So, we must put a reasonable time box on doing the planning.

It is also useful to plan with good ‘agile’ people. Meaning people who will use the information developed from planning in a useful way (eg, will not do the ‘stupid waterfall manager trick’ of expecting the Team to always hit the date they planned on Day Zero).

Let’s talk about this last one (minor versus major)…

To put things simplistically, there are two types of decisions, which I will call minor and major. Minor decisions has a minor cost if we make them incorrectly. If we are clever, we soon learn that we are wrong, and we correct the decision.

But some decisions are major. To change the decision later, it can be very costly in terms of money or time or reputation or some other factor. Once we identify a major decision, we want to do our best to decide it correctly. This means first being sure we have framed the decision question correctly. Then, assuming this is a difficult decision, we want to make the decision at the ‘last responsible moment’.

***

Can planning be useless or worse?

Well, of course. If you have people who will not learn. If you have people who will take longer than the current knowledge can justify. If you too many people who want to use the information for ‘stupid waterfall tricks’.

But if done with good people, using useful concepts, the Scrum Team (and others) can learn a lot doing Release Planning, followed by Release Plan Refactoring every sprint.

It is also true that we can learn by doing ‘real work’. This is not to say ‘do only real work’…but one balances and shortens release planning (release plan refactoring) in the knowledge that we can and will learn some things faster by doing real work.

Joe’s Agile Release Planning

Posted on October 30, 2012 by Joe Little

I have written a new booklet that I want you to have (I think you will find it useful) and also to comment on.
It is about Agile Release Planning.

It proposes that agile release planning consists of these major steps (at least):

Assemble the Team and some business stakeholders
Agree on the Vision (of the release or maybe more)
Create the Product Backlog
Determine the Business Value
Estimate the Effort
Consider Risks, Dependencies, Learning, MMFS and other factors
Order the Work
Do the scope-date trade-off
Finalize the initial plan
Consider the ‘communication plan’

Note that the purpose of the work is not focused on the release plan itself. The most important purpose is the Team together with the business stakeholders start seeing the same elephant.

So, I wrote a booklet to show and explain how I teach teams to do each of these steps. And to address some of the ‘lessons learned’ in doing this approach in the real world.

I hope you will read it and comment. Please download it here. It is 28 pages.

Self-organization

Posted on July 27, 2012 by Joe Little

We have this idea in Agile, that the Team should self-organize. This is an important idea. And also an important occurrence (eg, the reality precedes the idea).

In Agile, self-organization is compared to command-and-control.

We think self-org is an important thing to study, both in general and in your Team.

Why

Well, one, because it is just right. People are free, and self-organization is saying that the Team is allowed to be free.

I guess this needs to be explained a bit. Some will say: well, the company has bought their time as employees, so the company gets to define what the Team does. Well, let is concede this at a high level; let us say that the company may define the vision or the goal or the general product. Perhaps even the user stories. The Team members are not slaves, but we can assume that, as employees, they agree to do the company’s work for pay. A contract.

But, devising the work, figuring out how they will get to the goal, they should have the freedom to do.

The second main answer is: self-organizing humans tend to do better work than human ‘slaves’ (humans directed by one or a few command-and-control people).

There is lots of evidence of this. The first book I recommend is The Wisdom of Teams by Katzenbach and Smith. This is a rather old book. But the basic evidence is that a self-organizing team out-performs, almost always, an individual. And to such a degree that the extra cost is well worth it. But, you must given them some degree of ‘freedom’.

There are also a lot of more recent evidence.

Some topic you may wish to research:
Self-organization
Complex Adaptive Systems
Maneuver Warfare
Free Enterprise
Knowledge Creation

Note: Some people say that a free enterprise system is mainly characterized by (mostly) private ownership of capital (means of production). And attribute its successes or failures to that. Others focus on the freedom of individuals to make their own decisions (much like the “wisdom of crowds” idea) and on the view of the national economy as a complex adaptive system, trying to accomplish high-level economic success via many individual agents (people or companies) making their own decisions. In our view, successful free enterprise countries exhibit many of the successful characteristics related to self-organization.

Command-and-Control Managers

Lots of managers have been taught, explicitly or implicitly, that the ‘workers’ are dumb, and the manager must tell the worker how to work. In our view, especially for virtually 100% of knowledge workers (our domain), this is very very incorrect teaching. But it is nonetheless, what they have been taught.

Now, some of them also understand freedom to some degree, and understand that they want the people in their group to ‘think for themselves’. But, we can say with relative assurance, most companies have a lot of people who are relatively command-and-control in their style.

And, in pressure situations (our common situation), they want to use too much command-and-control.

Again, this is not true of all managers, but of many. It depends, in part, on the company’s culture.

It is hard to convince these people to be patient for self-organization.

Teams that won’t self-organize

This is seen in real teams.

There seem to be several root causes. One, the team has been beat down by command-and-control managers so much, that they have ‘forgotten’ how to self-organize. Another: that they Team does not believe it when managers say ‘self-organize’. Another: The Team is fearful that by self-organizing they will be ‘held accountable’ with punishment a likely outcome. To avoid pain, they refuse to self-organize.

Whatever the reason, two things can be said.

Many Team (perhaps with Agile coaches) do eventually break out from being ‘stuck’ (not self-organizing).

And some Teams may take a very long time or perhaps never do it.

The key advice is this: If the Team will not self-organize, or seems to want to self-organize to mediocrity, then a good manager should intervene. Temporarily.

Perhaps prior key advice: Be patient. Often Teams will self-organize in two or three sprints. Keep talking about it, and ask them if they need help.

Third advice: In the view of some (including me), some Teams lack some key skills to self-organize. For example, a new junior Team may not know really how to break down work into tasks for the sprint planning meeting. Sometimes ‘holding their hand’ as they mature is a very successful approach. And 3 or 4 sprint later, they can be very good at self-organizing their own Sprint Backlog.

Learning to decide as a Team

I think each Team learns how to decide.

The first, most useful thing, is that everyone in the Team gets to offer input on a decision.

Next, the Team needs to accept that no decision is ever perfect. Thus, decisions in general must be made, perhaps not always quickly, but promptly.

The Team needs to understand the impact of decisions on the morale of the Team and on the success of the Team.

In our view, most teams go through a forming and storming period of decision-making. And then later get better.

Good self-organization… and better

Lots of Teams seems to self-organize well.

What is also common is for most Teams to plateau.

In part, we may say that a root cause is that most Teams want to reach a stasis… a place where things are balanced and where change slows down.

But have they reached the height of improvement? We think not. Some Teams have reached much higher heights. And some Teams keep on improving.

There seem to be two main factors (or sets of factors):
* magic — or, more accurately, a bunch of things that are hard to describe.
* a bunch of factors that people talk about, and some teams study and work on

Some of these last factors seem to be quite ‘soft’. Love, listening, creativity, heart seem to be among them.

Lastly

If you have never been on a good team, it is hard to understand what self-organizing is all about.

Within the Team, it might be rather rough and ready. But a lot depends on the specific individuals in the Team.

Scrum teams and our Mammalian nature

Posted on October 24, 2011 by Joe Little

My experience with people doing Scrum is that we tend to take the “man is rational and isolated” hypothesis to easily. Often it is not a thoughtful choice, just the implicit assumption of the way we are thinking or the way we speak.

Isolated and individualistic are key words. If you believed in them, you would build cube farms for people to work in. For example.

Is there another hypothesis? Turns our there might be several, but one is that humans are fundamentally like all ‘pack’ mammals. We work and have worked, over thousands of years, in small teams, and these teams support the members inside the team. We have a limbic brain or limbic system that supports the huge emotional and ‘social processing’ needs of pack living.

Here is an article on the limbic system.
http://en.wikipedia.org/wiki/Limbic_system
(As you will start to see, the spiritual, physical and thought-memory processing aspects of the brain are quite complex, largely sub-conscious, and quite fascinating. And there is much for us still to learn, IMO.)

How does Scrum inter-operate with this?

Well, first Scrum seems implicitly to recognize the pack or mammalian nature of people, and organizes individuals into teams. (Our mammalian natures may be one of the reasons for this, but certainly not the only reason.)

Scrum implicitly seems to understand that the team starts to be a source of well-being and of motivation for the individual. While the team demands something of the individual, it also supports him (eg. “can I help you with that?”). The team provides this ‘pack’ sense of belonging. That they say we all need. (And I think I believe ‘them’ on this.)

More than a sense of belonging, it gives us a sense of purpose. We want the team (pack) to succeed. And we want to contribute to the team’s success. To the degree that each person identifies with the team, this is a whole set of subconscious associations that each of us tends to make with the team.

Did the designers of Scrum do all of this on purpose? Well, I have worked with Jeff Sutherland a lot, and I have never heard him put things this way. But he has suggested that there is more going on than can be explained.

And now to you….

Assuming that we as humans are largely pre-rational mammals with a need for a ‘pack’, in what specific ways would you use this information to make your Scrum team more successful?

Thanks.

What gives?

Posted on October 29, 2010 by Joe Little

I was just at the Agile Tour at Research Triangle Park in North Carolina. Very good event (kudos to Catherine Louis and the other organizers!!).

Laurie Williams, who is a great person and a great agile researcher, has done some work recently on, and I should use her words but don’t have them handy, ‘how do we feel about the Agile Manifesto and the Agile Principles now?’

One general reaction I had, which is also a reaction I have had recently in other situations….

When push comes to shove, what should give way: Agile principles or our local organization?

In my view, almost always the problem is ‘us’ and not the agile values, principles and practices.

And almost always, we make the agile stuff ‘give right of way’ to what we call ‘reality’. But it is not ‘reality’ as in the law of gravity, but only reality in that these are the stupid ways our organization is doing things today.

Example: Sustainable pace.

Some people complain that the principle of sustainable pace means that managers can whip us to stay at 30 story points per sprint (after the team itself volunteered to go 30), and that it does not allow us to fix the technical debt or do the broader range work that must (at least eventually) be done.

This is my view:
* sustainable pace is very important in many ways. The main way I like to talk about it is that it is no longer about ‘hard work’, it is about ‘creativity’ and ‘innovation’ and ‘inventive’ solutions to difficult technical problems. Our brains have to be fresh to be creative as a team.

* sustainable pace (as measured via velocity) quickly becomes less valuable unless we are doing virtually everything possible never to allow technical debt to grow. Let’s be professional.

* sustainable pace does not mean that the team ‘must’ maintain the same velocity every sprint. (Yes, Virginia, stuff does happen, for example.) AND, the team should always be challenging itself to remove impediments so that more ‘work’ can be accomplished in the same amount of time. In other words, in general and on average, ‘velocity’ should be upwardly sloping. But NOT by working harder.

* an empirical process requires transparency (or a high level of it) and any pretending about or hiding of ‘undone work’ (as Ken Schwaber likes to call it) is not helpful at all. Sustainable pace quickly becomes meaningless if we do this. (Cf Technical debt above.)

* Bad news does not get better with age. So, sustainable pace must be immediately linked to a strong and improving ‘definition of done’ for normal stories in a sprint.

* By sustainable we must mean we are doing everything we professionally can to assure we are keeping each sprint up with ALL the different types of work needed to keep the system fully ‘done’. This includes fixing all bugs, doing all the refactoring, building all the truly useful documentation, visioning of future sprints, release plan refactoring, etc, etc.

* As soon as we discover some undone work (and we as humans will typically forget something and thus it is undone), we must address it professionally….do it immediately or put it on the product backlog. And consider how much it makes our previous information about velocity and progress a lie. (Always, to some minor degree, and possibly to a significant degree.)

* Just because we will always be imperfect does not mean we should give up on agile or agile principles or practices.

Can you put these ideas into action real soon? (Today is a good day.)

PS. I am not saying the Agile Manifesto and the Agile Principles are perfect. But maybe I am saying that our real worlds are messier than those ideas. Or so I see.

Do Scrum and Kool-Aid go together?

Posted on February 26, 2010 by Joe Little

Occasionally I hear the complaint: “Oh, you [scrum, agile, lean, x] guys have drunk the Kool-Aid. You don’t care how reality intrudes, you’re just going to propose your [X] solutions.”

And what does this person mean? He might mean: “Completely on faith, without any support of reason and facts, you are a strong advocate of a certain set of views.” He might also mean that we have let out minds be clouded with too much emotion and too much enthusiasm.

And of course, in the Agile community, there are indeed some people who resemble this remark. His (or her) comments do indeed have some traction. (Maybe I think not very much, but at least some.)

So, what is the right way to play Agile?

Well, first, of all the rigorous approaches to new product development, I find Scrum and Lean to be the MOST reality based. For example, the principles of Scrum require us to be transparent about the truth. Require us to keep an honest velocity. And require us to admit *every* Sprint the painful truth that we are not (yet?!?!) perfect, and we must remove one impediment now, and get better. And we try to immediately use all the good and bad aspects of the truth, as it minute-by-minute unfolds, to get better.

To be honest, I still lie. But I must say, when I did waterfall, I felt it was helping me lie, while when I do Scrum, it puts the mirror up and makes me see how much I still continue to avoid the truth. So that I almost can’t avoid. (Of course, being a clever guy, I still do avoid it some.)

So, when a Scrum theory or practice hits a hard reality, Scrum allows that the hard reality wins. It also demands that the onlooker examine yet again how they are twisting the truth out there in the very process of trying to perceive it….but when we really understand the truth, the truth always wins.

Now let’s move to emotion. It is right to say that any sport, if you play to win, it must be played with intense…energy or intention. Some wish to call this emotion…ok. And Scrum is such a team sport. But to play any sport at a high level, one must ride one’s emotions, but at the same time control them. All the winners know this, and it is indeed this that is their greatest struggle (I am thinking Roger Federer just now, but many great athletes will tell you this if you have not experienced it yourself).

Now, being emotion in this way does not mean that the energy is allowed to deceive our good perception of reality. In fact, to play a sport well, one always wants a hyper-perception of reality. They say: “It was as if the ball was moving in slow motion.” As one example.

Now, junior level athletes forget these great lessons more often, and sometimes have not even become accomplished enough to start to deal with these lessons yet. But do not blame tennis that some people play it terribly. Do not blame Scrum that some people allow their emotions to cloud their judgment. Scrum is only a vehicle to enable them, in the time that God may appoint, to learn to live better in this real world.

Oh, and if you play Scrum, don’t forget to drink the Gatorade. Your body needs that hydration and the electrolytes. To also help enable the creativity.

Spontaneous Order

Posted on December 17, 2009 by Joe Little

I will not remember this well (knowledge decay), but there is a great quote from Fujio Cho (now Chairman of Toyota) at the beginning of Liker’s The Toyota Way. Something like: “There are many things you do not understand, and therefore we ask you, ‘why don’t you just take action? Try to do something.’” With the idea that you thus cut the gordian knot of inaction, and start real learning.

What happens if we do not? The opposite: “And thus the native hue of resolution is sicklied o’er with the pale cast of thought.”

And enterprises of great pitch and moment
With this regard their currents turn awry
And lose the name of action.

I have been in projects like that, and so have many of you. (These last two quotes are from a play, not Fujio Cho.)

The soft spider web of thought can be the hardest, most granite-like roadblock.

Yesterday I finished helping to teach a Certified ScrumMaster course with Jeff Sutherland. So, a couple of related thoughts from several conversations.

1. Spontaneous Organization. In the agile community, we are fond of self-organization and complex adaptive systems. And these ideas go way back. Chuangtze and Laotze taught us that the Tao that can be expressed is not the true Tao. That Tao organizes itself in things great and small. And Chuangtze especially talked about the spontaneous organization of things, nature, people, society. That if left alone, they would move toward Tao; that human meddling would more likely move them away from Tao. Better that they take on that more perfect imperfection of Tao, he seemed to say.

Like many another idea, these ideas were picked up later by others, by Proudon and Hayek for example. Tolstoy speaks of this when he talks about the hive of Moscow after the battle of Borodino in War and Peace. We see this in the things of nature, where Energy and Mass self-organize at the speed of light. (OK, perhaps a play on Einstein.) But there is a natural organic spontaneous organization of things.

Now, in real life, that spontaneous organization might be at a mediocre level or a hyperproductive level. The ScrumMaster may have more influence over this fork in the road than she has accepted yet.

I suggest to you that the ScrumMaster, at least, think deeply on how to put these mere thoughts into action for each team. And stir the pot gently. Maybe start here: http://en.wikipedia.org/wiki/Spontaneous_order

It is by spontaneous order that free enterprise gives you your daily bread. However much we may say (and it is true) that man does not live by bread alone, still we must have bread.

2. The ineluctable contradictoriness of things. We humans have this wish for things, for life, to be simple. And so in some ways it is indeed. “A kiss is still a kiss.” But we are everyday forced, if we allow our eyes to see, that in so many things there are contradictions. Male and female. Good and bad. Black and white. Darkly wise and rudely great. Go fast slowly. Achieve by not trying. I must be cruel only to be kind.

Sometimes we see through the glass, darkly, that these contradictions do not need to ensnare us, but rather they give us balance.

So, for a pedestrian example, the ScrumMaster should be a servant-leader. The Team should use velocity to push back at the magical-thinking managers who demand they double output; and the next minute demand of themselves that they push velocity to hyperproductivity. From a certain point of view, these can seem utter contradictions.

In theory, we may think these contradictions should make us fail; in practice, done well, we come to know they do the opposite.

Perhaps a few of you will find the famous Butterfly Dream (see that link) an apt koan for the harmonious contradictoriness of things. Chuangtze has other, perhaps better, stories that deal with this.

ScrumMasters: They can cut through their mental spider webs in a minute. Or in two years. You can be a key difference. This is your great refactoring work. Find that sharp, swift, gentle, liberating sword. And pull it out.

The Nokia Test (2): Working Software

Posted on February 8, 2008 by Joe Little

The second line in the Nokia Test says: Software must be tested and working by the end of each iteration.

This is the second of three items that confirm that the team (project) is “iterative”. Then there is a series of small tests (within the Nokia Test) for whether the team is really doing Scrum (in Nokia’s opinion).

Why this second line (element)? As with almost everything in Agile, there are many good answers to that question. I will highlight three.

1. We can get better feedback. Only by having the software tested and working, can the Product Owner and the Stakeholders give the best feedback. And we want short, small, fast feedback: “Yes, it’s what I said, but now that I see it, it’s not what I want.” When it works, and they put it together with everything else that is working so far, then they can lift their eyes up from the weeds, and start to see if a real customer product is starting to emerge (be formed). Sometimes this allows them to creatively discover other visions for the product (or improvements to the vision of the product).

Arguably, one could get feedback without being fully tested. I am not particularly impressed by that argument, but I’ll leave it for now. But my next reason for this line in the Nokia Test addresses that argument.

2. Working (fully tested) software is the primary measure of progress. This is straight from the Agile Principles that were agreed when the Agile Manifesto was written.

And why is that important or right? Well, before that, many were measuring progress by how much paper was churned out, or how many detailed tasks were done, or by the dev team saying “We’re 63.2% done”. None of these were ever very reliable (at least in my experience and that of many others). Certainly they had minimal meaning to a business side person who had to manage the risk of delivery by a specific date.

OK, so what does it really mean to have working, fully-tested software? Well, each team must define at some level of detail what “done” means. A company, at a slightly higher level, might also have a standard definition of done (with perhaps some wiggle room for special cases).

That definition of done would typically include (or at least address) things like:
* coded (duh!)
* automated unit tests built, in the configuration management system, run, fully passed
* refactored (anything that needs to be refactored has been: code, design, arch) Note: some refactoring might also occur after some things below.
* put into the integrated build and a new (QA?) environment (the new story does not break other things, etc.)
* automated functional tests built, in the CM syetm, reviewed by business guys, fully passed per a QA person
* other testing done (more variable by effort…eg, some performance or exploratory testing)
* business side testing and review (maybe by the Product Owner…full thumbs up)
* fully documented (any docs that need to change because of this story have been changed and reviewed and are perfect)
* no outstanding bugs (or none of any consequence)

If a story passes the above criteria, then a business person (in most projects) can assume a fairly clear and small amount of additional effort to take that story or feature live. This knowledge can be very powerful and give the Product Owner the courage to identify more early releases.

3. Working and fully tested software is necessary to know (meaningfully) the team’s velocity. (Velocity is really a later element in the Nokia Test, but this line in the test is setting up the team to have a meaningful velocity.) Velocity is useful in many ways, but I’ll just explain it with the family vacation metaphor. When the kids in the back seat ask “when will we be there?”, if I know we are going 60 mph (our velocity), and it’s 180 miles to go, even I can give a pretty accurate answer. Good enough to make mission critical decisions like whether to pull over for a potty break. And, as it turns out, good enough for most real business decisions. And, as it turns out, giving us about as info with as much quality as we can get.

The Agile Recipe; on second thought…Not

Posted on October 26, 2007 by Joe Little

I have been asked recently to provide a recipe for how to do Agile. I am sympathetic with this request, but I feel it misses an important point.

First, why am I sympathetic. Well, because I look at Agile as an art form, like playing the violin or learning Hapkido (Korean version of Aikido). It is an art that one continually learns. And, at the beginning one feels lost. How do I learn this thing that seems so strange? How do I start to make un-ugly noises from the violin? And the teacher must give you instructions of some sort, and you start to play. Perhaps ugly at first, but you start to play. And then you start to be…as a friend pur it recently, you start to suck less.

Of course, Agile is more like a team sport than playing a violin. But it is still an art. Where one starts with little skill and builds and builds. Agile is like the “ballet with force” that is basketball.

OK, So how do you learn to play basketball?. Well, start by dribbling. (Which one can break down.) Learn to do a layup. (Which one can break down.) But the real thing about basketball is not the individual skills. The real juice is learning how to play as a team. To improvise on the court. To maintain your confidence if the other team dunks on you twice in a row.

In basketball, there are a few set plays that one can diagram. With perhaps many variations. One cannot just follow a recipe in playing championship basketball.

This is where giving the recipe can mislead. By giving a recipe the coach can suggest to the beginner “all you have to do is follow the recipe and all will be well”. Maybe with an ordinary dish, but not if you want a meal that dazzles. And don’t you aspire to produce something that delightful?

If you have studied an art, you know that great artists will tell you that being really good requires a certain something that is hard to define. In Agile, we often say that you must “get it”. You must start to reflect, in your every thought and decision, Agile values and principles. And without these values and principles, just following the cookbook or the recipe will make only a small improvement.