leaders" that had been designated by management—rather than appointed by the team. As the dynamics within the teams started to evolve and Agile technical "go-to" people started to surface there became a blurring of roles between these emerging natural leaders and the traditional, "titled" technical leads. As we continued our migration, we kept a look out for functional leads that could be experiencing frustration with the move to Agile. We found the best way to avoid this was to mix up common assignments on the team so that no one became pigeon-holed.
The Misconception of Chaos and the Importance of Transparency
Many people—including some of our own management—were under the impression that Agile methods imply random chaos and cowboy development. What we have learned is quite the contrary—Agile methods drive accountability, ownership and responsibility down to the lowest and most appropriate levels. Team members are held accountable not by some faceless process, but by their peers - peers that they must face each and every day at the daily stand-up meeting. Some of the core practices of Agile promote these characteristics naturally, and as we navigated our transformation we developed further practices to drive accountability and transparency across the organization.
Chaos Buster #1: The Daily Stand Up
Every day, each team member has to give an oral account of what they have done since the last stand-up, what they plan to do before the next stand-up, and any impediments that might be keeping them from performing their tasks. Gone are the slick, useless, status reports and emails. Everyone has to stand there day after day and tell their peers what they've accomplished. Talk about peer pressure - these daily oral reports promote accountability and ownership within the team.
Moving to meaningful, concise documentation
Let me dispel the myth that Agile development is only ad-hoc development which leads to spaghetti code that is totally unmanageable. We create design documents at each sprint that we call mini-specs which are linked to a broader architecture specification that is maintained by the product architect and evolves as the product needs to evolve.
These mini-spec documents are written collaboratively by the engineer who has taken on the user-story to develop the feature and the technical lead for the product or functional area. They are usually maintained by the technical lead as a living document and extended or modified as the feature or functionality is expanded. Further, they are posted on our Wiki pages so they're open for review and comment. We keep them brief and relevant—we don't try to capture all aspects of the software, instead we concentrate on recording the reasons for design choices, major components, and any assumptions at the time. My experience with traditional documentation is that it almost never captures this type of information. In Agile, standard best practice development guidelines still apply. The difference is that the team is free to alter and adopt those practices that best fit their needs.
Fostering improvement through retrospectives
Retrospectives do an excellent job of helping the team learn from their mistakes and ensure continuous improvement. As the trust grows among the team members, they start to feel more comfortable asking questions and making suggestions for improvement. They helped us build an environment of openness and objectivity. Further, we've extended our retrospectives to include planning sessions. We found that these were necessary to plan the changes we were going to make to improve on our process. In some cases we may even write user stories that apply to making the process work better. For example, in the area of functional test, we may have