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?

Lean Lego Game @XP 2009

Next month, Me and Danilo Sato will be presenting the Lego Lean Game ate XP 2009, which will be held in Sardinia.

So, what is it?

The Lego Lean Game is an activity developed to teach people about the basic concepts of Lean thinking in a dynamic and fun way, demonstrating Lean practices in an imaginary production line to build Lego houses.

Why?

The idea came from the fact that Lean is becoming a common term in software development, but many people haven’t been introduced to the concepts that made it successful. This workshop aims at introducing this concepts to the participants, making them understand where Lean comes from, and why apply them in the software world.

Should I Come?

If you are interested in Lean, but haven’t had time to study about it, this is the perfect place for you. More experienced people are also welcome, since the hands-on activity makes you discover many aspects that might have been missed before.

If you want to have a better idea of how it is, you can check this video (sorry for the shaky camera : ) ), from the presentation we made at Agiles 2008.

Hope to see you there!

Porto Alegre Agile Weekend 2009

For the Brazilian crowd (or anyone who wants to be part of it), between the 25th and 26th of April will take place in Porto Alegre (my home town : ) ), the 2009 Agile Weekend, which has my friend Daniel Wildt as part of the organizing team.

This will be hopefully the first of many Agile conferences happening in South Brazil, and will serve to boost even more Agile adoption in the region.

Needless to say, I really wanted to go, but London is not close enough to Brazil yet…

More!

Since the advent of the industrial age, we have had a terrific word: “more.” It really worked for everything. When our roads became crowded, we built more roads. When our cities became unsafe, we hired more police officers, ordered more police cars, and built more prisons.

This is the introduction for one of the chapters of the book I’m currently reading, Information Anxiety, which talks about how to live in a world where we don’t have time to retain all the data that is thrown at us.

What I’ve found interesting about this sentence is how it can be applied in different areas, from police officers, like stated above, to software development.

It is surprising to see how many people that work in the area believe that a software project running behind schedule can be solved with a simple measure: throw more people in the team.

It is so appealing that nobody thinks it can go wrong, and they often forget to consider some minor points, like:

• time it takes for newcomers to understand the project and its domain
• time it takes for newcomers to know the people in the project
• the decrease of communication levels brought by the addition of new nodes

and more than often, the same persons that believe in this measure forget to take a look at their team in order to really try to understand the root causes of what is happening, in a totally anti-genchi-genbutsu way of solving problems.

In a recent project I’ve participated, 4 persons were added to a 3 pairs team in order to try to increase velocity the team was delivering. Needless to say that in the first week we had a 5-pair team with 4 newcomers, and if you looked at the team room, you could see that in each pair there was one person trying to explain to the other how the system worked.

It is pretty straightforward to understand that the team was in reality less than half strong, and that in the first iteration we delivered…. guess what? Half the points.

So if you are thinking about ramping up, think again, and again, and again, and spend some time just looking at how your team works before you make any decision.