Implementing best development practices can lead to greater responsiveness, quality, and transparency. While there might be consensus in the wisdom of adopting best practices, development teams can be impatient in mastering them, and management will often give little time and budget for improvement efforts. Yet how teams go about implementing them is critical to success. A progressive adoption that follows states of maturity built on core principles, as opposed to an immediate adoption that attempts to make a quick change, can be what determines whether best practices bring teams to new levels of agility or simply create disillusionment with process.
Recognizing Practice Gaps
Adopting new ways of working takes time, effort, and practice. Even something that may appear to be relatively straightforward can require a significant amount of change. For example, a development team that delivers software on an irregular and infrequent basis will not instantly be capable of delivering software frequently and at regular intervals. The changes necessary to bring this about affect all development activity, from project management to requirements capture to engineering and build. Even a more modest objective, such as greater collaboration with a business customer, will be highly disruptive if the team's communication practices can't facilitate increased involvement from a non-development participant.
When successfully
Advertisement
adopted, best practices areas such as testing, requirements management, collaboration, and build are demonstrably superior ways of working. But successful adoption is a function of a team's capability and its self-awareness of that capability. That is, the pursuit of best practices requires that teams recognize the gap between what they're doing now and what it is they aspire to do, and specifically recognize those things they are currently doing that will undermine best practice execution. Suppose a team aspires to have a high degree of unit test coverage automatically executed during the build. This aspiration will be frustrated if the code lacks a testable architecture (e.g., if it possesses a significant number of singletons) and if individual developers do little more testing than infrequent, manual tests of their own code through the user interface. A team with a wide, unacknowledged gap such as this is likely to fail with testing best practices.
Clearly, then, both awareness of this gap and how it is bridged are key success factors in best practice adoption. Build and collaboration offer examples of this phenomenon.
Build Best Practices: Build as the Paragon of Integrity Continuous integration promises a bucolic state where code committed by developers is immediately subjected to compilation with the most current state of the project, and code quality, metrics, testing, and even deployment are automated. Suppose a team recognizes the value of this, but currently produces a project build only every few weeks. Suppose further that with each build, someone has to make adjustments to the last build script to make it execute. Attempting to instantly change from an immature to a highly mature state would likely be a serious failure.
The core of this is a change in each developer's priority. When the build is performed infrequently, each developer focuses on completing the coding task at hand. The greater the latency between the time when code is committed and the time when the project build is executed, the less visible - and subsequently the less important - the project build is for each developer. At build time, the team will do whatever is necessary to produce a successful build, meaning the build process will be adjusted, possibly dramatically, in response to the state of the code. This is not the case in when build is continuous. Because of the short latency between the time code is committed and a full project build is performed, each developer is more fully aware not just of the development task at hand, but the impact of his work on all other code in the project. This prevents a developer from making the potentially catastrophic assumption that a successful local compile defines "development complete" with a coding assignment. This represents a fundamental shift in behavior: rather than adjusting the build to fit the code, code is adjusted to maintain the state of the build.
Build practices therefore mature with increasing "build consciousness" of developers. Conversely, the level of build consciousness can increase when build process matures in an iterative fashion. Consider the following stages. In the least mature state, as described in the previous paragraph, the build is a custom exercise where code is marshaled manually and scripts are coded each time a build needs to be produced. The first mature build state is to improve build hygiene by making the build repeatable. This requires stabilizing the build script and keeping it consistent, even with changes in code. This establishes the build as an unquestionable integrity check, and becomes something against which all developers must reconcile their work. Once the build is repeatable, it can be made to repeat on a regular basis, using tools such as CruiseControl. The act of repeating the build to execute daily, or even multiple times each day reduces the latency between the time code is committed and the time a developer knows that their individual code commits work and play well with all other project code. Because the build itself is respected as a paragon of quality, a trait established when making the build "repeating," teams are better prepared to benefit from this reduced latency. Once the build is repeating, it can be made continuous, executed at very frequent intervals: several times each hour, or even with every code commit. This creates the build as a near-immediate feedback loop to developers and creates a high degree of awareness of the impact of each code commit to the complete software deliverable. In the most advanced state of build maturity, the build can be made a gatekeeper. Here, the build process automatically invokes unit tests and code analytics which must be satisfied or the build fails. It can also automatically deploy the current build to a QA environment. In this highly mature stage, a team supplements its high awareness of the build state with a more complete definition of what it means to successfully commit code.
Consider the incremental change taking place by working backward from the highest state of maturity. For a gatekeeper to be a benefit, the team must reduce the latency between the time code is committed and the project build is executed. To reduce this latency, the build must execute consistently. To execute consistently, the build process must be consistent. To be consistent, it cannot be a custom exercise. At the root of the best practice is the fundamental recognition by each member of the team that the project build is each person's responsibility. Only when this exists can build mature into an atomic, nearly transparent event that ties the impact of every code commit to the overall project.
Collaboration Best Practices: Engaging as Partners
Team collaboration offers an example of the same phenomenon. The idea of development teams actively engaging business partners is intuitively appealing: an active business partner should contribute to business buy-in of IT solutions and improve solution fitness through active feedback on deliverables. Collaboration is, however, deceptively simple. Traditional development practices aren't designed with non-development participants in mind. They rely substantially on establishing contracts of requirements through voluminous documentation which, in turn, drive deterministic project planning. The aggressive introduction of collaborative business partner participation will encourage ad-hoc requests and change, something which deterministic models and up-front design don't accommodate particularly well.
Establishing a highly collaborative business-IT environment requires fundamentally different ways of communicating. Traditional IT projects employ one-way communication, where things such as requirements and status updates are presented by one party to another, often infrequently or only during times of trouble or slippage. The first mature stage of collaboration is simply to have regular communications that make bi-directional communication possible. While team communication behaviors might still have more in common with traditional ways of working in this stage, the importance of this step is simply to create opportunities for back and forth communication through things like regular team meetings. From here, communications become structured through collaboration forums that actively engage people. In this stage, lightweight but structured meeting events such as daily stand-ups and iteration planning meetings drive participation. This basis of engaged participation allows for more sophisticated collaboration infrastructure that makes communication among all stakeholders more efficient. Beyond this, collaboration becomes fluid, characterized by the continuous entry, exit, and prioritization of requirements with the full participation of customer and development team.
Again, working backward, the incremental change becomes visible. The highly dynamic state is achieved when a team has mastery of the requisite collaboration infrastructure, which is itself the automation of structured communication forums, which provide structure to an established rhythm, which breaks the cycle of one-way communication. Attempting to short-circuit the process by, for example, jumping directly into a state of collaborative infrastructure is doomed without fundamental collaborative practices.
A Foundation of Core Principles
At the root of best practice adoption is acceptance of core principles by each team member, such as individual responsibility for the state of the build and true collaborative communications. It is also the wellspring of consistency and discipline in executing these practices. Payoff of best practices comes not from partial, inconsistent, or occasional application, but from pervasive and disciplined execution. Teams in immature states of adoption can be tempted to relax discipline when under the stress of a challenging business problem. By comparison, teams which fundamentally recognize the catastrophic costs of mortgaging the future by reverting to inconsistent build and irregular, uni-directional communications will continue to execute best practices with discipline, and yield the benefits. Execution to best practices can be the stated goal of a team, and even an expectation built into the IT governance model, but execution of best practices fundamentally rests on individual commitment to the values which underlie them. Without this, the pursuit of best practices might lead to a better state, but will not achieve maximum impact.
About the author Ross Pettit has 15 years' experience as a developer, project manager, and program manager working on enterprise applications. A former COO, Managing Director, and CTO, he also brings extensive experience managing distributed development operations and global consulting companies. His industry background includes investment and retail banking, insurance, manufacturing, distribution, media, utilities, market research and government. He has most recently consulted to global financial services and media companies on Agile transformation programs, with an emphasis on metrics and measurement. He is a frequent speaker and active blogger on topics of Agile management, governance and innovation. He is currently a Client Principal with ThoughtWorks.
Comments (2)
GaelStar: ...
Mr. Petit,
Taking one step back to see the process from higher elevations, I find there are certain basic assumptions in your argument:
1. Collaboration between team members is constant and effective 2. The Self-Directed nature of the team directs the paths it follows to creat the end-product 3. All teams have the necessary support infrastructure available to deliver the project 4. The business organization can accurately measure value coming out of each iteration.
How do you reconcile Best Practices when the infrastructure or business support is uncertain?
1
September 11, 2007
John: ...
This was a rather good view of the areas of attack in my development area. I totally related to this article, and would love to hear more thought and ideas in this area. I do not think that most Agile writers understand the extent of obstacles that we legacy programmers must face daily (manual builds and poor testing methods), when in fact, we are the ones most in need of help from Agile practices!
Articles 
Implementing best development practices can lead to greater responsiveness, quality, and transparency. While there might be consensus in the wisdom of adopting best practices, development teams can be impatient in mastering them, and management will often give little time and budget for improvement efforts. Yet how teams go about implementing them is critical to success. A progressive adoption that follows 
