Wednesday, September 23, 2009

Team Preservation vs. Prioritization

Keeping a team together is important, but not to the point where prioritization is hard.

Shared services teams are a necessity and they won't go away. The problem with them is that backlog prioritization is hard. You need to identify a product owner that is effectively a proxy to all the other users. This proxy's job is thankless; he or she has to make multiple competing stakeholders agree on priorities without an incentive to collaborate.

One way of solving this issue would be to group and disband teams as projects come and go. The Storm, Norm and Perform [1] theory for teams suggests that we keep teams together as long as possible and this approach would go against it.

So how would I solve this difficult problem?

I thought about:

  1. Have a proxy for clients responsible for accommodating and negotiating priorities across stakeholders.
  2. Dedicate resources or hours to specific stakeholders.

  3. Form/Disband teams as projects come and go.
  4. Create a cap and trade system similar to the one described on [2].

Lately, I have been leaning towards option 4 a lot. In short, every stakeholder is given a number of hours, or percentage of the team's time; a cap. They are allowed to negotiate their hours (or points) with the other stakeholders, but once the iteration, or some other time period starts, any points/hours that were not used would be forfeited in a use it or lose it fashion (I still have to think this one through).

This approach is not infallible. It can lead to context switching if all stakeholders decide to exercise their options in a specific, or worse, all iterations.

On the other hand, this could lead to some interesting behaviors, where certain stakeholders with medium priority projects could negotiate their caps at a premium with stakeholders that are "desperate" for completing projects. In other words, it rewards collaboration. It also allows the shared services team to measure how much a stakeholder "conceded" or not, eliminating the squeaky wheel effect [3].

Another interesting consequence is that it would encourage better portfolio management on the stakeholders’ part. I don't mean to reduce acceptance to change, but committing the team to a task/story that has low return value, would equate to throwing away money.

The cap and trade system seeks to reduce conflict resolution for all involved and give an incentive to negotiation and collaboration among stakeholders. I have not implemented such a system and have not completely thought it through, but it seems promising.

Besides all of that, it could lead to an interesting game.

What problems do you think I'm going to encounter? How did you solve this problem before? What were your good/bad experiences?

Please leave a comment below :)


Monday, September 7, 2009

How stable should velocity be?

If you are estimating story size instead of duration, velocity is what will allow you to determine project duration and thus cost. In such an environment, velocity is an important metric and needs to be monitored accordingly.
As I wrote back in April, we have been collecting data to see if we were improving or not our velocity. My original intent was to find what influenced velocity however, that goal became making sure that velocity is somewhat stable.
As we started to collect metrics (Total # of team hours available, # of points with clear definition of done, # of distractions and # of blocks) we started to pay more attention to velocity. It was interesting to see that velocity was varying beyond what we expected. We could always explain why velocity went up or down, but it was varying regardless. One of the issues we found was that story estimates were wrong. The team inadvertently started using a different scale that turned out to be too small. In other words, a story that used to be a 5 became a 1, so the stories that were a 1 had nowhere to go.
If you are using story points, you need to make an effort to make sure that the relative sizes of stories are valid. As you work through your stories you look for stories with disproportional sizes. A story of size 5 must be a little bigger than twice a 2.
I regularly use a room painting problem to explain story points. It works well because people will tend to estimate the time it will take to paint a room by the number of walls and their sizes, but the number of cuts (windows, doors, etc.) is what really determines how long it will take. So once we go through the exercise of estimating painting multiple rooms based on sizes, I introduce the cutting variable and thus have the team re-estimate the "project". In other words, when the team learns something new about a set of stories, they should go back to the backlog and re-evaluate their estimates.
During this effort of collecting metrics, I did create control charts for velocity, but these weren't as useful as I expected. If you just observe velocity you can already tell when there's a problem, you won't need control limits for that. Pay attention to what is contributing for your velocity to vary. If it is distractions, make sure they go away!
The participation of the team is important. They have to share your ideal that this is intended to help them achieve their full potential and that cheating the system will not help anybody.
Velocity shouldn’t swing much in a single iteration. It should be stable and somewhat predictable. If it does you have a problem and need to address it.