A top-down, institutionally sponsored approach can be an effective way to roll-out Agile practices across an organization. Top-down approaches benefit from a high degree of visibility and strong executive sponsorship, both of which communicate to the entire organization that value is placed in Agile practices, values, and principles by leadership. Similarly, having a central change team coordinating the rollout accelerates organizational adoption and offers consistency in execution and measurement. By clearly articulating the organizational problems, providing incentives for individual contribution, and establishing business-facing execution metrics, institutionally-sponsored programs make Agile adoption important, actionable, and relevant to the organization. This makes it easier for individual project teams to adopt Agile practices.
Make It Important: Define the Problem Agile Will Solve
Any top-down initiative needs to have a charter rooted in an obvious and important business problem. This gives clear purpose to the introduction of Agile practices, and gives people an understanding of how they can contribute to its solution.
The nature of the business problem is particularly important. Change made for reasons of administrative convenience - for example, an IT objective of having 100% unit test coverage of code for sake of having 100% unit test coverage - is not a compelling reason to take on Agile practices. Efficiency or waste-reduction initiatives can be valuable, but can just as easily be dubious as actual cost savings can be difficult to quantify. Pursuing change in order to make significant, even dramatic, bottom-line impact creates a compelling "call to action" in a top-down Agile initiative. For example, if transactions are failing and customers are leaving a trading firm due to unreliability of trades, a drive to quality will make significant - and measurable - business impact. Even better than damage control are initiatives tied to organizational growth. A company is better positioned as a "destination employer" if the business imperatives are not efficiency, savings, convenience or remediation
Advertisement
but business competitiveness through innovation or growth.
This compelling business need drives individual responsibility. An obvious and urgent business imperative makes clear the answer to the question "Why are we making this change?" Linking specific Agile practices to business need communicates the motivation behind a sponsored initiative. It also makes clear how every individual contributes to achieving business goals. Consider an organization that is unable to release new software due to an excessive number of defects. By writing unit tests before software is coded, requiring that all committed code be in a state of build-readiness, and auditing all code through pairing, defects will decline. Making the connection between business need and day-to-day practice can be the difference between "rubber hitting the sky" or "rubber hitting the road" in a top-down initiative.
Make It Actionable: Active Versus Passive Efforts at Change
While taking a top down approach can provide clear linkage to compelling business needs, by its nature it risks ignoring practical matters of on-the-ground adoption. A small team charged with rolling-out Agile practices in a large organization needs a lot of leverage. As a result, top-down Agile adoptions can favor breadth over depth. Very often, this becomes an emphasis on tools and training as means by which to reach large populations in short periods of time. It also reduces the points of personal contact between change leaders and change participants, placing a greater emphasis on e-mail and artifact creation over direct contact.
Agile practice adoption is not accomplished solely through tools and training, but through fundamental change in how work is performed day-in and day-out. Broad tool roll-outs, training, and passive communication through e-mail and Wikis are reinforcing events, but do not specifically address how work gets done. Experience and application matter most.
Clearly, then, project teams have to be active and engaged in the process of adopting Agile practices. An effective technique in a top-down approach is to federate participation: make Agile practice definition less prescriptive and more a process of discovery by each team within a set of guidelines and expectations. In this approach, the application of Agile practices in different business domains and technical environments become opportunities for individuals to be seen as organizational "thought leaders." This provides individual motivation, and creates leadership and expertise where it matters most: in individual delivery teams. The sponsored Agile initiative is subsequently not an ethereal initiative coming down from a corporate headquarters, because practice adoption is very much a phenomenon within individual teams.
Make it Clear: Communicate Information, Don't Overload with Data
Agile projects are like Formula 1 cars: they produce a lot of data, most of which is meaningless to the uninitiated. What is done with this data will have a significant impact on how the organization responds to IT's increasing "agility."
Agile practices generate a lot of project and technical measures. The number of feature points ("stories") and their estimating unit ("ideal days"), the amount of time the team has remaining ("capacity"), the impact of distractions on a team's performance ("load factor"), and the historical performance ("burn up") all provide a quantitative foundation for project analysis. Similarly, it is easy to generate technical metrics by integrating tests and technical analysis tools into an automated build. For example, tools to automatically report unit test coverage (such as Emma), code quality (such as PMD), security compliance, scalability and so forth can are easily implemented in an automated build process. Because Agile development occurs in fixed-length time-boxes (or "iterations"), both project and technical metrics can be provided on a consistent basis. The good news is, this generates a lot of data. The bad news is, this generates a lot of data.
This is further complicated by the fact that Agile uses familiar language. Terms such as "load factor," "velocity" and "ideal days" are deceptively familiar, which leads people "understand Agile too quickly." The combination of a false sense of understanding and an overwhelming amount of data form a dangerous combination. At best, there is more data, but less information. At worst, there is an outright misunderstanding of what is happening with a delivery project.
Continuing with the Formula 1 analogy, knowing the team's "load factor" is somewhat akin to knowing the manifold intake pressure of a car. To people familiar with the terminology, this might be useful information as to how well the engine is holding up under stress; to the uninitiated, it is little more than noise, providing little additional information about the state of a project. This can quickly escalate to be come a problem as well, creating friction between those fluent in the terminology, and those not. Transparency is only achieved if project status is easy to understand. If it requires a crib card or dictionary, it is not all that transparent after all.
In Agile projects, it becomes very important for a top-down approach to identify the project and technical data points that will be exposed. Specifically, focus on what is important to business decisions makers. In the Formula 1 analogy, this could be when will the car be ready to race, how fast can it go, and what race distance can it cover before reliability becomes an issue. In a software development project, this could be what functionality will be delivered, when it will be delivered, and how much transaction volume the application can support in the target environment. Project data beyond this, such as the team capacity, unit test coverage and security compliance of the deliverable, might be appealing and useful to the team itself. However, delivering an overabundance of metrics will simply create noise when communicating with the business.
This leads to an important follow-up consideration. Agile practices lend themselves to quantitative, fact-based, forward-looking assessments of project success. This information, however, is only as useful if it can be consumed. How mature is project portfolio management within the organization? Is there strong business discipline in business case development, sponsorship, staffing and personnel, and budgeting? These are especially important considerations as there can be unintended consequences to operational transparency. A team reporting the status of a project in trouble - due to complication, staff, resources or other factors - might be seen to be uncooperative, disinterested, disorganized, or outright hostile. While forward-looking project data in Agile projects might be founded in fact, the language that is used to communicate it is every bit as important as the information itself. Top-down programs must be particularly active in managing - and even maturing - how the business makes best use of IT responsiveness.
Anticipating the Impact of Change
Although Agile practices may be intuitively appealing, the law of unintended consequences comes into play in a top-down program of change. The reaction to Agile both inside and outside IT may not be as effusive and enthusiastic as a change leader and program sponsor might hope. By making the adoption of Agile practices important, actionable, and clear, the risk of resistance can be reduced and problems in adoption mitigated before they escalate.
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.
Home 
