The team is too fast, what to do?

During a recent conversation in a LinkedIn group, the following question came up:

Assuming you are maintaining a high velocity but your customer isn't keeping the pace with the team in-terms of feedback and freezing the stories. what do you do? Do you decrease your velocity or keep the pace and develop things based on your assumptions?

My response:

Talk to your customer. If they are happy with the pace, then you could downsize the team to match the customer velocity and use those resources elsewhere.

If they would love to go faster, then work with them. Learn how to help them be a better customer, or immerse some of your team in the activities of the customer (slowing your team down and speeding them up).

View the customer as being part of the team, at least until you can solve the problem.

The goal is not to develop stuff fast... the goal is to deliver the right stuff fast. (therefore developing things based on assumptions won't help).

Another thing you can do with that "extra time" is reduce technical debt, train the team on new stuff, refactor code, and improve things like performance and installability.

Your thoughts?

Good Enough Metrics...

Another post triggered by my interaction with other customers using VersionOne. We were discussing story points, velocity, capacity, and other metrics. Here's what Tom said when he was trying to figure out team capacity each sprint:

As an example some of our teams state the base capacity of every team member (assuming a 2 week sprint) is 10 days * 6 hours a day. The 6 hours rather than 8 is to account for emails, minor interrupts like unplanned meetings etc. Then they reduce capacity based on company mandated holidays (we are global so ever office is different), then they reduce hours for the sprint meetings. this becomes the max anyone on a team can contribute to a sprint. The team members may additionally subtract off vacation time, or other meetings they are required to attend, trainings, etc. it would be nice if a team can define a default formula based on known factors, and team memebrs have an additional ability to have thier own formula that can further adjust thier own availabilites beyond that, or even just override it with a typed in value.

Wow! This sounds like a lot of work! Does this additional planning accuracy actually provide a similar level of accuracy predicting the outcome? I'm guessing it doesn't. When we transition to agile, over time we slowly learn to trust what our agile coaches / education told us up front. Here was my response:

This is great and I remember going through this myself. I had excel spreadsheets in the back of my sprint backlog where I could enter holiday and other data to get this value.

What we found over time was that it became somewhat unnecessary as your velocity and team matures. We slowly transitioned to story points and relying on them to do sprint planning. We picked our stories and blew out the tasks for them only when the story was picked up (mid-sprint we swarmed on open stories and closed them every day instead of running them all in parallel). We did just in time task planning and estimation (more efficient).

This led to us no longer needing all those calculations. Holidays and vacations were a simple head calculation (example: typically we do 20pts per 10 day sprint with 10 people = ~.2pts/person/day, we have 5 people taking 1 day of vacation = ~1pt... so plan 19 pts this sprint.)

It's an interesting problem to solve in the short term, but I'm guessing every team will have a slightly unique view on the calculation... and I'm guessing most people will outgrow this need over 6 months to 1 year.

I'm a strong believer that conversations of planning and capacity should focus on days and story points, not hours and tasks. Without getting into the debate that estimation isn't needed at all (that's another discussion), what are your thoughts?

Gaming the System: Velocity...

To take my previous point further (prior post), Alex Hamer wrote an interesting post about how his management wanted him to "find ways to improve velocity". He correctly considers things like training and coaching, but is concerned that management isn't thinking down the same lines and is "approaching with caution."

I've seen this management request before. Typically it comes from the frustrated Product Owner who projects the current velocity against his "desired release scope" and is frightened by promises he has made to customers. He understands the new system and velocity, and decides to use the "whole team" concept to suddenly include you in the problem. Next thing you know, he's standing over the team asking for "more velocity!".

Feels like the old way of working again, doesn't it? Agile doesn't solve the problems you felt under waterfall, it simply exposes them in a big ugly way. You can either cave and play the old games, or you can hold your ground and help management become agile with you.

Here's my sarcastic advice to Alex:

Your gut is telling you the right thing... you don't forcefully "increase velocity", you have to help your team get what they need and it will increase on its own over time.

The easiest solution is to start accounting for the velocity of vacations and conferences or training. These are guaranteed points and therefore will drive up the average. After a few sprints of the higher number... disclose that you've gamed the system. Then drive home that forcing metrics only forces gaming of the system. Remind them that this is why waterfall fails in most environments. They are only pushing you to go back to the old way of doing things under a new name.

Help your project sponsor become agile!

Gaming the System: Sustainable Pace...

Awhile ago, Bruce Zhang raised an interesting debate about sustainable pace as tied to the number of hours a team member worked each week. He closes with the statement that it is more important to remove waste than increase work hours, and work hours are not the appropriate metric for measuring sustainable pace. (His post was inspired by another old article on InfoQ.)

I know the debate is an old topic, but related to my next post I have to weigh in.

As I understand it, the 40 hour work week is a result of the U.S. government studying Henry Ford’s assembly line factories. Ford discovered that each individual is slightly different, but the “average” manual labor worker produces the most (with quality) somewhere between 35-45 hours. This is a human limitation.

One could argue that time has passed and we are more (or less) capable due to technology. One can also argue that this would be a different set of hours for mental labor (white collar) instead of physical.

One thing I have noticed is that as Agile teams mature and truly adopt practices such as pairing and TDD, they tend to be more productive around 35 hours (as opposed to 40). I worked on a team that produced A LOT more than pre-agile, and they went from lots of overtime to normal weeks. They were burnt out by Friday at 3-4pm. They needed a good weekend of recovery to come in ready to go on Monday.

Can anyone verify the 40 hr week, Henry Ford point I believe I heard before?

Create a Proper Estimate Scale...

Tuesday I pointed at Jim Schiel's article about using an abstracted story point scale instead of calendar time (days/hours) for estimation. This morning I read a new article by one of his colleague's at Danube about their issues with their current internal estimation scale.

So, the question is, how DO you come up with a good abstract scale? Here are the main points I believe you need to address when attacking this discussion -

• Atomic unit of measure - the unit of measure needs to be atomic. This means that a value of 2 needs to be 2 times bigger than the value of one. A ten is 10 times bigger than the value of one. Why? so that when you know your team's velocity equals 10 and you select a 1,2,3 and 5 point story for a sprint, you know they actually add up to a sum velocity of 10.
  
• Restrict allowable numeric selections - don't allow just any old number to be assigned to a story. Poker planning estimation decks can't contain every number between zero and one thousand, and you don't want it to. Human brains are very bad at estimating. The larger the estimate, the larger the error. It is easy to state that something will take 1 minute to do... it is very hard to state with confidence whether something will take 60 minutes vs. 62 minutes. The higher your number, the wider the gap between confident values. Most teams use a doubling sequence (1,2,4,8...) or a Fibonacci sequence (1,2,3,5,8,13...). When estimating, you are not allowed to pick a number that doesn't exist in the sequence. Why? it is a waste of time to watch your team bicker over the 12 vs. 13 estimate value on a story when their estimation error is larger than the delta between the two sides of the debate.
  
• Create non-numeric selections - not all estimates can be covered by a value on your scale. Most poker planning decks include a few others. Examples: Question Mark (I don't understand enough to estimate with confidence), Infinity (I understand but it will take longer than we will ever have), Coffee cup (If I don't get a bio. break first, then my estimate will be whatever you want it to be), Zero (it can be done quicker than it will take to have this conversation). Why? This facilitates the conversations that planning and estimation need to flush out. Remember that estimation is not just about predicting, but also about understanding and committing.
• Pick a reinforcing name - pick a metaphor that will invoke interest and understanding. Many people call them points, but some use more interesting terms. Examples: headaches (bigger is bad), donuts (reward I'll get for delivering), dings (times I hit a bell when I deploy), dukets, dolla, goats, bricks, cans of jolt, etc. Why? It not only engages a team, but can put focus on a positive (or negative) part of the process that needs to be used as motivation.
  
• Allow adaptability - remember, this is an abstract scale. It can be adjusted. If after two weeks you find yourself using decimals because you need units under one... then shift your scale. I've done this twice and found two good options. Add a zero (multiply by 10) so that people don't lose reference to the old scale and can transition with ease, or make up a new scale and spend an hour quickly re-estimating the whole backlog. Why? When people have to think about what a value means, then they are losing their ability to do comparative estimation.
  

Feel free to add your comments about other concerns that need to be covered.

Note: If you are interested in other posts about why to use story points, I've also posted about it myself here and here.

Don't abuse the metrics...

Tim Ross blogged about his concerns on burndowns. He offers some interesting points on how they can hurt including:

1. too much pressure early on
2. it doesn't handle the unplanned
3. it is unforgiving
4. PM's and customers misread it
5. it discourages refactoring
6. it focuses on a predetermined time

Hmm.... my responses:

1. really? most people feel it at the end
2. it is a reminder of the reality of the clock
3. neither is the market, it is changing whether you deliver or not
4. well... yes, that's true with any data point
   
5. not if you refactor constantly
6. or you could say it focuses on meeting a completion of commitment
   

Okay... some of that is me playing devil's advocate. I can relate to some of the points that Tim makes. Unfortunately, he proposes a solution where teams focus on the task board and maybe even hide the burndown for only the manager's eyes.

Umm... no. If you are really interested in going agile, then you have to understand that there is a power shift from the managers to the team. Instead of having people above (who aren't doing the work) ask for ridiculous things and make useless statements, the team is now more in charge of the process. But, the idea of a self-empowered, self-managed team is that the team has to be willing to be accountable for the work. This is not just the validation and quality of that work, but also the predictability of its timely delivery.

My view on this matter is two-fold:

• The burndown is an indicator. Bad trends in burndowns should be a flag for resetting expectations. When expectations are adjusted (be it the developers, customers, or managers), then everyone should know about it (that is why we do sprint planning and sprint review together, right?).
• ANY METRIC can be abused. If your culture stinks, or there isn't a trusting relationship between the team and the customer or managers... then any metric can be abused to support finger pointing. This is not specific to the burndown.
  

This is why many waterfall projects fail. It takes so long to uncover problems that when they are realized by lower management, they can delay the discovery further by gaming the metrics and reports to protect their jobs as long as possible.

"My definition [of agile] is that you accept input from reality, and you respond to it" - Kent Beck

A burndown is one of many measurements of reality! Unfortunately I think the answer in this situation is that the group needs to improve the cultural issues instead of throwing out the burndown.

Snake on the wall!

We found ourselves in a retrospective and there was a general feeling that there were a lot of interruptions in our day caused by "other people" outside the team. Nobody could put their finger on it and everyone had different unique examples. We couldn't easily say if we handle this problem or group of people then it will stop.

So how do you handle this?

Invoke the Snake on the Wall!

Every time a team member feels as though a task they are responsible for is delayed, they write it down on a post-it note. The note includes the time lost (compared to if they didn't have the delay), the thing affected, the cause, and their initials. They take the note and add it to the "end of the snake" which is a growing row of notes on the wall.

Over time the snake is monitored for repetitive patterns. The issues consuming the most productivity time are prioritized to the top of the list for the manager, scrum master, and team to focus on reducing or removing. Scrum masters look at it daily, managers look at it weekly (or when it grows suddenly), and the team reviews it right before retrospectives to trigger new topics. When an item is solved, those related stickies are removed from the snake and it is collapsed back down (you can't let it grow infinitely, otherwise you demoralize the team).

What does this accomplish?

• it validates real issues
  
• it kills false beliefs and misdirected complaints
  
• it quantifies the impact of impediments
• it creates transparency for managers who don't believe what you say
  
• it empowers the team
• it is immediate
• it self-prioritizes
• it uncovers surprises

On my last team we quantified for upper management how much time was lost EVERY DAY due to a bad source control system we were forced to use. It also provided insight into things we would never have thought were a problem. If used properly, it does a good job of quantifying the ongoing costs of certain types of technical debt.

So, I'm trying it a second time with my new group. We'll see how it goes.

Sustainable pace...

I ran across this from another site. It's about productivity and overtime. It wasn't intended to be agile focused (actually, if you are truly agile, then this isn't relevant), but it's good ammunition for an agile team when arguing with management about sustainable pace.

Enjoy!

Rules of Productivity - Upload a Document to Scribd

Read this document on Scribd: Rules of Productivity

Update: Today InfoQ published an article about sustainable pace. OpenView Venture Partners has announced that overtime is detrimental to scrum. There is a reference to Clinton Keith's discussion on this also.

Typing faster makes you more productive...

I'm channeling JB,
JB is channeling a concept from Alistair Cockburn.

I highly respect both, so I'm not going to unnecessarily add anything more. Read about microtechniques and productivity to find an ingredient in the secret sauce.

I used to be faster, but here is today's result

77 words

Typingtest

Sustainable Pace...

I hate that in the past I've worked in an environment where overtime or week-end work was a badge of courage. Where the pager was rotated and the holder expected a page every night at some point. And this was commonly accepted. People didn't question whether the pager should have been able to go a week without ringing... they were used to knowing it would go off within the next 12 hours.

Of course, the company didn't require overtime... it didn't condone burning out... but we also didn't force someone who stayed up until 3 am to come in late (or not at all) either. Where does the line between volunteering and demanding begin/end?

Well, here's a post that I like... it's a debate I've poked at for over 5 years and homebrutrout says the piece very well.

How to handle interruptions...

There is a great discussion about how to handle interruptions on InfoQ. In many environments, teams have to not only build a product, but also support that product's existing customer base. Fires arise all the time that diminish productivity and velocity for the team. How can this be handled?

Suggestions included:

• separate backlogs
• emergencies (work stops)
• manage support like features
• sacrifice someone

Having seen Alistair's presentation at Agile 2007, this was one of the points I wanted to add to in the discussion. The "sacrifice one" idea is described properly in the post as: "assign one person dedicatedly to take care of that interruption. Though, this one person would feel sacrificed, rest of the team can make progress by working on the primary task."

My thoughts:
"As for Alistair's idea to sacrifice one team member, I do believe he supports that this is a rotating role (per iteration or sub-time window)... and that it is important to assign your most important person first to make it clear that it is an important role and is not dumped on the newer/weaker people in the team. Otherwise, it can become something that breaks the team dynamics into a group of superstars (those that create) and pledges (those that support)."