Dreamfeed

In Delivering Business Value, Tim Beck writes about (agile) practices and their relation to delivering value:

But, and here is the hard part, if they _don’t_ achieve the business goals or don’t fit in with the context you are in at _this_ point in time, then you must look around at what other people have done to achieve their business goals in order to figure out what will work in your context.

How do you know specific practices don’t achieve the business goals? How do you determine whether a practice fits your context?

These questions are usually not easy to answer. It’s not a matter of we’re doing A, we’re still having problem B, so let’s stop doing A (or, the management perspective, we’re doing A, we’re still having problems, so we should do more of A). The relation between what you do (your processes) and what happens (failure, success, happy or unhappy stakeholders, etc.) is almost never a simple, obvious, linear relation. It is complex, cause and effect can be circular and/or separated in space and time. Practices are not independent of other practices, but form a system of mutually dependent practices.

Take test driven development (TDD) for example. TDD is not only a testing practice, it’s also a design practice. It helps keeping code more understandable and smaller – you’ll only write code you understand. You are forced to manage dependencies well, otherwise it becomes hard to write test units. Smaller, more maintainable code means that using TDD will have positive effects on project velocity in the long term. For TDD to keep on working, it needs continuous refactoring to keep code in shape. Otherwise writing tests will become harder and harder.

There is a second factor that makes it hard to decide whether a practice works. A specific practice (agile or not) may help to prevent problems – if you’re doing the practice, you won’t encounter those problems. This bears the risk of forgetting the reason why you are doing it. An example is having frequent, efficient status meetings and regular one on one meetings with the people in your team. These help to detect potentially major problems when they’re still small and seemingly unsignificant. After some time, big problems occur less frequently. The pattern I see then is that people start questioning the usefulness of the meetings – why do we have these meetings? There are no real big issues, we’re wasting our time. Instead, let’s only have a meeting when it’s necessary. The practice of frequent meetings is abandoned. At first everything seems ok. After some time however, you run into one or more really big and painful problems and you’ll waste a lot of time and energy on fighting all the big fires, because you abandoned your early detection and prevention system.

So how do you determine whether a practice works for you? I use e.g. systems thinking and the Theory of Constraints for this. Tools like diagrams of effects, current reality trees, evaporating clouds, and 5 Whys make the dynamics and the complex cause effect relations visible and help finding root causes instead of fighting fires. They also help to determine how a practice contributes to delivering business value and where to do effective interventions in the system – and that might not be the thing, practice, or person you thought of at first! See for example Willem’s blog entry on Process Improvement on ‘borrowed time’ where he investigates the relation between pressure to deliver, quality, and process improvement.