What is Your Goal?

One of the best things about Agile is the introduction of software development as a system. Software stopped being treated as a sequence of separated steps to be seen as people with different competences working together to achieve one goal: deliver software.

This is not new in any sense, and it was exemplified by Deming on one of his books:

I could do a much better job (fewer mistakes) if I knew what the program is to be used for. The specifications don’t tell me what I need to know.

Despite this advance, most software development teams fail in really understanding this concept, and still normally don’t see the power of using one unique measure to manage the project, not getting the idea that the effort of the system should be only measured once, in what is its goal.

You must be asking what is the problem of having different measures to verify the sanity of the project. And that is what Peter Drucker explains in his Post-Capitalist Society book:

In knowledge work… the task is not given, it has to be determined. ‘What are the expected results from this work?’ is the key question in making knowledge workers productive. And it is a question that demands risky decisions. There is usually no right answer; there are choices instead. And results have to be clearly specified, if productivity is to be achieved.

What it means is that tasks cannot be fully specified anymore, the workers have to make decisions every time about how to proceed in certain situations, and they can just do it correctly if they have a clear vision of what is to be obtained, and what is the final goal of the work they are doing.

This concept is also illustrated in the draft version of Mary and Tom Poppendieck’s latest book (still in the draft version), when they are explaining the case of Southwest Airlines, which has as main advantage against the competition, the fact that its planes stay less time in the ground, thus generating more revenue.

Southwest maintains a systems perspective; it doesn’t let individual department measurements or increased revenue opportunities distract it from the primary objective of maintaining profitability. Southwest makes it clear to every employee – from the agent closing the gate to the baggage handler transferring luggage – what is important from an overall perspective. Everyone at Southwest knows the mantra: “Airplanes don’t make money sitting on the ground.” So everyone works together to get each plane in the air as fast as possible.

The important here is that we have one measure. One variable that everyone can rely on to make decisions during their work, and the ability to do it makes a whole difference in the overall performance of a team,  fact that often not considered in software development, where different measures distract people from the main goal.

As an example, a common situation I’ve seen in project is to track bugs within the iteration, and use it as a measure of code quality. Well, the goal of a software team is to deliver software without bugs, but it doesn’t matter at all if in the process of creating software bugs are found and solved prior to the software being released. If that is the way the team works best, so be it.

Another example is a case where a project had a problem with bugs creeping (this time, after iteration was finished and software delivered), and when discussing the fact we’ve realized that because of the pressure to deliver, we were delivering development complete, and not QA complete stories, so QA was actually done after the iteration finished, and yes, the team’s velocity was based on development complete points.

Well… if the goal you set to the team is to deliver dev complete stories, guess what you’re receiving in the end… dev complete stories!, it doesn’t matter how many times you repeat “Let’s focus on delivering quality software“. As Goldratt said, “Tell me how you measure me and I will tell you how I will behave.”

So, what is your goal?

%d bloggers like this: