Moving to Agile

Well, day two at TechEd 2006 in Boston and just came out of a talk on implementing agile methodologies in your organization. What I found interesting is that many of the best practices the speakers (from the patterns and practices group) discussed were ones that our project team are currently implementing. As a result, it was a good check for us in seeing what we have yet to tackle both from a team and organizational perspective. Briefly, here are a few of the practices mentioned and what we've done:

Building a team space. While our team members still have cubes, 90% of their work is done in a conference room dedicated to the project. In my view, that has increased the speed of communication and helps us to resolve issues more quickly. It also has the effect of allowing everyone to be more or less on the same page with how things are implemented in areas that they perhaps are not currently working in.

15 minute rule. Essentially this rule says that if you are blocked for 15 minutes, give up and go ask. The team space definitely encourages this behavior although we haven't talked about it specifically. The corollary to this is that when someone asks for help you can't say no. In our organization this doesn't tend to be a problem anyway but surfacing the need to keep the communication open is key.

Real-time code review, aka Pair Programming. We don’t pair program today but we do have some overlapping of assignments with two core BizTalk developers and two services devs. In some cases they work together on a feature and of course I assist and help talk through the implementation of code. We should perhaps be more intentional about this.

Give team time to gel. One of the things that has helped us be successful is that our team had a two month time period in which we implemented a reference architecture before turning our attention to actual production code. As a result, we were able to find our roles before the pressure ramped up. While not intentional, to me, this turned out to be a very helpful by product of the process.

Get a coach or mentor. None of the team had had much exposure to agile methods before and could have used a bit of coaching before the project commenced. That said, we're not really officially doing agile within Compassion and so this probably wasn't an option. But if we had to do it again, a bit more knowledge would have been useful.

Encourage questions and discussion. The team space really makes this possible. It tends to keep the environment open and questions are often raised within the room to no one in particular. To me, that's a sign that people are comfortable with each other and no one is too intimidated to ask.

Stack rank work by importance to customer. While our customers have been very involved in the project, they have only stack ranked work related to hot fixes once various releases have gone into production. Our organization has some way to go it seems before customers are entrusted to do this. The corollary to this is reevaluating that stack frequently. This also needs some work.

Developer estimates are not to be trusted. The speakers were adamant that developer estimates of more than three days are probably essentially guesses. Unless you can break down a feature into very small tasks, then you're not really estimating. Our developer estimates are a bit larger than that and so we probably have some work to do.

Clarify Customer Requirements. We have used use case documents and a feature matrix in order communicate the requirements. Unfortunately, the documents are not always as clear as they could be largely because the conceptual model used in the development of the use cases was not familiar to the developers or the users. Had we to do it again, the use cases would be written in the language of the users and not in the language of the logical model. The team would then be responsible for translating that language into a new model used to implement the software. The speakers also note that automated tools should be evaluated that allow the requirements to be executable.

Customer (or their proxy) has to be available. One of the strengths of our project is that the business users and stake holders almost all reside in the same building and we have had for the most part a business analyst that does a great job of communicating. That allows the team to surface an issue and get feedback very quickly. The average turnaround time is something like four hours.

Implement the 3 strikes rule. In a nutshell this means you don't refactor code until you have three consumers for it. This has been a balancing act for our team since most of what we're building is being done for the express purpose of reuse across future projects. However, the features within the services we build we evaluate and implement based only on the certainty that they will be reused. In other words, our strategy has been to implement the infrastructure that will allow us to refactor when necessary but not to over-engineer in the near term. Examples include the business rules infrastructure we've implemented as well as the exception reporting and suppression techniques we've used. Interestingly, they noted that when you need to refactor, one technique to allow developers to integrate it into the project is to position it as "making room" for a feature before implementation. Their point is that the term "refactoring" implies rework which signals a red flag among some.

Insist on clarity of code. As with most agilists, their emphasis was on code readability for maintenance and refactoring. We insist on NDoc comments and code standards in terms of naming conventions etc. to assist with this but should probably be even more diligent about this.

Reward individuals for team behavior. Our team celebrates success after releases and there is very little in the way of individual rewards. The goal is to get the team to own the entire pie and not just their little piece of it. In that regard, something we do need to work on is the concept of developers working on features and not owning them. We tend to segment our devs into three buckets and each bucket's owns a set of features. While to some extent it is very difficult for everyone to know everything, we should do a better job of specifically asking devs to make changes in code that they have not had a hand in developing. This would increase team ownership.

Everyone is entitled to participate. In our team room we include not only devs but also testers, the project manager, infrastructure support, and technical writing. Including everyone certainly helps with communication issues but the speakers were actually suggesting that these other disciplines take part in real-time code reviews and design sessions. Each person would then contribute at their level. We certainly have not done this explicitly but again, having everyone in the room provides them accessibility to those discussions. At the end of the project we also do lessons learned off site sessions where we collect feedback to help us improve the process going forward.