The other evening I attended a presentation on agile metrics by Larry Maccherone of Rally Software. It was a great presentation. But he said something along the way that has been bothering me ever since. Let me try to get you in the right place by setting the stage a bit.

He started off by saying the agile metrics in general are “Context Based”. That is, your business space, problem domain, company maturity, technology stack, size and maturity of your team, etc; ALL come into play when determining your metrics. I guess this implies a one-size-fits-all approach doesn’t work and, in fact, that there is a unique size per agile context.

He had me at hello with this one.

But later in the presentation he was talking about the latest product extension to Rally that he was the Product Owner of. It was a set if metrics extensions. Then he said that quality wasn’t the focus for them at the moment. Quickly getting code out the door was a better focus and, if the software had some bugs (waste), that it was fine. He needed the feedback and needed to iterate, which was more important than quality.

In fact he went on to say, and this seemed to be a more general point, that waste was good. Waste implied that you were being quick to market, that you were being responsive, nimble, and dare I say it—more agile.

You can view the outstanding presentation that Larry gave here: part1, part2. He also delivered this at the Agile 2013 Conference. It was a fantastic way to end 2013 for the Raleigh/Durham ALN chapter!

Lean Startup

Now I could almost hear Eric Ries’ advice coming from Larry because this advice was nearly straight from his Lean Startup book. So, yes, waste in some very specific agile contexts can be perceived as quite good. But I think we need to couch that firmly with the “context matters” point as well.

For example, even in Larry’s case, he’s “deploying” his metrics extensions on a mature product and by his own admission he was experimenting almost daily with new or modified metrics. Now from an early adopter point of view, this is exciting. You catch an evolutionary ride as a company is refining their tooling. And you get the chance to add your feedback to the mix and help tailor the metrics functionality.

But what if you aren’t an early adopter. Or if you’re trying to use the metrics to measure mature teams and leverage them as part of your KPI dashboard across the Agile Enterprise? Or what if you’re simply on a solid agile team that is now being “measured” by these new metrics.

I’d argue that quality matters. And consistency matters. And having a well cooked set of metrics probably matters as well. I guess my point is that while waste can be good in certain context where you’re trying to “find your way” for a new project or product, at some point waste indeed becomes…waste. And that isn’t good!

Agile Speed

I’ve often asked executives whether the agile methods in general are a “Speed Play”? Probably 80% or more of the time the answer is yes. They think by simply adopting agile approaches, sure with some maturation factor, they will naturally deliver more “stuff”. Often they believe it’s a quick and easy 2x or 3x multiplier for their productivity. I usually quickly burst their bubble of hope and tell them that agility is NOT a speed play. What is it then?

I firmly believe it’s a “Quality Play” that can become a “Speed Play” with lots of hard work and lean diligence on the part of the team. But I emphasize, it’s certainly not free or fast. It takes time and effort.

Usually the executives come around to understanding the point. Especially when I share some of the ways that agile can possibly go fast. I think they fall into the following four categories:

  1. Rework Avoidance:  taking the time to do things right the first time from an architecture and design perspective, but also from a quality point of view. Invest in reviews and pairing that inherently delivered better code and allows fewer bugs to escape. Rick-based testing and automation are another important investment here. But beyond the “code”, also extend this to documentation and all other product deliverables.
  2. Waste Avoidance:  don’t implement things that the customer truly doesn’t care about. The classic Project Management term is “gold-plating”. That is, adding work to a project that is above and beyond what the customer truly needs or has asked for. The essence here is the Just Enough and Just-in-Time mantra from the lean community when we’re building software products.
  3. Scope Avoidance:  so very often we’re asked to implement things that are simply guesses, where nobody truly understands exactly what the customer wants. Microsoft Word is a clear example of this. Studies have shown that only 20% of Word is actually used. The other 80% is total waste. Can you imagine what Microsoft’s team could have done with the “extra time” if they could have avoided it?
  4. Innovative Solutions and Creative Problem Solving:  this is one of the hardest to achieve, but the one with some of the greatest promise for time/cost savings. Refactoring lives in this area. As does simplifying your products at every opportunity. As does making your work testable and maintainable.  The mantra here is—delivering the simplest possible thing that will delight the customer and solve their challenges.

To me, the first three revolve around the general Lean term of ‘waste’ and as such, we want to more often avoid them then embrace them. That’s why I’ve had such a visceral reaction to Larry’s comment.

Wrapping up

From a lean experiments perspective, the point that Larry made was valid. In fact, we do want to experiment and triangulate towards customer solutions based on customer usage and feedback.

Clearly customer feedback is the Breakfast of Champions.

But that being said though, we don’t want to become frivolous in allowing waste to seep into our agile products, projects or most importantly into the mindset of our agile teams. Some waste in specific situations can be healthy. But most of the time, we want to defend against waste in all its forms.

I suspect Larry will feel differently as his metrics efforts mature and are leveraged by more and more of Rally’s mainstream customers.

Thanks for listening,

Bob.

1 Comment