This is an operator’s nightmare: security breach leads to information theft leads to direct or indirect damage. Someone hacked into the information systems, and stole credit card numbers or other sensitive personal information; alternatively someone hacked into the information systems, and deleted vital records.
Whereas the latter has higher chance of being revealed rather quickly, the former may be done in stealth, over a period, creating undetected damage to revenue, reputation, or even to personal security and privacy.
There are many reasons to go SCRUM in particular or agile in general. Each organization will have their own reasons and motivations. According to the 2011 State of Agile survey, top three reasons are to increase time to market, to cope with changing priorities and to increase productivity.
The question is, how do you know that you are getting there?
The default answer for most is KPIs. Measure it, and you will know that you are there. The problem with measurements is that they are very elusive. You want to measure one thing, and ending up affecting another. Regardless of the measurement, you may impact something that you didn’t intend to.
Why is that so? This is because when you measure things, you leave a trail, and this trail is not merely the guide to go back, it is also the guide to go forward, a kind of a forecast to the next target.
In fact, a trail is more useful to going back in order to fix things, rather than to predict where to go next. Take breadcrumbs navigation: It helps you go back in the application to re-navigate; it also helps you navigate faster on successive uses of the application. But it doesn’t help you predict what you are going to do. It can help you measure what users are doing most, in order to improve the navigation. Like in Hansel and Gretel, the kids wanted a trail back home, not a guide to go forward.
Take an example. Many teams use velocity as their planning tool. They use the amount of done stuff, in relative size, in order to plan how much they can sensibly fit into the next iteration. It is a planning tool, not a measurement.
Yet, organizations try to use this velocity to do more than planning. After all, velocity can be a good measure for productivity or even predictability, can it not?
Yes, if your organization’s main business is velocity. When were you last asked by your customers: “For the next release we would like to order 54 points and 21 epics, please”? Is this the kind of predictability you require?
Check out Smith and Jones Predictable Lighthouse sketch – are you convinced that predictability is something you welcome that much anyway?!
What kind of trail can you use that will record something deliverable, and not an artificial, game-able, number that can have collateral impact that is potentially undesirable?
Let’s examine few of the options:
Velocity: Dear team, please provide more story points.
No problem, dear manager. We’ll just skip all those tests, and the number is set to increase. Given that we do not provide the support, escaping defects will be anyway handled elsewhere.
Predictability: Dear team, please provide a consistent number of story points.
No problem, dear manager. We’ll just provide the same number of points. When something big comes in, we’ll just bloat the estimate, so we don’t have to deal with breaking to smaller stories.
Cycle time: Dear team, please provide a standard ratio between points size to the time to develop it.
Now here’s a good one. Cycle time can actually be a rather useful trail. But only if you consider it from a systemic point of view – which makes it much harder to measure. Otherwise, it may become similar to velocity
The problem with all the above is that it mixes several concepts into one number. The trail and the measurement are not one and the same. This is why using points or velocity as a measurement is risky. It becomes goal in itself, rather than means to a goal.
In such a trail, for every story you specify, in business context, WHAT is the system expected to do. This specification is turned later to an executable sequence that will verify that the developed code does WHAT it is expected to do. Note, that specification by example is not about HOW, it is about WHAT.
This makes a trail of business rules that have been proven, and are now part of our regression suite, and upcoming trail that is what business rules are to be proven in the coming iteration. In an analogy to the breadcrumbs navigation, where have we navigated so far, and where are we navigating to now. Note that over specifying (forecasting several iterations ahead) is likely to become waste.
Recall from the top of the post, the trail helps you go back and make corrections. In this executable specification trail, it enables you to either fix business rules that got broken due to changes, or to remove redundant rules – and code, in order to navigate better in the future.
Coming back to measurements – this trail is not a measurement. It is a trail.
If you must measure, try to check, for example, how many routes you are navigating on concurrently. WIP can be a good measurement for that. Yuval Yeret has a good explanation of WIP and using CFD to measure it. Once in place, you can start measuring also cycle times, but as a supporting tool for your WIP, not as a guide to limit story duration.
Alternatively, try to use Agile Earned Value Management (EVM). You may read about it in Tamara Sulaiman’s article here. While Agile EVM is useful for planning against budget, it has some hidden assumptions, such as scoping for the entire release.
The merits of one measurement or the other is the subject for a separate post. I will just comment that I like these measurements more than others because a) they are good tools for decision making, and not merely measuring; and b) indeed they are based on the trail but not measuring it.
As long as you remember that the objective of the trail is to correct yourself – to make the right decisions, you will be ok. Don’t force measurements if you cannot effectively use them for decision making.
Otherwise, you may find that you were hoping for breadcrumbs and instead of SCRUM you we left with, well, just the crumbs and no trail.
All things, great and small, come to an end, eventually.
So are new posts to this blog.
I am currently writing mainly to our blog at Practical Agile. You are most welcome to visit our website and blog.
Becoming agile 