Monday, January 18, 2010

Agile Values and Principles Should Guide Your Practices

In a recent meeting I was in we were having a discussion about a paticular process (I leave the exact process and practice off on purpose) and one person was saying it should be mandatory to perform a specific practice. This paticular practice is a bit heavy and was put in place because some legacy products/teams had some very bad habits and the code was really unstable. My first desire was to throw my hands up and discuss and say that it was stupid. Luckily, my more sensible side asked what is the goal of the practice? This lead to a discussion identifying the goal of the practice and how individual teams might need to meet the goal but not neccesarily with that specific practice.

As with any area of our work when we get bogged down in the day to day of doing things many times we forget why we are doing certain things. New people come on the team and challenge a practice and we get defensive and walls go up. We do not want to be in a position where we feel we must defend a practice or a tool for that matter. These or things to help us a meet a specific goal and that goal is what is the important part.

Since we want, or I hope we want, teams that are continually improving we need to understand what is the goal of the practice and then verify that both the goal and practice are inline with our values and principles. Let's look at a commone agile practices and the goals, values and principles behind it.

A common agile practice is TDD. Starting from the agile manifesto: TDD supports the value of "working software over comprehensive documentation" by having a set of tests that can be used to continually verify that the software is working. As an added benefit TDD also gives documentation of how the software actually works as well. TDD support the value of "respond to change over following a plan" by allowign change to be safer. Change traditionally is seen as dangerous but TDD is one practice (but not the only practice) that helps make change easier and faster.

Moving to Lean principles: TDD supsorts the Lean principle of "build integrity in". With TDD you are thinking of the integrity of the system from the beginning, before you actually write a line of production code you are considering what it should do and building a mechanisim to verify that it does it. TDD also supports the Lean principle of "eliminate waste". Rework and defects are waste in SW development. Since the test is written first TDD helps prevent the creation of defects and reduce the amount of rework by using the tests to verify that the current changes broken some part of the system. TDD also supports the Lean principle of "amplify learning". I can run the tests often to verify current changes have not broken anything.

By understanding the goals, values and principles behind the practice we have the ability to adapt the process to the changing needs of the customer and team. If we stop doing TDD how will it affect our ability to deliver often? Will it affect the quality and therefore increase rework? Is there some other practice(s) that it can be replaced with? What is the cost of the other practice(s) in comparison to TDD? Who are the customers of this practice? How will any change to the practice affect the whole system not just me? TDD is a practice that adds a lot of value and is backed by many principles and if you decide to replace it you will need to answer a lot of questions. Other practices have fewer goals and there will be more options available that may fit different situations better.

Focusing on the goal, principles and values is what allow a team to improve and adapt to change. If our practices become our goals we will fail and our teams will become less productive. Stop getting defensive when someone challenges you to change. First make sure you understand why you are performing a practice. Explain to them the goals you are trying to achieve with a practive. Validate that it does not violate the values and principles you are following. Does it look like it could make the team better? If so give it a try and see if the team gets better or worse and then adjust appropriately.

But please do not stop doing TDD. :)

No comments:

Post a Comment