Simplicity of Measure

October 18, 2014

Fitbit_Dashboard

I got a fitbit bracelet the other day. It’s a pretty nifty gadget. It tracks the number of steps that I take in a day, as well as measuring movement while I’m asleep. I’ve been very impressed with the number of things that you can derive from a simple measure of the frequency of movement. You get number of steps, activity level, calories burned, sleep periods, and a few other metrics. All of that from one simple measure of how often my hand moves.  Admittedly, some of those measures are inferred based on some simple assumptions like how many calories that the average person burns in a fixed period of time. However there is nothing wrong with that, The measure doesn’t have to be 100% accurate in order for it to be useful to me. I can see the trends and understand if my calories burned is changing for the better or for the worse without having the exact number of calories that I burn in an hour. An approximation is certainly sufficient.

It’s really quite impressive that you can derive so much from a single metric. It made me wonder about the metrics that we keep on Agile teams. Whether it’s velocity or throughput, there are metrics that we use for a lot of different purposes. We use velocity to tell us how much work the team can take on per sprint. We derive duration using velocity. I like the notion of having a small set of metrics like velocity that we can use for a variety of measures.


Radical Transparency

September 8, 2014

cokin-filter-field-hand-1050

 

 

 

 

 

 

 

 

I’ve always been a big fan of transparency in Agile projects. I love the idea of project stakeholders having an unobstructed view into the work that the team is doing. Of course, what does transparency really mean? To me, transparency means that anyone, whether or not they are a member of the team, can easily see for themselves the current state of the work. That includes all work completed, work in progress, and work remaining to be done. It includes all impediments, risks, and retrospective action items. In short, the customer should be able to see all of the artifacts that the team produces. That’s the idea anyway.

But what happens in practice? Well, if you are intimately acquainted with the team then you will have no trouble reading their stories, understanding their acceptance criteria, and otherwise deciphering whatever agile artifacts just happen to be pinned to the wall.

But what if you have multiple projects taking place at once? Suddenly any given story, of the hundreds of stories in progress, is likely to be completely opaque. Without the context of what the team is working on, coming in as an outsider can be disorienting. Try it out yourself. Walk into a team room of a team you don’t ever work with. March up to their task board and see if you can understand just what the hell they are working on. The odds are pretty darn good that you won’t have a clue.

Actually this makes a lot of sense if you consider that the backlog and the task board are a reflection of the learning that the team has done as they work to deliver a project. Together the team shares a collective set of lessons learned that has been acquired over the duration of the project. You really can’t expect someone to come into a project midway through and understand everything that the team is currently working.

Teams create their own shared understanding of the work they are doing. They often develop a shorthand to describe what they are doing that is difficult for an outsider to initially understand. If we understand team learning this way, then is it really reasonable for a team to have meaningful “transparency” once they have made significant progress on a project?

I think it depends on the information that one is looking for. It’s probably reasonable to expect to see a burn down chart and be able to understand what it tells us, even without knowing anything at all about the work the team is doing. You should be able to at least answer the question, “Are these guys going to deliver everything they are working on in this sprint?” There are a few artifacts that fit this description:

  • Burn down charts
  • Release burn down charts

Yikes! That’s not much to work with! But just about anything else you look at is very likely to be opaque if the project is even reasonably complex. It’s doubtful you will recognize what is in the product backlog (but not unreasonable, because we hope it is expressed in business terms). My experience is that teams start adding their own material to product backlogs fairly quickly. Once they start adding their own stories, they’re starting to share in the learning with the product owner. They are starting to alter their collective knowledge of the problem (aka learning). Some teams will be able to keep the backlog in business terms that everyone can understand, but that actually seems to be pretty rare. Teams tend to switch into their own shorthand fairly quickly.

OK, so maybe the backlog is transparent (maybe not). How about the task board? I can almost guarantee that the task board is going to be a complete mystery to your average project stakeholder who hasn’t been involved in the day to day development of the project. That’s OK, they usually don’t want to know the gory details anyway.

I used to have a notion of radical transparency when it came to development projects. Now I find myself questioning the utility of that notion. Not all the information that is important to the team is necessarily important to the team stakeholders. This seems to be especially true the larger the number of teams that you have working together.


Measuring Productivity = Continuous Improvement?

December 18, 2008

ruler

How do you measure the productivity of a team? Some answers that leap immediately to mind are:

  1. Story Points
  2. Throughput
  3. Function Points
  4. Features

And I’m sure there are dozens more. But as I consider this, perhaps I should re-examine just what the word “Productivity” actually means. According to Merriam-Webster the definition is:

1: having the quality or power of producing especially in abundance 

2: effective in bringing about 

3 a: yielding results, benefits, or profits b: yielding or devoted to the satisfaction of wants or the creation of utilities

4: continuing to be used in the formation of new words or constructions 

5: raising mucus or sputum (as from the bronchi) <a productive cough>

OK, we’ve all probably worked on a few projects that fit definition #5 of productivity. Cough. Ahem. There are a few words in those definitions that catch my eye: abundance, effective, yielding results, benefits, or profits. I’m still no closer to measuring productivity. Hmmm…

Donald Gray has a great blog on applying measures to a teams work. He points out the usual criticism of most measures – namely that you get what you measure (for better or worse – usually worse). However, that really doesn’t help us at all. We’re still stuck without a decent measure for productivity.

You know, the more I think about it, the more I wonder, “Who’s asking for a productivity metric?”

I can think of two basic cases:

  1. Some sort of external stakeholder (a manager, a director, a product owner, a CEO, a customer, etc…)
  2.  The team

If the answer is #1, some external stakeholder, then the odds are good that for some reason they don’t see the team as productive already. If they thought the team was productive to some sort of acceptable standard, they wouldn’t bother asking in the first place. It could be caused by a variety of things (poor visibility into the team, not understanding how the team measures its progress, or plain good old fashioned cluelessness). Or maybe they are trying to help the team. Pardon me for a moment, a monkey just flew out of my butt…

If the answer is #2, then that’s a team I want to work with! The way I see it, this is the way it should be. It’s the team’s job to be constantly examining their own productivity. They should be fascinated by it. Positively mesmerized. How can we improve our work? Measuring productivity in what ever form it might take is the heart and soul of continuous Improvement. It’s the team’s job, not the customers. That feels right. See? No monkeys!

Personally, I like Ron Jeffries example. Productivity is the team’s challenge and the customer’s right. Let the team find the measure and then they should hold themselve to it. Make it visible. I’m a lot happier with the notion that the team controls the measures of productivity rather than some external stakeholder. Is that wrong? Still no monkeys…*

*I apologize for the monkey references. Pinochio had his nose, I have butt monkeys.