An Enterprise Agile Journey

[article]
Borland's Case Study in Enterprise Transformation

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

About the author

TechWell Contributor's picture TechWell Contributor

The opinions and positions expressed within these guest posts are those of the author alone and do not represent those of the TechWell Community Sites. Guest authors represent that they have the right to distribute this content and that such content is not violating the legal rights of others. If you would like to contribute content to a TechWell Community Site, email editors@techwell.com.

AgileConnection is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, TechWell.com is the place to go for what is happening in software development and delivery.  Join the conversation now!

Upcoming Events

Sep 24
Oct 12
Oct 15
Nov 09