Agile Turkey Day...

Last year my wife decided to be ambitious and host Thanksgiving for her family at our condo. I thought this was a bad idea based on our small place and having two new kids to deal with, but I accepted responsibility to clean the condo from top to bottom so she could focus in the kitchen.

Preparation went pretty well, she even made many dishes in advance. But the one dish you have to cook on the day of the event is the turkey itself. (Well, you don't have to, but part of thanksgiving is stinking up the house with the bird.)

Unfortunately this was the day the oven thermostat broke, meaning it couldn't hold a steady temperature. We didn't realize it until the turkey should have been done and the thermometer said it was still a few hundred degrees off.

It quickly turned into a scrum process:

1. Check the bird's temp
2. Estimate a new time for when it will be done
3. Wait the the oven to work its magic
   
4. Repeat

Every time we did this, our estimate became more accurate, but the oven became worse at holding the temperature (and our constant opening and closing of the door didn't help).

Several hours late, we finally took delivery of the bird and ate our meal.

Customer feedback: That was the moistest turkey ever. Tasted awesome. Was ALMOST worth the wait.

Hope your and our Thanksgiving are going better this year. Happy Gobble Day!

Best day of week for sprint boundaries...

Chris Spagnuolo asked the Agile Linkedin group about the best day of the week to set sprint boundaries.

Some interesting points were made by the group including:

• Mondays are sometimes focused on fires and recovery from the weekend break
• Fridays are prone to people losing focus and being worn out
  
• Vacation and holidays more frequently cover Monday and Friday
• If a sprint ends badly on a Friday, people might feel pressure to work the weekend
• If a sprint ends well on Friday, then the weekend is a clean slate
• Sprint planning and review activities are a nice break from work and therefore work well on Fridays
• We can't control a lot of this anyway

Pick your poison!

Non-Functional Requirements...

If you haven't heard, there's been some buzz about non-functional requirements in both the community (InfoQ) and from the experts (Mike Cohn). I'm also seeing some activity in the Agile Alliance LinkedIn group.

Agile Risk Planning...

I'm going to oversimplify a lot of things in this post. I'm doing it for two reasons... it's not the most interesting topic, and I'm really just trying to throw out a very basic solution to what can be a very complex process. Many environments don't even do risk management, so my theory is that something light covering 60% of your needs is better than nothing at all.

What do we know about Risk Management?

Well, we are supposed to do our best to anticipate what might happen and mitigate it. The best way to do this is:

1. make a list of all the bad things that make you lose sleep (or just worry you)
   
2. assign a probability of each happening
3. assign a cost of impact if they occur
   
4. multiply all of the probabilities by all of the costs and get a total cost
5. put that money in the bank (or time padding on the project plan) to protect against it
6. constantly manage the list to your best knowledge
7. make decisions about how to spend resources to mitigate or remove risks (if you can do this for a fraction of the cost of it actually happening)

Your approach to this could be very scientific, thorough, and accurate... or you could just make some quick gut calls.

What is the agile solution I propose?

First, I believe that the amount of time needed to be invested in this process to make it very accurate is an amount of time and resources that most teams don't have. This is the same issue as estimation for stories and tasks in agile. There's a reason we do poker planning, and it think it might apply here.

1. Let's start with the basics... have the team spend a few minutes each release (every few sprints) brainstorming risks with the guidance of a PM and the PO. The PM, PO, and Scrum Master should have already pre-seeded the list to speed things up since this isn't the main focus for the team.
2. Now assume the risk will occur. Have the team estimate the impact of the risk using the same scale you estimate stories by.
3. Using poker planning, assign a probability of each happening (but use a scale of 1%, 10%, 25%, 50%, 75%).
   
4. Multiply each of the probabilities by its corresponding cost and sum for a total cost. This is your risk budget.
5. Here's where I assume you have an electronic version of your backlog (be it excel, or a tool like VersionOne). Add a story to the bottom of your backlog called Risks. Under it, create a task for each risk. Put your total risk budget as the story estimate.
6. Go.
   

Your system should include this story in any projections it makes for the burndown chart... so now you have that buffer built in to your projected product backlog. You have hedged your bets against the risk odds, and your are reasonably protected without being overly protective.

Responsibilities moving forward:

• Management is responsible for keeping this list up to date. Add/Remove risks as appropriate.
• Any work that can be done to reduce or remove items in this list at a fraction of the cost of the risk occurring should be pursued.
  
• The team should re-estimate both probability and impact cost periodically based on their updated knowledge (this supports the cone of uncertainty philosophy)

That's it... that's my poor man's soluton. Time to apply it and see if it is "just enough".

Final Note- Since I'm not as experienced in hand's on Risk Management as I could be, I welcome any ideas or feedback on this post... especially errors in my thinking. Feel free to beat me up. Most of the places I've worked, I haven't had time to focus on risk because the biggest issue is teaching people how to make and follow a plan along with communicating well as a team (hence my interest in agile).

Update (11/25): Here are two very good articles by James Shore about risk management and estimate inflation if you want to see a more in-depth look at these topics.

What is an impediment?

I use agile terminology in this blog, and sometimes I get asked what a term means. One of these words is impediment.

According to Dictionary.com:

1. obstruction; hindrance; obstacle.
2. any physical defect that impedes normal or easy speech; a speech disorder.

or

1. something immaterial that interferes with or delays action or progress [syn: hindrance]
2. any structure that makes progress difficult [syn: obstruction]

In my mind, an impediment is anything that delays a team member from working as efficiently and productively as possible.

If you are a manager and don't know better, you tell people what to do and you find an appropriate point of blame for problems.

If you are manager in an agile environment, then you should also be a leader. In this environment it is your duty to help identify, track, manage, measure, AND REMOVE impediments. Your team will reach their goals if you lead and remove impediments. They don't need to be told how to do their job.

5 minute retrospective...

Personally I view the retrospective as one of the most important parts of agile and one of the easiest first steps to implement. I find many of my peers agree with me. I've done personal retrospectives for self-improvement, and I've talked about retrospective accountability.

Peter Stevens wrote on the Agile Software Development blog about the challenge of working with a new team and introducing agile concepts. Knowing that "challenged" teams are so busy fighting fires that it's hard to interupt them even to make their sutuation better, Peter attempted to apply Ken Schwaber's idea of 5 minute retrospectives. Cue Bill Murray in "What about Bob" saying "baby steps" over and over again.

It's a good read and it furthers my belief that agile retrospectives are a agile practice gateway drug.

Don't use a germ ball...

I know about the pattern where scrum groups use a talking token during their standing meeting. It's some random object that is used to signify who is in control of the conversation. If I'm holding it, it's my turn to answer the three questions. If what I say leads to a short conversation, I am responsible for reeling it in and getting the meeting going back around the circle.

Some groups keep it interesting with random rules around the token. Last one in gets it and starts off. We go in different directions each day which is decided by the first person. We can refactor our standing sequence to change order of turn mid-meeting. Some groups pass it to someone in random order to keep everyone on their toes.

This is all good stuff, but do me a favor. Don't make it a germ ball. I've had this happen in two groups now. The token is something everyone touches. The first flu season comes around and suddenly it's the germ ball. It's the reason that everyone is sick at the same time. No amount of anti-bacterial spray can clean that stupid thing, and the talking token doesn't work if everyone is scared to touch it.

In my group, we have a squishy rubber ball. We kick it around. The downside is that it gets disgustingly dirty on the floor. We call it the dirt ball, sometimes the snot bugger ball. BUT, nobody touches it with anything other than their shoes. Nobody gets sick from it.

We even built a house for it out of a shoe box. I'm sure the cleaning crew is confused by the dirtball house with the dirtball at rest at night... but we don't get sick, so it works for us.