RE: [scrumdevelopment] Re: Metrics (a summary)
It seems to me that this conversation has meandered off on it’s own path, as we are want to do on occasions J
My take on metrics is this…
- Software development is empirical
You can measure whatever you like but need to apply judgement & knowledge to get meaning from it.
- People are involved not machines.
If you want to measure efficiency/utilization/slack time then you probably don’t want to use scrum for a management process. Scrum is all about results. It’s about knowing where we’re going and if we’ll get there on time, not looking through the rearview mirror to see where we’ve been or how fast we went in the wrong direction (and feeling good about it). Measuring utilization, efficiency and friends are useful for other project management methodologies (the look behind types).
- Slack time, waste time, down time, etc is an important part of development.
It’s the area where creativity lives. The space developers need to think up the right solutions to the tricky problems.
At the end of the day the questions are these – how do you measure your return on investment especially when “business value” is such a nebulous concept, and how do you know your team isn’t wasting too much time while at the same time allowing them to time to be creative? The answer – I dunno. To my way of thinking, this is what people management & leadership is all about – maximizing the return from the team you have.
Maybe the best question to ask is “how do you measure management and leadership?”. I know I can tell the difference between a good leader and a bad one, but how do I measure it? Usually by the results. It’s the same with Scrum.
From: email@example.com [mailto:firstname.lastname@example.org] On Behalf Of David H.
Sent: Monday, 1 May 2006 7:48 a.m.
Subject: Re: [scrumdevelopment] Re: Metrics
-----BEGIN PGP SIGNED MESSAGE-----
Mike Dwyer wrote:
> The environments I work in already require people to report thehours. But
> if you do not then it would be an add. The other option is to reportat the
> end f the sprint DONE or NOT. In that case you would be hiding wasteas
> value as there would be no way to identify the waste time. Inaddition you
> would not have any means to track the impact of impediments.Well, the environments I have been in sometimes had it, sometimes they did
not. Sometimes they considered the time tracking as waste and in a way I can
Personally, and just personally, it is about getting done. Not how I get
there. I could care less whether my developers play ping-pong 90% of their
time, if they get done, they get done.
Yes, before you all scream, this is not realistic, there are monetary
implications and so on, but I am allowed to dream.