Agile Zone is brought to you in partnership with:

Kirk is a software developer who has filled most roles on the software developer team. He is the author of Java Design: Objects, UML, and Process (Addison-Wesley, 2002) and he contributed to No Fluff Just Stuff 2006 Anthology (Pragmatic Bookshelf, 2006). His most recent book, Java Application Architecture: Modularity Patterns with Examples Using OSGi was published in 2012. Kirk is a DZone Zone Leader and has posted 77 posts at DZone. You can read more from them at their website. View Full User Profile

Grass Roots Agile

02.24.2009
| 16860 views |
  • submit to reddit
Team Guidelines

Working to establish an environment that increases agility is only a starting point. Guarding the integrity and quality of the source code is our top priority. All else must be secondary. Nothing can be proven, verified, or evaluated unless a functional system is available. While a supporting environment is critical, the team must be rigid in enforcing some simple team guidelines.

Golden Rule

A prime directive of agile development is sustainable forward progress. A failed build always represents a step back. Anytime the team experiences a build failure, it must become the priority of the team, above all else, to rectify the situation. No changes other than those correcting the problem should be released to the source repository until the application is successfully built.

Synchronization Rule

Developers should release and update their local environment at least once per day with the master source repository. Waiting any longer increases integration risk.

Release Rule

Avoiding build failures requires developers to exhibit more discipline while coding. Developers must write tests and code simultaneously. When finished, a local build should be performed, followed by synchronizing changes with the repository. Any differences between the local environment and the source repository should be resolved before releasing code. Developers should give careful attention to ensure they release all modifications to avoid a partial commit that may cause a build failure.

Defect Rule

Fixing bugs must be done with rigor and discipline. Developers should first write a test case that recreates the defect. Initially, the test should fail, but after correcting the defect, the test should execute successfully. In addition to identifying and fixing defects, automating tests as part of the build ensures the defect does not resurface. When finished correcting the problem, source code changes including tests, should be released according to the Release Rule.

Team Organization

The software industry does a very poor job of learning from its history. In 1968, Melvin Conway gave us Conway’s Law, which states that organizations that design systems are constrained to produce designs which are copies of the communication structures of these organizations. In other words, the design and architecture of software is a reflection of the team or teams that built it. Agile practices speed software delivery and increase software quality by increasing communication and sharing valuable information. The team structure and collaboration methods in place are critical aspects in ensuring the development team delivers resilient, adaptable, and high quality software.

Team Structure

It should be no surprise that large software projects have a higher failure rate than do smaller projects, and that larger teams are more difficult to manage than smaller teams. For large projects, dividing the system into smaller systems, or modules, is one technique to make development a bit more manageable. Herein lies the rub. Failure to share information across these smaller teams of developers results in each module having a separate architecture, inconsistent user experience, and disparate levels of quality depending on the practices employed by each team. This is the heart of Conway’s Law. While SOA may be the architecture model du jour, the benefits of loose coupling and service transparency can work against a team if developers rely solely on the service interface as the means to communicate.

To avoid the integration and quality issues that surface when teams work in isolation, team cross-pollination is important. Experienced developers from each team must communicate on a regular basis to discuss architectural, functional, and technological issues. The structure and makeup of the teams have a significant impact on the teams’ ability to communicate. I’ve found two common models used when organizing teams of developers.

Process Organization

With this structure, groups of developers focus on developing complete business processes. Each process may or may not be part of a larger, consolidated system. The group of developers emphasize building front-to-back functionality, including all user interface, business logic and data access functionality. The greatest benefit is that developers gain a more intimate understanding of the business process and tend to be more connected with business objectives. For larger systems, with many smaller teams of developers focusing on developing support for business processes, Conway’s law tends to surface quite readily.

Technology Organization

With this structure, groups of developers focus on working with a certain technology. For instance, one group of developers might be solely responsible for the data access layer, with others focusing on the business layer, and others focusing on integration with external systems. This allows developers to gain a significant amount of expertise with specific technology, such as Hibernate in the data access tier. But all too often the teams lack a clear and concise vision of the business goals of the project. Without this understanding, developers tend to emphasize technology excellence over business excellence. In addition, integration issues can easily arise if developers across tiers fail to communicate.

Which Way is Best

Since I’ve found it produces more positive results, I favor process organization over technology organization since developers gain a more intimate understanding of the business processes they must support. The challenge with process organization, however, is avoiding silos that cut off the smaller teams of developers from each other. Encouraging technology experts from within each process team to share information across teams is one way to avoid silos from developing. For instance, a usability expert that spans teams is one way to ensure the system maintains a consistent look and feel. If Hibernate is used as the data access framework, an expert well-versed in Hibernate can offer guidance to ensure access to data is done consistently, reliably, and performs well. Assigning individuals to these roles does not always work. Instead, allow technology experts to emerge from within the process teams and establish a plan for them to fulfill the requirements of this new role while allowing them to participate with their process teams.

Favoring process organization offers many advantages, but one significant disadvantage is having small teams working in silos. It’s imperative to establish communication channels that span disciplines and teams. I caution against using heavy forms of documentation as the preferred means of communication, keeping in mind that the value of a document is not the document itself, but the thought that went into creating the document.

The Agile Matrix

Figure 1 illustrates the Agile Matrix, a cross-pollinating software development team. Teams of developers are responsible for fulfilling the requirements of core business processes, while technology experts working on process teams are responsible for mentoring and communicating across project teams on the most appropriate use of practices, patterns and technologies relevant to a specific tier or specific role. Open channels of communication must be present across all teams and all team members must advocate the use of techniques to ensure that intense collaboration prevails. The result is multiple levels of communication that span teams, roles, and ultimately projects.

Figure 1

Published at DZone with permission of its author, Kirk Knoernschild.

Comments

Sergiu Ivasenco replied on Sun, 2009/02/01 - 10:53pm

A very good article about the essence of agile. Worth reading

Sergiu Ivasenco replied on Sun, 2009/02/01 - 10:53pm

A very good article about the essence of agile. Worth reading

David Michaels replied on Fri, 2009/02/20 - 3:28pm

You said: Ideally, the most effective artifact is executable against the source. For instance, a suite of user acceptance tests that have received customer approval. Source code is an executable artifact and must be wrapped by practices and processes that verify the correctness of the source. I have found a source code control tool to be valuable to Agile practices where it can manage both the source code assets and adapt our process on the fly and be as agile as we are. The only tool I have come across that can do this is Accurev. http://www.accurev.com Giving our teams the ability to do individual testing in private workspaces, improve our continuous integration environment, and allow us to change our process with a quick drag and drop when story requirements change in invaluable.

john green green replied on Tue, 2009/09/15 - 11:41am

very helpful. Thanks!!
-----------------
Get a good buy

john green green replied on Sun, 2009/12/06 - 11:37am

For it is us who produces the only artifact upon which a software system is judged. And it is we who must push, fight, and claw for a better way. It is our responsibility to lead the charge, and initiate the transition from the prescriptive and plan-driven processes of yesterday to the adaptive and emergent practices required of today’s software development effort.
nike china shoes

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.