I taught and coached agile software development a lot over the last many years. A common question was "What about metrics? I need an agile that supports metrics. Our organization does metrics. Or will." Often the people asking the question had little if any understanding of "metrics". Often they thought that "metrics" (the kind in "quotes") must be really complicated, and so this agile thing where you cheat and cut corners certainly must not "do metrics".
Often the people asking the question were asking because *their* managers, QA team, whoever were telling *them* or asking *them* about "metrics". Often neither group of people had much of an idea of what "metrics" are, not to mention which are valuable or how to collect them. But since the term is spelled "metrics" (the kind in "quotes") they must be really complicated, and so "important".
My response (after asking them what kind of "metrics" they are currently gathering, how do they use them, and have they seen improvement from that effort, *and* after finding out, no, there is little they collect, less they use, and zero improvement), my response after all that is that an "agile" approach to "metrics" is like an "agile" approach to *everything* -- try to make consious decisions, try to have an idea of what to expect, and try to do it in small, measurable(!) steps so as to have a hope of making any sense of it.
Elaborating, I would explain that "cycle time" to "get business value into production" is a really good measurement for an organization, but that cycle time is *the* most difficult to improve in any significant way. (Here is where we would spend less than an hour doing a *really* simple, quick-and-dirty "value stream map" in order to start thinking about how to measure cycle time.)
Beyond, or even before, measuring cycle time in any detailed manner, just thinking for an hour about your "value stream" and roughly where time goes, and whether that time should be counted as "waste" or "value" is exceedingly useful for a team. In fact the activity can help a team understand who is (or should be, or could be) "on" the team, what changes are within the power of the currently defined team to make, what changes will be more difficult because they go beyond the purview of "the team" per se, and so on.
The other challenge is that measuring cycle time assumes the value being added is the highest-priority value (or as close to that as possible) for the organization. Before spending a lot of time measuring cycle time, or anything else for that matter, a useful excercise is to get a quick survey across the people and organizations in the value stream as to their awareness and consensus on value priorities and decisions. If these people and organizations are not "aligned" (and they typically are not) there will be mixed priorities, misunderstandings, and so delays and failures.
How do these organitions make decisions? If they actually do make decisions together, are they accountable (metrics?) in any way to uphold those decisions?
Surprisingly (or not if you've been around as long as I have in several organizations of various sizes), organizations are emphatically *not* designed for effectiveness if the measurement (!) is getting prioritized business value into production as soon as possible (and keep it there correctly). How is your organization "designed" if that term could be used at all?
I've participated in some significant "re-orgs" and I can say with certainty they are rarely "designed" for or from any such measurements. Based on the reasoning(?) and politic'ing I've seen in "re-org" meetings and smoke-filled back rooms and hallways, an argument could be made that the opposite is true: organizations are typically designed to *impede* progress.
Sorry, that's the way it is. If you're organization has figured out how to "manage the whitespace in the organization chart" you have a *keeper*. Organizations are "systems" and attention has to be paid to what are the goals of the organization and whether the organization is "aligned" to those goals and whether the "system" is designed to effectively address those goals and whether they have the fairly simple-yet-seemingly-impossible-to-apply tools (like simple "metrics") to continuously improve toward those goals.
It's a system. Apply the universal laws of systems or ignore them at your peril. I'm done.
No comments:
Post a Comment