« Agile Work Uses Lean Thinking - Empirical Process Control | Main | Agile Planning »
Share this post:
November 10, 2005 
Agile and Defined Processes
People who are organizationally minded, or who are risk adverse often have difficulty understanding the benefits and safety afforded by Agile as opposed to defined processes. This often manifests in a desire to standardize tools or processes so they become defined.
For example: an organization may wish to standardize on a spreadsheet template to use for iteration backlogs for all Agile teams. This seems innocuous. While I understand the desire to standardize, I believe even doing this would be detrimental to an organization. Some Agile teams may not use spreadsheets at all. In fact, using spreadsheets is considered a last resort used only if you have an extremely complex project. Generally speaking, user story and task cards along with a burndown on a white board are meant to be sufficient. Standardizing on spreadsheets would _impose_ process where it is not necessary and would be taking us all back along the path of a non-agile approach to projects.
In one instance where I have coached, we did in fact use a spreadsheet because we have up to 300 tasks per team per two week iteration. It would have been very difficult to manage all these tasks manually. Additionally, we customized our spreadsheet to work for our circumstances which are unique. Agile specifically encourages the values of simplicity and adaptability. I am perfectly happy to share our spreadsheet for other people to learn from, but the whole notion of standardizing the spreadsheets seems to be against agile principles. Think of it this way: would anyone be happy if an organization decided that everyone needed to drive the same car to work? Each person's car serves their own transportation needs. In exactly the same way, each team's spreadsheet/whiteboard/cards serves their needs… and not necessarily the needs of anyone else. It is true that everyone needs transportation, and in the same way an organization needs every team to track their user stories and tasks, but how exactly it is done should be left up to the teams.
Related articles can be found in the following categories:
Howto
I also maintain a page of references and recommended links to materials related to agile methods.
Posted by Mishkin Berteig at November 10, 2005 02:35 PM
