What is Iteration Zero?

Someone asked a very interesting question in the Agile Alliance LinkedIn group. Discussions about iteration zero have come up before, but this one was specifically focused on the situation where the architecture was not well understood.

In case you are new to Agile or Scrum, iteration zero is the term for that first sprint where you know you won't be delivering software that is adding value for the customer. It's the "let's-get-our-ducks-in-a-row-so-we-don't-bomb-the-first-sprint" sprint.

Many people use sprint zero when they transition to agile for converting their project plan into a backlog and seting up the environments needed for CI and other XP practices. Some use it to kick off a project and understand the underlying system being built on top of.

In this discussion though, it got me to thinking about a past project where we were starting from scratch. We had nothing, and we had never developed in this technology before. So, what to do?

Remember, a sprint should always have an outcome or goal. And, it should always be demonstrable! The original poster asked about unknown architecture, common impediments, and differences to non-agile projects. Here's what I contributed to the forum:

Iteration 0 should result in a compiled installable "Hello World!" system (example: user shall be able to login and logout). Common impediments are purchase, license, hardware, network, and system related.

In an ad hoc PM practice (or traditional), there would be a huge "balloon payment" (to borrow from technical debt metaphors) at the end of the project to take this built system and install it in the real world. Iteration 0 is a way of beating this problem up front and then refactoring along the way as you learn instead of having to rebuild based on the mistakes uncovered at the end during "stabilization".

What do you think?

A further experiment in ScrumBan…

I’ve recently evolved my company process to include WIP limits, but before I share this story, I must first provide the following background.

When I started at this company 2.5 years ago, there was a large divide. I was trained in PMI, was a CSM, and I was a staunch advocate of XP/Scrum by the book. On the other side of the divide, the company had little process, little documentation, no source control, and made minimal attempts to plan work a day or two in advance. One could say this was a recipe for disaster, but this is a startup… and the point of hiring me was to improve as they doubled the size of the company.

Several things have happened since then:

• retrospectives and weekly iterations were quickly adopted
• source control is now in place
• we put tools in place to manage our work (VersionOne)
• standups have become common for both teams and projects
• we’ve modified the 3 questions
• we now use a ScrumBan inspired board
• most importantly, I’ve learned that there is more to Agile than Scrum/XP… I’ve become an interested follower/borrower of Lean and Kanban practices. This is an important step for me as a coach since not all environments fit the Scrum/XP model. A mixed bag of tricks helps win the debate, especially when it is gamed against you!

So, what is the new problem of the day? I’ll call it the plan-to-budget problem. I’ve struggled for 2.5 years to find a way to get the company to plan work based on the available capacity. We’ve always had “BUT-we-need-to-do-ALL-of-it”-itis.

I’ve explained velocity and scrum, but this was viewed as too expensive to pursue. “Why should we estimate everything when we only care about certain parts of it meeting a specific deadline?” This is a good point. If only a small portion of our work is deadline driven, and the rest is “do as you can in this order”… then putting time into estimating and projecting everything might lead to waste. (Although this is contradictory to “I-want-all-of-it-by-next-month”-itis.)

Thus, I reduced focus and tried a top5 concept. Hey CEO, pick only 5 things that are important for this week, we’ll do our best with that set before touching other stuff. This worked well for a while since it forced us to admit we can’t get everything done and focused on fewer items. It reduced our “in flight” work… for a while. Two things derailed this approach.

1. The CEO found ways to assign work to people outside the top5 set (most people can’t say no to the CEO/founder when approached).
2. Not all items were the same size (scream together now: ESTIMATE!) so 1 large top5 item could clog the whole pipe.

We let go of this concept and evolved our breakdown further. I was happy to push for smaller stories and quicker closure. Appropriate sizing is a great stress reducer for the team, especially when you involve them in that process. But we slowly returned to our problem of demanding more work than we have capacity for.

This is where I started thinking about Kanban’s WIP limits. After all, this would fit our model well, and we already have the board in place. Unfortunately I knew that this would be bypassed just like the top5 limit. Our problem was a cultural problem, and I had to tackle it at the source.

So, we’ve started a new trial change in our process. After 3 hours of debate, I was able to convince management of the following (meaning they agree with these):

• Giving one person too many things at once will slow down throughput
• Swarming is a good way to get things done faster
• Saying we have to do everything doesn’t mean it will get done
• Not deciding on priority means it will get decided by the people doing the work
• Our biggest issue might be over-committing (actually, over-requesting since nobody was necessarily committing)

The solution? Headshots! I made little headshots of each team member. We plan the queue of work and then prioritize it. Then the CEO points at a card on the board and says “I want that first”. We put 1-N heads on it based on availability, capability, and size of work. The CEO keeps pointing at items until we run out of headshots. If he points at big things, he picks less stuff; if he points to small things, he can pick more (Budgeting to capacity!) When a person frees up, they move to something else on the board. Everyone on the team might have a few things assigned to them in VersionOne, but they KNOW which item is most important (the one with their head on it on the board). Everyone on the team focuses on helping each other finish these items before starting new things. All of this is clearly transparent on the board! It's not rigid like scrum velocity or Kanban column limits, but it is a place to start and a way to prove value (a door to further improvement).

Summary: We aren’t doing true scrum, but some of the pieces. We aren’t doing true Kanban or Lean, but some of the pieces. We aren’t truly self-empowered, self-managed… but somewhat. I would be the first to declare we aren’t “agile” as defined by most in the community. BUT, I’m getting to the point where I believe we have a system that works for us (2.5 years ago, we were a demand-and-control company led by the CEO). It’s a hybrid of many agile approaches, driven by my teaching of agile philosophies, allowing this company of ~70 work better together. Hopefully this new change will help us overcome our capacity/planning issues, only time will tell.

The PO is part of the team, get over it!

The other day I posted about charging a fine for being late to the standup. I knew this would get some reactions, but one thing I should have been clearer about was that this wasn't a team problem, it was a PO problem. Sure enough, several of the LinkedIn forums got fired up over it and some heavy hitters had some good points to make (thanks Rachel Davies!).

I agree that this concept can backfire (fine, I'll pay the fine so I don't have to come), and there are solutions to that (double the fine for each offense). I also agree that if the majority of people need a fine to appear at the standup, then there is a much bigger problem occurring.

So, that background aside... one of the conversations appropriately focused on the issues we were having with the Product Owner. Why didn't he want to participate? Why was this an issue?

Lesson learned on that point: when this company went agile, we trained the developers, then the QA and analysts. Following the rules of Scrum & XP, we understood the metaphor of the Chicken and Pig very well. Unfortunately by following this rule, we optimized the team but de-optimized the whole value stream. It wasn't until the PO's got some agile training that they understood how to evolve for the new agile world.

This post is in response to the following comment in regards to fining the PO for being late to the standup:

Why wait for the PO for a stand up? The PO should not be in a position to cause the problem. We try and utilize the Chicken and the Pig approach.

And my response:

There are many people who feel the PO is a member of the team: http://www.danube.com/blog/dan_rawsthorne/who_is_the_project_manager_in_scrum
Thus making them a Pig.

Also, the chicken and pig concept is dead in my mind. It's a coping mechanism for bad managers: http://www.langrsoft.com/blog/2008/08/pigs-chickens-and-asses.html

As our agile team matured, we found that many of our early retrospective discussions led back to the fact that the PO wasn't accessible enough. When your PO is the voice of many customers distributed globally, the PO is very important. If you have direct access to your customers (example: internal employees), then this might not be as important.

The last thing you need is for a team to go to the sprint review and demo lots of software that fails PO acceptance. Instead of making decisions in his absence and hoping they were right, avoid this waste and just treat him as a team member. If you can't do this, then get a proxy in place (lead analyst), or get direct access to the most important users to reduce the risk (beta customer).

Sprint backlog meets fundraising...

Sometimes I see agile in everyday interactions (see prior post about the Kindergarten Kanban board).

My son goes to a daycare in a church. The other day I was walking out with him and I saw the following (click for larger image):





















We've all seen the "thermometer" fundrasier boards where the local non-profit raises the red bar in the thermometer in the scale to entice people to raise the amount needed. What this church realized is that people will feel more invested if they actually know what the money will be spent on.

Enter the prioritized backlog on the fundraiser board. It is very clear that the group in charge is saying that the first dollars will fix the problems, the next chunks of money will think about the future, and the extra money can be spent on some nice to haves (and the remainder will be saved). It's not about raising X dollars, it is about raising the money for the individual projects.

People will feel invested to get involved. Every week they can look at the board and say "Look, we should help pitch in for that." The customers are getting immediate feedback. An expectation and accountability is being set for seeing these projects happen, because it is what people paid for!

Imagine if you could determine where your tax dollars were spent. What impact would that have on paying taxes and government funded projects?

Prioritizing your backlog and exposing it to your team and customer can be a good thing. I hope you appreciated this example as much as I did!

Help! Our estimate was off by a lot!

Another LinkedIn discussion, this time the question was along the lines of estimates that turn out to be incorrect. In this case, the person asks what the team should do when something estimated at 6 hrs turns out to actually take 26 hrs.

Wrongly estimated stories normally create more pressure on team which in turn impacts the quality, velocity and off course targets.

Is there any way to handle this issue? It is ok to pop out some stories in between sprint?

Most of the initial responses focused on the fact that estimates are always slightly wrong and that this error will normalize itself out. One person before me suggested mid-sprint correction with reflection during the retrospective. I agree that trends of estimate problems should be reviewed, but the real question was... what do I do right now in the middle of this sprint?! My response:

If you uncover something mid-sprint where your estimate will be 4x greater than originally thought, I would assume you have uncovered an impediment or complexity that was unknown during planning. This will happen from time to time, even on a mature team (otherwise you might not be doing difficult enough work!).

My advice would be to pull the product owner/customer in immediately. They need to understand the issue (and hopefully the cause). They need to decide if that story is still important to them at that cost. They may want to descope it knowing that everything else in the iteration is more important than that one thing. Or... they may tweak the requirement to get the majority of it and work around the problem.

I follow most scrum ideals, but I don't believe that a sprint's scope cannot be changed mid-iteration. (Actually, I'm doing a Kanban/Scrum blend now). It makes sense to re-evaluate when these things happen because the team has to remember that the largest goal is delivering the right business value. Delaying multiple expected items for a single item is a decision that should be left to the product owner/customer.

I'm curious to see what others add to the discussion thread. Unfortunately, I think most people are focusing on pure Scrum (ignoring other Agile flavors) and are assuming this is an immature team. I don't know if that is the case for this person or not.

When is a story too large?

Peter Steven's posted on the Agile Software Development blog today on the topic of "When is the story too big?" It's a really good article if you are on a team having trouble with that single story that deep-sixes the entire iteration.

Some of his points are:

• Past Performance is a good guide to future performance
• Stories should be small compared to the size of the sprint
• ‘How to demo’ makes the complexity clear
• Splitting Stories which are too big

On the second point he states:

My own rule of thumb is that no story should consume more than 40% of the teams estimated capacity. Why? An estimate is merely an estimate. If your team is knowledgeable in the technology and domain, each story has a nominal tolerance of +/- 50%. So 4 days could be 6 days, and you would still be in your tolerances. A six could be a nine. Assuming your capacity is 10, then committing to a 4 leaves a lot of room for error. Committing to a six exhausts your margin for error, especially if you commit to other stories. And anything bigger has a high risk of not getting completed, even if things go well.

I actually took this a step further in my comments:

I would decrease your 40% further.... I am a strong believer in MMF (minimal marketable feature) and encourage items that can be broken down smaller to be. If something can be built and marked DONE in a day, that is better. Remember, sizing allows for change in scope and priority mid-iteration if needed. Large stories block this.

Thus, my rule is around the 25% mark. If a story will consume more than a 1/4 of the resources in a sprint AND it can't be broken down further, then I call for a spike. Use the spike to R&D the riskiest parts of the story and flush out the demo/acceptance criteria. Timeboxing the spike to 10% of the sprint forces re-evaluation before creating a huge time sink (allowing time to refocus 2nd spike in the same iteration if necessary).

The outcome of this timeboxed "spike" should be a more clearly defined, lower risk, and possibly broken down set of stories. Containing the work to a timeboxed spike insures the team continues to deliver other stories in the meantime.

Also... these stories should be tackled early on in the release cycle. If you wait until the 2nd to last sprint in the release cycle, your risk will probably cause you to miss it.

A lot of people forget about risk management in agile, I believe that proper story sizing is part of the risk management that teams must be accountable for when becoming a self-empowered, self-managed agile team.

Your thoughts?

Infusing some Kanban...

The team I am working with was starting to have a few issues. We had too much on our plates, lots of noise, and the CEO was raising concerns that we weren't focused on the right things. We also had a feeling that the sprint end and begin was a magical flurry of stressful activity.

So we've implemented some changes:

• Our cards on a wall board is now restricted. Only 5 things can be in flight at a time. Everything is still in VersionOne; but only the top 5 get the explicit visibility of being important enough to be covered every single day.
• The CEO (highest level product owner) is responsible for filling and prioritizing the +5 queue whenever there is an opening. These are the next 5 things expected to move into flight.
• Our standups are no longer going to be asking the 3 questions going around the circle in the sequence we lined up around the room. Instead we are going to first talk through the top5, and then use the time remaining to discuss other notables as people need to. The team is responsible for taking their turn by importance and not going in sequence.
  

Our hope:

• This will shift focus from what "I am working on" to what "the team is delivering for the company".
• We might not get to every topic since not everyone will have an explicit turn, but we guarantee that we are talking about the right things.
• Outsiders can attend the standing meeting and easily see certain items and their status as opposed to hearing about an item across people throughout the meeting.
• We force the business to shift from magically identifying 5 things every Friday (1 week sprints) to constantly filling a pipe of work every day as we empty it.
• It is easier to see if our commitments of date and cost are at risk and communicate that to stakeholders because the topic is covered at once. (Our commitments are more safely limited to the top5.)
  

We see how it goes... (like many issues, we'll implement changes and slowly snap back to a happy medium as we learn and grow)

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!

Story Pts vs. Capacity Hrs...

I was participating in the VersionOne user forums and a question was being asked about capacity. I'm guessing the person was a scrum master or project manager and they were asking about whether they should plan their resource ideal capacity for 8 hour days or 6 hour days.

This is a question that comes up from managers a lot, but it sometimes gets confused with velocity. I've seen people thinking that sprint planning is based on understanding a teams capacity and scheduling to it. Though there is some overlap and dependency between these two concepts... here is some clarification.

Philosophically, you want to use story points and velocity to plan your sprint commitment. You want to use hours and capacity to measure how you track towards that commitment throughout the sprint. Thus, you are better planning capacity at a realistic level. If for your group that is 6 hours, then plan 6 instead of 8. Teams that do support work in addition to project work typically have a lower capacity. This will vary by team.

In other words, hours shouldn't be used to plan and commit to a sprint. Remember that estimates are faulty and full of human error. The point of story points is to normalize this error out. But, using hours throughout the sprint to track tasks and watch trends is a good way to raise red flags and work with the team. This balance is part of the magic provided by the scrum master and project manager.

This is where the old style PM asks, "what about known vacation and holiday issues?"

Yes, you obviously don't let the team commit to the same amount of story points as the last 3 sprints (your velocity) if you know they are all taking 2 days off for Thanksgiving. But a simple rounding math formula can help you figure that out. Determine the percentage of capacity lost (rounded in days) and remove that percentage from your expected velocity for the upcoming sprint. That simple approach will probably be 85% accurate or more. Any more time spent figuring it out will not improve your numbers enough to be worth the investment.

Update (11/25): Mike Cohn just posted today along these same lines.

What is sprint planning about?

There is a good discussion forming on the VersionOne google group about sprint planning. As people were starting to weigh in, I found myself writing more than a forum response... so here's my blog post about it. On my last review, I cut chunks out of this to shorten it... so there is much more to say on this subject.

The following is a description based on my last environment since it was a more mature agile team. We always treated sprint planning as a time-boxed event.
_________

A major goal of sprint planning is to make a commitment to what is intended to be delivered by the end of the sprint.

To do this, you:

• need customer/team input on what items from prior sprints need revisiting before moving forward (incomplete stories)
• need product owner/customer input on what is important to tackle next
• need estimates on these items to understand relative size (unless everything is sized the same)
  
• need an understanding of team velocity

Sometimes sprint planning will already have all these things completed (may happen throughout the sprint and during review), but if not, this should be the first focus during sprint planning.

• First bullet, assess the realities of where you are. There might be items that were rejected during sprint review for whatever reason that now need follow-up work before being marked as DONE. Also, a mature team might have a few stories started for the next sprint because they've learned how to keep their cadence and view sprint boundaries as a point of measurement instead of a true work-stop.
  
• Second bullet, have a prioritized backlog. It might shift throughout the sprint due to changing conditions from the market, the feedback from the users, or the complexities uncovered while building the software. This needs to be reviewed and updated so the team understands what is near the top of the list.
• Third bullet, perform just in time design. As items were put on the backlog, enough design should have been done to estimate them in comparison to each other and properly size them. Now the design should be discussed further to insure that anyone on the team has an idea how they would tackle the work and could see themselves taking it on (but leave the black-box details to the folks doing the work during the sprint). If you have specialized resources, then it might be possible that only those resources need to be involved in that conversation (not my personal preference).
• Fourth bullet, how much does the team normally get done? This is your velocity.
  

In an immature agile team (or one with current difficulties) this may be as far as you get during a time-boxed sprint planning session. The agile coach or scrum master can guide everyone on how it will go forward from there. Slice of the top an amount of work matching your velocity and go!

Of course this isn't optimal. So, if you were well-prepared and still have time after answering these questions... then what?

The team reviews the backlog and makes a selection of work they will target for the sprint. They should take into account things like removing risk earlier, not stumbling over each other in the code, the knowledge they have on the team, specialized resource bottlenecks, etc. This may lead the team to negotiate with the customer or product owner to skip over something at the top of the backlog for now.

This is the optimal minimum point to get to for sprint planning. A list of backlog items (stories) that the team has committed to tackling that is also acceptable to the customer / product owner. This is a set list that can be statused, monitored, and managed throughout the sprint. Because the team committed to it, there is a level of accountability that people will take responsibility for.

If you still have time in sprint planning, I've seen some groups break down the stories into tasks. If the team is mature, they can do this without knowing/caring who will do the work later (including task estimates). If not, then they might want to wait until someone picks the story up themselves. In really immature teams (technical immaturity, not necessarily agile), the architect or senior members may lay out the task work and estimates as a guide for the junior team members when they get to it. At this point, there's a lot of variance based on the team's needs, culture, skill sets, agile maturity, etc.

The bare minimum is that the team walks out of sprint planning with a commitment for sprint delivery that they can hold themselves accountable to. Explicitly this is a selection. Implicitly, this is the top group of stories that add up to their prior sprint's velocity.