Good agile stories

So what is a good story? I’ve been asked that frequently as of late.

The basic thing about a real story is that it's a metaphor for the work being done. It is not a requirement but a reminder to collaborate about the topic of the story - in other words in agile development (good agile at least), the documentation is secondary to the collaboration. So the story doesn't make you agile, it's the underlying philosophy.

A good story, from our perspective uses the invest model –
Independent – reduced dependencies = easier to plan
Negotiable – details added via collaboration
Valuable – provides value to the customer
Estimable – too big or too vague = not estimable
Small – can be done in less than a week by the team
Testable – good acceptance criteria

But a story is really driven by the acceptance criteria. In other words we try to determine how we'll know when we have satisfied the story before we put any details in it – and we mean actually enough details that we can test the story.

I'd be glad to speak with you in on the phone or via email. Part of my job as agile coach is (surprisingly) coaching agile teams.

Our stories have 3 parts, the title, the description and the acceptance criteria. The description is the only part that can be explained as a reasonable template.

Start by writing the description. It should be long enough to allow people on the team can differentiate it from other stories but short enough to fit on a 3” X 5 “ sticky card when written with a marker. Rule of thumb is that a description should be less than 10 words.

Now write the description. You can use the template below.
As a [user role] I want to [goal] so I can [reason].

Using the description, write acceptance criteria. This is the critical piece of the story. Ask the question “how will I know I’ve satisfied the goal and supported the reason” or “how will I know I’ve done that?”

I'll blog another time with examples.

Metrics Kanban versus scrum

I've analyzed my Scrum productivity and compared it to Kanban. Kanban is over three time more productive from my experience.

Agile 2009

I've just posted my second session on agile 2009. The first one - experiences in moving from scrum to kanban looks like it will be accepted. The second is a workshop on finding possible solutions to the big problems in agile management.

Agile isn’t free; it comes with new responsibilities, ways of working, and a fundamental shift in principles.Certain legacy procedures and artifacts fall outside of agile, yet interface with the project in such a way as to make the iterative nature of agile development challenging – these are the agile big rocks.

What do you think are the agile big rocks? My candidate list is:

• Performance evaluation of agile personnel – how do you motivate the team and the individual?
• Agile software development within a waterfall business – how do you do small iterations when the business wants analysis, design, code, and test?
• Agile PMO – Can the PMO track agile like a traditional project?
• Scrum failure points – Surely Scrum is not perfect. How can you recognize and avoid failure points?
• Backlog grooming pain points and resolutions.
• Agile forecasting via metrics – how do you plan when you really don’t know what you’re making?

Anything you think should be added?

Skype and Twitter as an agile communication device

I've been using Skype for quite a while now as a way to communicate in an agile environment. It's pretty good for communicating but I've also found that Skype tends to limit face to face communication. Many times I've Skyped the person right next to me or at the next table just because I'm too lazy to get up and talk or I didn't want to disturb the person when they're listening to music.

I've also found that twitter may be a way to say what you're working on but again, it can limit true collaboration. People tend to rely on the technology. It's a psychology thing - developers tend to be introverted and comfortable with technology (a generalization).

So what do we do? Hold meetings (no)? Get rid of Skype (no)? I'd suggest that we slay the dragon by specifically pointing out that the tool can be a problem for face to face collaboration. Being explicit about the problem can keep people on the striaght and narrow. Face to face collaboration is certainly the highest bandwidth for communication. When you find yourself using Skype too much - pinch yourself and vow not to do that again.

Is scrum perfect?

In answer to the above question: no, of course not. But is Scrum beyond reproach and criticism? Again I hope not. Scrum is great, and it is a great starting point for many projects that are beginning their agile journey. But Scrum is not the pantheon of perfection. It can be improved upon, particularly if one looks into the principles of lean.

Scrum is not totally lean (of course). We can look at Scrum with a few questions:

• Why do we have 2 week sprints? Isn’t that an artificial and therefore wasteful limit that batches up work?
• Why do we have 7 people on the team? Can we have less (or more) and make sure everyone is engaged appropriately?
  
• Why do we demo at the end of a sprint and not when the story is complete? Doesn’t this sound like batching work?
  
• Why do we estimate story points in an estimation session? Some of those stories we may not played because of reprioritization?
  
• Shouldn’t estimates be done ONLY by those working on a story? Having people that don’t work on the story estimate seems like a handoff situation.
  
• Why do we work on several stories during a sprint? Can we just work on one and therefore reduce inventories of work?

I believe, that by posing these questions to the Scrum process, one can improve the overall process and work toward a better Scrum.

Do Fish Burp??

I've decided to keep my blogs lighter, so here goes...

Do fish burp? I know, fish don't swallow air so they don't really burp from that, but most burping really is caused by the process of digestion - the enzymes, and bacteria in your body that give off air when digesting. I tried to google this but couldn't find the answer. Guess I'll be watching my aquarium more carefully.

Lean Software Development - Experiences

Over the next few days I'm going to post information on experiences with lean software development.

I find it surprising that people actually believe Scrum can work without Lean. LSD helps to organize the backlog, figure out what to do during the sprint, and gets the business on board.

The principles of LSD are most important. Principles drive the practice which drives the technique. Most people concentrate on the techniques, but before you look at techniques, you should ask why (and more questions). Why use these techniques, why do they work, why should I change them. Going back to the principles will guide you when the work at hand can't be boiler plated into a technique. For example if one of your principles is that honesty is the best policy, when your wife asks if her pants make her look fat, you should tell the truth - not doing so would violate your principle in favor of 'say what doesn't rock the boat'.

The LSD principles are:
Optimize the Whole
Eliminate Waste
Build Quality In
Deliver Fast
Defer Commitment
Create Knowledge
Respect People

Over the next few days I'll go into each.

My Presentations at Agile 2008

My game presentation was spectacular. The participants asked a lot of participation and a number of questions related to the game. In fact some of the people were going to use this game at Nokia. Others suggested that is would create an interesting experiment in group communications. Take away is that I’ll probably play the game in the following months.

Agile 2008

Trip report from Agile 2008
Trip Date:
August 3, 2008 through August 8, 2008 in Toronto Canada.

Overview:
The majority of the sessions were in workshop format. I.E. the instructor would lecture for the first part of the session, the tables would break into teams and work an exercise, then the instructor would debrief the teams, bringing home some of the points of the lecture. While this worked in some instances, some of the sessions provided very little new information as the exercises were necessarily simple. Most of the sessions that I attended were related to team work and personal interaction rather than technology.

Takeaways
• Other sciences have potential contributions to agile development.
• Over coaching dilutes influence.
• People matters are of primary concern in Agile development and teams must focus on problems at hand.

Agile 2008 takeaways

I attended Agile 2008 in Toronto this year - August 3, 2008 through August 8, 2008.

Toronto - not a bad city at all. Agile 2008 was a good presentation with a bit too many sessions - 500 over the course of 5 days.

The majority of the sessions were in workshop format. I.E. the instructor would lecture for the first part of the session, the tables would break into teams and work an exercise, then the instructor would debrief the teams, bringing home some of the points of the lecture. While this worked in some instances, some of the sessions provided very little new information as the exercises were necessarily simple. Most of the sessions that I attended were related to team work and personal interaction rather than technology.

Takeaways

• Other sciences have potential contributions to agile development.
• Over coaching dilutes influence.
• People matters are of primary concern in Agile development and teams must focus on problems at hand.