Agile Specification

This is a "just enough, just in time" concept.

Please read these blog posts:
http://scrum.jeffsutherland.com/2009/11/enabling-specifications-key-to-building.html 
http://scrum.jeffsutherland.com/2008/09/agile-spefiction-is-it-hoaz-or.html

OK.  So, it is something 'written' that the PO gets done for the Implementers in the team. The Implementers define exactly what they need, and the agile spec is neither more nor less than what they need.  To get it done right. Quickly. High quality. Etc.

What might it contain?

Well, anything useful.

I think it is easiest to think of conceptually if you think of 1/2 page (or 1 page or maybe 2-3 pages if the drawings are big) tied to each small sprint-sized user story.

It is simplest to think of the Agile Spec being 'written' 'one sprint ahead'.  And being checked for 'ready, ready' before the Sprint Planning Meeting.  But your real world may require some common sense adjustments to that. But be careful; common sense is remarkably uncommon.

Maybe hand-written, maybe on a wiki.  Maybe in a Word doc.

Who writes it?  Well, the best people, of course (self-organize!).

It might hold:

• the acceptance criteria
• a business flow
• a list of business rules
• a wire frame(s)
• a mock-up of the screen (if that means something different to you)
• a simple use case kind of flow (not all the darn UML use case stuff... just something, just enough) (to me, this is a variation on a business flow, using a few specific symbols)
• a data flow
• new data elements (or whatever you guys call them)
• key data elements and key values in this context
• a screen flow
• a simple design picture
• a data flow, maybe simplified
• an example (eg, if X, Y, Z inputs, then we expect A, B, C outputs)
• anything else they may find useful to build it quickly and for it to EXCITE the customer

Any one Agile Spec will NOT have all of these things.

It does not repeat the usual BS that we used to put in specs. That no one really read.

It does not say all the stuff they know well already.  It is not trying to be 'comprehensive'.

We are _not_ managing through documentation. Consider this sentence repeated 15 times, 15 different ways.

We are sharing knowledge in one effective way. It is not the only way to share knowledge, and create knowledge. Two people at a white board is still going to be used. A lot.

And we definitely use the Agile Spec as a basis for conversation, to confirm that everyone is seeing the same elephant (well, in this case, the same small sprint-sized user story).

For some people, who maybe had too much fun in college, we need to write or draw more.

For some people, who maybe took their Ginkgo today, we need to write or draw less.

Any questions?

Ozymandias: Creation birth pangs

It is hard sometimes to create. We wonder, will our darlings ever survive.  I have spoken already of a book called The Courage to Create by Rollo May.

Now I want to show a short poem by Shelley.  Ozymandias, it is called.

I met a traveller from an antique land
Who said: Two vast and trunkless legs of stone
Stand in the desart. Near them, on the sand,
Half sunk, a shattered visage lies, whose frown,
And wrinkled lip, and sneer of cold command,
Tell that its sculptor well those passions read
Which yet survive, stamped on these lifeless things,
The hand that mocked them and the heart that fed:
And on the pedestal these words appear:
"My name is Ozymandias, king of kings:
Look on my works, ye Mighty, and despair!"
Nothing beside remains. Round the decay
Of that colossal wreck, boundless and bare
The lone and level sands stretch far away.

Ozymandias was once a famous king, of surpassing wealth and power in his time. And Shelley wrote this after seeing the ruins of his kingdom.  You will note that Shelley, the great poet, was not daunted by this vision of despair.

I note with irony and pun-ishness, that in our computer world, the lone and level sands stretch far away.  (Ok, Virginia, I am alluding to how sand becomes silicon, as in Silicon Valley. The valley of dreams.)

I hope that you do not seek that fickle goddess, Power.  Or wealth (perhaps slightly less fickle, if you know a good Swiss banker).

But if we only build castles of dreams in the breasts of our friends, even those dreams, once built, can die surprisingly quickly.  A new product will come along and charm them a different way.  I am sure any of you can think quickly of an example.

We must have the courage to create, and the laughter to let that beautiful creation come crashing down. And then to create again.

I will close with this quote from Henry Ford:

I cannot discover that anyone knows enough to say definitely what is and what is not possible.

Release Planning: Effort (2)

Now we come to the point of describing Planning Poker.

(This is a continuation of a series on Release Planning that starts here.)

Planning Poker has been described before, so we will be brief.  It is described at greater length many other places.

***
Some basic characteristics:

• We find the 5 best experts on effort for this work.  (About 5; maybe 3-7.)  In almost all cases, this means the team of pigs.
• Usually the Business Stakeholders (as I call them) will not stay around for this work.  This is ok. Not ideal, but ok.  We will bring them back in later.
• We use the planning poker cards with the Fibonacci scale.
• The approach is wide-band delphi.  Delphi means we use the best experts we can find. Wide-band means that we allow the experts to talk and learn from each other.  This bears strong resemblance to the knowledge creation ideas from Takeuchi and Nonaka.

The basic technique

We have about 5 Experts.

We use (solely, mainly) the people in the team who will be building the product.  The affects motivation.  This affects their knowledge.  This will affect their later behavior. We try hard to get all of them, so that none of them feels left out.

The Product Owner is typically not one of the voters, but he/she is there. The PO has to make sure that the team is understanding each story correctly.  Typically the PO is a business person and in any case is representing the Firm and the Customers.  So, when those kinds of questions come up, he must be there to give them the best possible assumptions to work with.

The ScrumMaster (SM) is there to facilitate the meeting or the work.  Ex: To try to get the quiet ones to talk more and the talkative ones to talk less.

In this discussion, we will assume all the PBIs (Product Backlog Items) are in the User Story format, so we will call them stories.

The Experts must now choose the reference story.

Imagine that the team has 50 stories in the Product Backlog, covering about 6 months worth of work.  The Experts choose from that set the smallest story.  Well, except that it should not be too small. Ideally it is about 1 ideal person day (after adding together all the ideal hours from all the required skill sets).  [Someone should check that the story is about the right size. But don't tell anyone, and especially don't let the experts start thinking in units of time (days, hours).  Still, if the story is too big or too small, it starts to distort the voting, in my experience.]

The reference story is arbitrarily given a 1. Meaning, it has an effort value of 1 Story Point.

Note: For those who are just reading this post, an earlier post talked about how the Team must have a strong DOD (definition of done). The DOD should make clear what things are being done in the Sprint to get the story 'done, done' as we often say.  So, it is the effort of 'these things' done during the Spring that we are estimating.  Earlier we talked about a minimal DOD.

OK, now the team estimates the relative size of all the other stories in comparison to this reference story.  This happens in this way:

1. Select the (next) highest value story.
2. Discuss it briefly to assure everyone understands it the same way. PO describes story. Experts ask him questions.
3. Someone asks "any more questions?"  If no....
4. Each Expert privately selects a Planning Poker card that best represents his feeling of how much bigger the new story is in comparison to the reference story. For example, if 7 times bigger, the choice is between a 5 card or an 8 card.  Likely, the 8 card will be chosen...
5. If all Experts are within 3 consecutive cards of each other (ex: all have either a 5, 8 or 13), then average the numbers. Example: 5, 5, 5, 8, 13 .... averages to 7. The average is rounded to the nearest integer.
6. If the Experts' votes are more dispersed (ex: 3, 5, 8, 13, 20), then the two extremes talk (mostly). In this example, the person with the 3 and the person with the 20 both talk about their assumptions, etc.  If the assumptions are business-related, then the PO can decide which assumption is correct.
7. With the new information, each Expert votes privately again.
8. Voting and discussing can go on a couple of rounds.  Almost always, the final answer for a card is the average after the Experts get within 3 consecutive cards of each other (Ex: votes are 2, 3, or 5).
9. If, after X number of rounds, the Experts have not reached some degree of consensus (with 3 cards), then the team should just take the average. Each team can decide how big X should be.  My guess is 4.
10. Once the number is decided, it is written on the card (story) in such a way that everyone knows that it represents the story points (color and placement on the card usually make that clear).

A few additional comments:

• The discussion is actually the most valuable thing.  The numbers drive a better conversation about the more important stuff.
• Sometimes important assumptions are identified. In that case, the assumption should probably be recorded (eg, on the back of the card?). Later, if we discover that the assumption is incorrect, we can refactor the story points for the related stories.
• Sometimes the Experts will want to address certain general issues.  The issues might be architecture or design related. This is where the SM has to use good judgment. Typically let them discuss for 'a while' but not too long. Maybe make one or two drawings.  Make and document a few assumptions, and then get back to Planning Poker.  Sometimes one or two people on the team want to discuss these issues too long. In this case, the SM must use good judgement and get the Experts back to Planning Poker.
• You will  hear of people suggesting that the Experts must agree on 1 Fibonacci number (eg, 8) for a given story.  This is _not_ recommended.  First, it gives a strong incentive for people to too quickly start to shade their numbers, rather than vote what they really think.  They find that George, the senior guy, is stubborn, and to avoid conflict and to keep things going, they decide, almost subconsciously, to start voting a closely to what George says as fast as they can.  The research shows that the average is more likely to be the correct estimate. And it actually takes less time to reach that number (if everyone is voting honestly).
• Usually one or two new stories are identified while we are doing planning poker. This is normal. Occasionally it turns out to be the most important story.

At the end

It usually takes no more than 1.5 hours to estimate 50 cards well.  The first few cards take longer. Then things speed up. On average; sometimes one or two later cards will take some time.

Once all the cards have been estimated (for effort), all the cards should be put on the wall. And then the whole Team should gather around. And see if they can identify one or two 'stupid' cards.

It is very common that 2 or 3 stories that were estimated early on will need to be re-estimated, in the team's opinion.  This is fine, good even.  And normal.  They now, as a team, are much smarter than when they started Planning Poker.

Cost-benefit analysis

Now one or two people in the team calculate the R ratio for each story.  BVP divided by SP.  For each story.  The R should not be more than one decimal place.  This gives:

• the low hanging fruit
• the bang for the buck
• the return on investment

...however you want to put it.

We next suggest that the PO organize the story cards based on the R number. Highest R first.  Lowest R last.

We ask them: What do you think?  Is this the right way to do the work?  Often they say: Well, it is a good start but we need to make some changes.  Which is 99% of the time, the right answer in my opinion.

What ideas do we use to re-order the work?  More on that in a post soon.

The importance of a real team

Scrum requires a real team.

The word 'team' is often used, often in different ways.  So, let us define it.

According to "The Discipline of Teams" by Katzenbach and Smith, this is what you should look for:

1. A meaningful common purpose that the Team has helped shape.

2. Specific performance goals that flow from the common purpose.

3. A mix of complementary skills. Including technical/functional, decision-making, and interpersonal.

4. A strong commitment to how the work is done.

5. Mutual accountability.

For more discussion, see The Discipline of Teams.

The team needs to be small (~7), stable, cross-functional, and self-organizing.  The team is in it together.  And should help each other.

In general it is best if the team is fully dedicated to one missson, one purpose, or at least the one team's goals.

All of these team characteristics together are key to starting Scrum.  Got to start with a real Team.

Note: Not everyone wants to be on a Team.  And for sure, not everyone walks into the office knowing how to act in a real Team.

Meet the Meeting Killers

Here is an entertaining article in the WSJ.  About people "types" that kill meetings.

Scrum of course has some meetings. It is trying to minimize meetings, and make meetings better.

But as soon as you have people and meetings, you can have some....umm...interesting times.  So, may your meetings not be interesting this way. 

What to do with managers?

First, unlike some in the agile community, I think managers can and should be useful in lean-agile-scrum.

Still, there is a lot of evidence, on many levels for two propositions:
1. Some managers can be very detrimental to a lean-agile-scrum implementation.
2. Many managers have not been well trained in how to manage. In fact, what they have been taught seems to be, to a large degree, the wrong stuff. (At least, it seems, in the US.  In other countries, this may be better.)

So, we agile advocates have a long way to go to get all of management 'fixed'.  I mean both middle and senior managers now. (Yes, the solution for the middle managers might be somewhat different than the solution for the senior managers.)  On the right page with the right attitudes and practices that are consistent with lean-agile-scrum.

So, a few quick ideas on how to fix this:

1. Check out the "Stoos" group. A few are a bit too radical for my taste, but that group is working on 'management'.  They have useful ideas on this problem.

2. Respect change. It is hard. It does happen. You cannot always make it happen, especially on your own schedule. But sometimes, either before or after you want, people will change. And even in the direction you want, due (partly) to the efforts you made.   ...Do not let yourself get depressed, do not give up.

3. Respect the people you are trying to change, and that, at least in some ways, their concerns are legitimate.  At least from where they are coming from, there is typically some internal logic to the way they think.  ... I find this is hard, because I can so palpably feel the damage these people are doing. It feels like they are trying to be evil sometimes.  Certainly stupid. And I grow impatient.  But mostly there are not (evil); they are usually trying to do they best they know how.

4. Look (again) at the standard change books. Kotter's books. Fearless Change by Manns and Rising. Others (if you prefer). Many great ideas about getting people to change.  Most of the following are discussed well and at length in these books.

5. Make the case. Repeat it often.  It starts with a Sense of Urgency. 

6. A sense of urgency, to me, starts with one person having a passion that, dammit, things have to get better. And conveying that passion. Maybe in a quiet way. Certainly in a respectful way. But in more an emotional way than a 'numbers' way. Although numbers usually need to be in there as well.

7. Use some experiences. Maybe from articles. Maybe from nearby firms. Maybe from your own firm. Data of one sort or another.  There are tons and tons of great articles about lean-agile-scrum now.

8. Five books for managers.
Toyota Production System by Taiichi Ohno.
Radical Management by Stephen Denning.
The Power of Scrum by Jeff Sutherland et al.
Software in 30 Days by Schwaber and Sutherland
Drive by Daniel Pink.

9. Motivation. Often the key, I think, is they misunderstand motivation. Particularly motivation for knowledge workers. This is why I think Daniel Pink's book is so useful.

***
Please comment here. I think this is a hard problem. If we knew the answer well, this problem would be a lot better now.  So please suggest better things.

We are also discussing this topic in the Agile Business yahoo group. Please join us.

Why our CSM (Scrum) course + Workshop is unique.

We believe our CSM (Scrum) course plus Workshop is unique.  And better.  For the following reasons.

1. We focus on results. We want you, your team and your customers to get real results. In a big way.  In 3 words, more satisfaction, more money, more fun.

2. Therefore the teaching style is not toward remembering explicit knowledge.  The teaching style is to enable you to change your own mind, so that you want to take action.

3. We focus more on 'why' each Scrum practice is done.  We think that this 'music' makes the dance steps of Scrum more powerful, more effective.

4. We have learned from 8 co-trainings with Jeff Sutherland.

5. We are more business-oriented than most Scrum trainers.  And still protective of the Team being asked to do a Death March and yet call it Scrum.

5. While we offer some serious challenges, and ask you to challenge yourselves and your company to truly achieve the results you deserve, we are also realistic.  We appreciate that Scrum will be tough. We offer sympathy.  But not too much.

6. Attendees say the Workshop converts the ideas of the course into action. So that the Team can get off to a good start. 

We know a bunch of great CSTs. It is unlikely that our trainings are unique in every one of these ways.  We know that one trainer or another does, we think, every single one of these things. But in the combination of them, no doubt we are unique.

Killing Babies or Sizzling Steak

I thought I would share this story, with one or two key metaphors.  Perhaps useful to you.  I use them in classes quite a bit.

***
OK, the PO is trying to optimize on the Pareto idea (80-20, the vital few).

At the beginning of the project, the team looks at the release plan and says: "OMG, if we try to get all that done by Aug 15th, we'll die!"  So the PO, realizing that even more (new) work will be identified later, gathers the business stakeholders for a meeting.

"Guys [speaking to the business stakeholders], we have to cancel from the release the bottom 30% of the stories. We just won't get them done, or at least can't guarantee them by that date. And we know new stories will be identified by then. I need your agreement they won't be in the Aug 15th release."

They look at him in disbelief.  And then the BSHs (business stakeholders) get upset.

"What the...! You haven't even started work!  I fought and fought with my team to exclude other stuff and I fought to get those babies in the Release. And now, before you even started, you want to kill my babies!"

Suffice to say, it is not a fun conversation and they don't want to agree.

Now, I do think the PO should make them aware that getting all stories done will be a big challenge. And if the PO can show a true Pareto curve, it is a much better conversation.  But don't try to get them to agree at this point. Too much pain, too little gain.

***

Now, imagine later. You have built two Sprints of the top stuff. You serve it up very seductively in the demo. You can see the top BSH drooling.

You say: "George, do we have all the top stuff built for you?"

"Well, I need story 23 and 47 too. But yes, this stuff is all the top stuff. And it looks good. I mean, aside from those missing stories, it looks...give me a second to wipe my mouth...it looks r e a l good."

"After the next sprint, when we complete some other stories and stories 23 and 47...  George, how about we then serve you up some of this sizzling steak, fresh-off-the-grill? We give you a release then?"

"Well, how about the broccoli and the mashed potatoes and the creme brulee?"

"Yes, we can give you those later, in later releases.  And how about we release you the sizzling steak _now_ (well, next sprint)?"

Now it becomes George, and not you, who gives the other BSHs the look... "guys, I think this is the best for the firm... I need you to TOFTT and let us do this release now... you'll get your stuff real soon." 

And he looks at Mary (the 2nd BSH): "Mary, we already have a bunch of your stuff in there too. What do you think?"

Mary: "Well, it does not have everything our group needs, but, yes, I think we could make use of what'll be there by the next Sprint. Are we really gonna get the later releases?"

Geo: "I think so. Heck, they never had this much working software before by this time.  I think we can trust those SOBs now.  Sorry, Mr PO, I meant SOB in the nice-est way."

Mary: "OK. How about the rest of you guys?"  ....

***

So, you can see that it is a totally different conversation. But with the same effect. That we execute and release more on the Pareto idea than on the 100% - 100% rule (where we often die in the death march).

And all because we served up the sizzling steak seductively.  We did not win on logic, but on the emotion of the drool.

Now, serving it up seductively is a fine art.  Seduction.  Well, there is Joe the geeky PO and then there is Casanova or Mata Hari. (Ok, yes, an exaggerated comparison...)  Do I need to ask which one is going to serve up the sizzling steak more seductively?  Thought not.

Now, one of the key benefits of the 'sizzling steak' technique is that the Team now has a better life (no death march, seen to be victors). Which means they are more creative. Which means everything should be better.

***
The story and the metaphors work for me. YMMV.
It does help if the key person is not a vegetarian. And even likes steak. 

Later, they will say "Oh, yeah, I liked the story about the sizzling babies." And then they will laugh.  But they might remember it longer.

Release Planning: Product Roadmap

I did a session today at the Atlanta Scrum Gathering about 'Joe's Approach to Release Planning'.  Jason Tanner asked "what about the product roadmap?"  And his question made me realize that I have not said enough about that.

My quick thoughts.

1. You need a product roadmap. For almost all products. Well, at least almost all the products I have worked with over 20+ years.  I suppose I am not an expert on iPhone Apps, for example. Maybe they are an exception.

2. What time span should the product roadmap cover?  Yikes. This is a hard question with no perfect answer.  Longer than the implementers want to think about and shorter than the 'planner' type wants.  OK?  For most products, about 1 year.  For fast changing, fast delivery products, less than one year, maybe even only 3 months (assuming say monthly releases).  For 'big' products, you might need multiple years.

3. The purpose of the product roadmap is not to be right. But to generate useful thinking about 'longer term stuff', and provide some context for shorter-term thinking. This is still adaptive planning, of course.

4. YAGNI.  First, You Ain't Gonna Need It (YAGNI) has proven to be a pretty good principle.  Stuff happens, things change (for good and bad) and most of the knowledge created to go down path A is now useless.  This principle always tilts things towards less investment in longer term planning.  But of course, this principle is not the whole story.

5. Purpose: Human beings seem to be more motivated, seem to enjoy life more if they feel there is a purpose to their lives. And a product roadmap is an example of something that can and should be used to put things in the context of purpose. "We are building the iPad1 as a step toward the iPad4."

6. Identify hard-to-reverse decisions.  Many decisions or actions are easy to reverse. Some are quite hard.  The harder a decision is to reverse, the more costly, the more it is worth some time to think about it and decide with a higher chance of being right.  A product roadmap can help us identify those kinds of decisions, and put them in a context.  For example, help us understand when those decisions must be made.  What I am saying here is very similar to the Poppendiecks' 'decide at the last responsible moment' concept.

7. Practical. For a team just starting Scrum with a fairly normal product, if the group seems ok with it, I like to plan about 6 months worth of work (typically one or two releases, at least as initially conceived). And stop there for now. And start Sprinting.  And then later build out the rest of the product roadmap.

Why? Because they don't really understand the power of agile and agile adaptive planning until they do Sprints. And until they do the Release Plan Refactoring.   It's a think-do feedback loop. They need to experience the "do" part sooner.  Then, having that tacit understanding, they start to plan better with less BS. And with more purpose.

***
Comments?

John Kotter Explains the 8 Steps to Create Successful Change

Here is a slide show and voice over by John Kotter (our big expert on change) talking about how to get organizations to change.  Watch and listen here.  About 7 minutes.

Of course, your organization is smarter about change than John Kotter, so your colleagues do not need to see this.  (smile...I might have been sarcastic.)

In fact, my premise is that no organization is professional about introducing 'different' changes within the organization.  (Example: I don't know Apple well.  I am impressed by how much their products have changed things. But I am far less confident about how well Apple itself has changed internally. Still, maybe they are the exception that proves my point. As a small example so far, they seemed to have adapted well to the new leader. Oh yeah, Tim Cook is his name.)

Taking Ideas on a Test Drive

I am a strong proponent of "show me the money."

In other words, there are lots and lots of ideas that sound good. And only a relative few that are really worthwhile. And we only know by trying to put the idea into action.

But even this basic scientific idea is not complete. I would agree that not all ideas are subject to proof in a scientific way. Even though scientifically it might be proven that murder were 'correct', morally I still am going to think true murder is wrong.  (No, Virginia, we are not going to have a debate on all the possible situation and moral permutations of killing a person.)

Here is a WSJ article about a new book, Uncontrolled by Jim Manzi.  Haven't bough the book yet, but the article makes it sound interesting.

And this is what lean-agile-scrum does. We try to do a series of small semi-controlled experiments.  To see if we are really on the right course.

If you have a problem reaching the WSJ article, contact me and perhaps I can send it to you.

Release Planning: Effort (1)

Now we move on to Effort in Release Planning.

For those who have not been reading before, this is a continuation of a series that starts here.

***
Estimating the effort of a Release Plan is not quite what I wanted to do in this part.  What I want to do is estimate the relative effort of each User Story that we have so far.

So, imagine that we have 50 user stories representing roughly (per gut check) about 6 months worth. Ballpark.

Now we have to do two things:
* Establish a Definition of Done for the Team.
* Do Planning Poker, which estimates a "story point" number for each user story.

Definition of Done 

Stealing from Taiichi Ohno, I suggest we do this differently than I see many people do.

What others do is a list that describes what 'done, done' means once we get there.

Maybe they say:
* Coded
* United Tested
* Basic documentation written and reviewed
* Functionally tested
* Small regression test
* No bugs (all identified bugs fixed)
* Product Owner Review (any issues fixed)
* No increased technical debt
* Promoted to the QA2 Server

What I would prefer is greater clarity how we got to this state. Or even if we really can get to this state.

What Taiichi Ohno proposed is that we ask the workers to write down the process that they currently use.

Once the workers do that, they themselves can see that it has weaknesses. And once the process is (more) visible, then everyone can help improve it. But especially the workers themselves will improve it. And so, they start to 'own' the process.  Which makes for better motivation. And better results.

Some in agile are concerned. Their concern is that, by writing down the process, we have locked the process in stone. And have made people into machines.

And this is actually the opposite of what we are doing.  We are making the process visible so that it can be improved.  So that it can be changed.  NOT so it will remain the same.  Now, by making the process visible, we do enable anyone who sees the process to open his mouth. And if the Team is not strong enough, then a 'bad' manager could try to force them into his process. But this seems unduly negative in the general case.
 
Let's make our suggestion more concrete.

[Insert picture of sample DOD.]

So, before or during the Sprint Planning Meeting, the team can do many things to 'get the stories ready, ready'. But what we want to estimate in story points are the things that happen during the Sprint.

We recommend that the first thing done in the Sprint is that we have a conversation about Story 1. The conversation, in classic form, is between the PO, the Coder, and the Tester. (Technically, with all the people with all the skill sets to get that story done, done.)  In this (short) conversation, all 3 people try to assure they are on the same page about the story.

Then we list everything that the Team says it can and will do to get Story 1 to a done in the Sprint.

In my opinion, the last step (or near the last) must be PO Review, meaning that the PO looks at the working product and gives feedback. If the PO feels the customer will not like it, he gives that feedback and the implementers must fix it. In the Sprint, in my opinion.

And anything done after the Sprint to make that story into something that can go in the live production product, all that work is listed as well. Below the line. And it represents, in my opinion, all the bad news getting better with age. But we have to accept that we can't always get to "live, in production, in use by the customer" within the Sprint.

We think this approach to DOD gives much more clarity or transparency.

And starts the Team on the road to becoming more professional. And enables the Team to improve their own process.

***
In the next post, we will go into Planning Poker.

A list summarizing Scrum

 Revised May 6, 2012.

***
The list below is not self-explanatory, but it covers the key ideas one has to know and execute on to do Scrum professionally.  Of course, becoming proficient at doing them at the highest level (at the rugby World Cup level) is a lifetime's work.  Rugby is a simple game with simple rules, but to reach the highest level of play is very difficult.

This list could be used as a starting point for defining 'agile' or 'scrum' in your firm. I am suggesting such a definition could drive useful conversations.  And it fits on one page (a key criterion).

A list that summarizes what Scrum is:

Roles:
Product Owner
ScrumMaster
Implementor ('Dev Team' role)

Events:
Sprint - 4 weeks or less.
Sprint Planning Meeting
Daily Scrum
Sprint Review
Sprint Retrospective

Scrum Artifacts:
Product Backlog
Product Backlog Items
Sprint Backlog
Working Product
Increment (of working product)
[Sprint Burndown chart]
[Release Burndown chart]
Definition of Done
[Public Impediment List]

Key Ideas:
Scrum is a process framework
Deliver business value faster
The Product Owner is maximizing the value delivered by the Team
Inspect & Adapt
Transparency
Self-organizing
7 plus/minus 2
Build iteratively and incrementally
Working product at the end of each Sprint
Potentially shippable product increment
Need for feedback
Always learning
Always adapting to good and bad change
Usefulness of high quality
Scrum hates technical debt
Knowing work remaining in a Sprint (daily)
Knowing work remaining in a Release (every Sprint)
Protecting the implementers from disruptions
Protecting the implementers from the Death March
The ScrumMaster drives the removal of impediments
Must add other practices (e.g., engineering practices) to Scrum to do work
Scrum does not include agile release planning (but you probably need it)
Scrum is consistent with the Agile Manifesto and Agile Principles
The Team should be having more fun (and be more creative)
Sprint Planning Meeting, parts 1 & 2.
The Product Owner orders the work in the PB; the implementers decide how much they can do in a Sprint.
Sprint Goal
Sprint "commitment"
The 3 Daily Scrum questions
Purpose of Daily Scrum: self-management
Demo working product & get feedback
Servant leadership
Chickens can help
Just-enough, just-in-time, documentation


***

Your comments please.

Here is the file: http://agileconsortium.pbworks.com/w/page/53405031/List%20summarizing%20Scrum

Agile's broad adoption and mediocrity - what to do

Ken Judy has an excellent, although blunt, blog post here:
http://judykat.com/ken-judy/agilescrumlean-broad-adoption-mediocrity-faul/

His main point maybe is that we do not have enough truly professional scrum (or agile) implementations.

And why? Because we have implemented too broadly too fast.  Is probably the main reason, in his opinion.

Some good insights.  Read them.

***

Here are my related thoughts.

The potential of a team using Scrum is enormous. And I don't think any team, ever, reaches their full potential.  In any sport, including what we call Scrum.

It is fair to say that most teams barely scratch the surface of their potential.  They get a 20% improvement when they could easily have gotten 100%.  And eventually get 5x - 10x.

Why?  Some root causes...

1. Reliance on "Scrum": Too many teams have a 'sit back' attitude and expect Scrum magically to do all the work. And it is amazing what Scrum alone can do.  But it really takes an active, purposeful, spirited team to get real success.

2. Better Product Owner. Scrum will not magically make George (a really smart guy in your firm) a good product owner.  In fact, all Scrum does is make us assign him that title, and then gives us lots of ways to observe, if we will, that he sucks at the job. Hopefully, someone sees the problem and fixes it.  It really really helps to have a really really good PO.

3. No real Team. The people don't feel they are a real Team. And no one knows how to form a real team. (Lots of explicit and tacit knowledge in doing that.  We will talk about that later.)

4. Not attacking impediments. One of the most powerful things in Scrum is that single-piece flow of attacking one impediment at a time.  The Scrum team is not aggressive enough in doing this. Or the company does not support it meaningfully.

5. Better Engineering Practices. When switching to agile, a team needs to move to more agile engineering practices. No, not for the silly reason that agile is in the name. Because the agile engineering practices are more effective. Probably more effective even if doing waterfall, but certainly when doing agile. SCM, automated build, CI, automated UT, automated functional tests, faster regression testing, etc, etc.

6. Scrum-Butt and Unprofessional Scrum.  Do you think the NY Giants should have fired all their coaches in Sept 2011?  Me neither.  Yet, somehow, many people magically expect that all a team needs is one 2-day course, and then they can play Scrum professionally.  Remember that at the beginning of September, every player on the Giants team has been playing football for years. At what you and I would call a professional level (college is virtually professional in many way). They are not beginners in the sport, and they need further coaching. Further training.

And we think people who are beginners at Scrum need only a 2 day course?  C'mon. They need a lot more. Now, of course it has to be reasonable compared to the value. If you need help with that math, I can help.

Related, but a bit different, is how beginners (or beginning firms) are so sure they are smarter than the Scrum community, which now has many centuries of experience with Scrum.  So, they change Scrum ('we are special,' they sometimes say). They do Scrum, but people on more than one team. They do Scrum, but they do the Daily Scrum twice a week. They do Scrum, but they don't have working software at the end of every Sprint.  Etc. Etc.

***
There are other reasons.  Many more.

We need more teams playing Scrum professionally, and showing others how it really ought to be done.
 

Six Myths of Product Development

Here is an article about: Six Myths of Product Development.  By Stafan Thomke and Donald Reinertsen.

Here are the fallacies in one list:

1. High utilization of resources will improve performance.
2. Processing the work in large batches improves he economics of the process.
3. Our plan is great; we just need to stick to it.
4. The sooner the project is started, the sooner it will be finished.
5. The more features we put into a product, the more customers will like it.
6. We will be more successful if we get it right the first time.

Recommended.  Read the article.