Services We Provide

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

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

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

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

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

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

Now back to our regularly scheduled programming.

Up the creek. Without a paddle

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

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

Very simple idea. Very true.

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

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

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

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

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

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

What is the scope of impediments?

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

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

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

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

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

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

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

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

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

Does this make sense to you?

The importance of Velocity

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

Why is velocity so important?

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

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

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

Three words.

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

What do you think? Helpful?

What is a ScrumMaster worth? (2)

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

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

Your Business Case for Agile

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

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

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

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

So, what is the case?

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

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

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

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

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

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

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

OK. One more thing on this topic.

How do you prove this for yourself?

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

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

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

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

Can fairly good people generally show impressive progress? Yes!

Developer Abuse

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

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

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

Being Agile is our favorite thing

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

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

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

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

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

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

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

The Product Owner has these responsibilities in Scrum:

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

A few comments.

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

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

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

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

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

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

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

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

Mura, Muri, Muda

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

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

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

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

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

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

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

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

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

Two cheers for the Nokia Test (2)

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

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

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

Regarding the long list...

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

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

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

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

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

I hope these are actionable comments for you.

Two cheers for the Nokia Test

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

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

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

As with almost anything, it can be misused.

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

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

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

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

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

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

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

The primacy of learning

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

What does this mean?

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

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

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

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

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

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

The team that learns the fastest wins.

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

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

Respect People

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

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

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

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

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

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

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

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

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

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

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

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

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

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

I am a coach, so perhaps I am biased.

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

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

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

* * *

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

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

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

How do I start an Agile project?

I have been teaching Agile courses for a while now.

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

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

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

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

So, what are the basic steps?

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

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

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

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

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

2. Gather a team.

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

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

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

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

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

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

5. Work on Iteration Zero.

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

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

6. Start Daily Scrums (standups).

Start them in Iteration Zero.

7. Do Sprint Planning.

8. Do daily Sprint work and Daily Scrums.

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

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

9. Do Sprint Review.

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

10. Do Retrospective.

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

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

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

* * *

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

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

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

More on this "getting started" topic later.

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

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

The Nokia Test (3): Agile Specifications

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

What does this mean?

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

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

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

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

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

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

What does this mean?

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

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

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

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

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

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

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

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

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