Many Agile projects start as grassroots, often surreptitious, initiatives. When successful, team members do their best to publicize their accomplishments and use the project as a baseline on which to launch others. But it is unlikely that these projects can lead to company-wide adoption without support from above. Management from both the business and IT sides of the house must buy into these new ways of building software and must understand the essential differences that Agile processes espouse. Top-down adoption is not about imposing Agile practices from the top down - it's about support from upper management. IT organizations that achieve this level of support are the ones that successfully deploy Agile processes across a wide range of business projects.
In the IT world, using the term "top-down" in connection with management conjures up images of huge Gantt charts with prescriptive (and usually sequential) methodologies. Traditional managers control projects and the development team lives under this control. And, despite following these detailed plans, development teams commonly fail to deliver to management's expectations.
Most Agile developers would shudder at the thought of management driving their initiatives. Squelching a team's creativity and productivity with
Advertisement
overbearing management is the antithesis of Agile development. Martin Fowler has written: "Imposing a process on a team is completely opposed to the principles of agile software, and has been since its inception."[i] But that's not the type of top-down Agile adoption that makes large organizations successful.
Agile processes are intended to empower teams to produce high quality products that meet their customers' needs. Empowerment is the key factor. Therefore, in order for Agile development to scale, management must support this empowerment and focus on leadership rather than control.
Have Answers Ready
In corporate IT shops, Agile processes are typically introduced on a small scale: on a few well-chosen pilot projects with enthusiastic team members and an enlightened customer. But for Agile processes to address broader corporate IT requirements, teams need management behind them. Of course, business and IT managers don't have an easy time making the change to less prescriptive processes. Resistance is common, particularly if managers are threatened or are not well-educated in the why behind Agile processes.
Selling, therefore, is an important component of Agile implementation. A 2004 University of Southern California Center for Software Engineering (USC-CSE) study noted a long list of real and perceived barriers to Agile adoption. Some of the (real) management-oriented barriers included:
Degree of documentation - for planning, requirements, compliance
Risk management
Interfacing/integration with legacy environments
Milestone reviews, cost estimation, resource and project management[ii]
Agile teams must debunk both the real and the perceived barriers. Given these and other management challenges, Agile teams must be proactive and prepare to address the following questions:
How and why will this approach work? For years, developers have presented new methodologies and techniques to improve their software delivery capabilities. Managers have long memories -- of CASE tools, object-oriented programming, client/server architectures, and the other silver bullets that developers have proposed. Ivar Jacobsen recently gave his perspective on why Agile is different. "Most important, agile is about social engineering. This is what actually made agile different. It is about how to work as a team, how to make people motivated, how to collaborate, etc."[iii] Education must include what these new practices entail, why they are or are not significant (don't say radical) changes from existing approaches, and how the team will measure its success.
Regardless of the methodology, development teams must gain support from their business users - otherwise they risk being outsourced or replaced by outside consultants. If Agile teams can communicate how they can deliver value and then demonstrate that commitment in early iterations, the buy-in will follow. Teams must educate the managers and help them move to a new set of metrics that reflect a project's progress towards delivering business value.
How will our existing tools be used? Note that the question asks "how" the tools will be used and not "if" they will be used. Every CIO has a list of (usually expensive) application lifecycle management (ALM) tools that are already in use in the IT organization. Replacing them is rarely an option. Teams must demonstrate how Agile practices work with existing tools, such as supporting continuous integration or test-driven development with legacy SCM or testing tools. These tools may not have been intended to support such iterative and incremental development, but many teams have been successful in adapting their legacy ALM tools to support Agile projects.
Many Agile projects do start with a few open source tools. These, like the projects they support, are under the radar of many managers. Some open source tools, like CruiseControl and Subversion, can easily scale to large and/or distributed projects. Environments like Eclipse can help teams integrate these new lightweight tools with existing ALM components.
How will you fit with our governance program? To address industry compliance regulations and internal corporate governance initiatives, all projects must provide appropriate levels of process compliance and transparency. By definition, Agile projects provide frequent information tied to the iteration schedule. Many projects are turning to management tools - from traditional project management vendors or new Agile providers - to communicate status and value-oriented metrics.
Probably the biggest misconception for managers is that Agile projects do not provide sufficient documentation. Working code is the highest priority, but that does not preclude providing associated documentation (e.g., test plans, requirements) along with the code.
How will you work with the PMO? This could be the toughest question to answer. Small steps are necessary, especially in large organizations where the project or program management office (PMO) has oversight for portfolio planning, resource allocation, and project monitoring and reporting. Some development teams start by seeking out managers who are tolerant to change, and then enlisting those managers' help in educating others in the PMO.
The classic IT project management community is not in the dark, but isn't off to a great start either. Gantthead.com, the popular site for project managers, has an "Extreme Project Management" department. But this department wants to help managers "succeed in keeping today's new breed, change-driven projects under control." This misses the point! The goal is not to let managers feel that they're still in control, even though the developers have changed the way they work. Managers must relinquish the classic control mindset and adopt a more collaborative leadership style. But they must be convinced that Agile approaches can, in fact, produce impressive results.
A number of Agile experts offer training in servant leadership. This type of management "... emphasizes the leader's role as steward of the resources (human, financial and otherwise) provided by the organization. It encourages leaders to serve others while staying focused on achieving results in line with the organization's values and integrity."[iv] Approaching change from a servant leadership perspective can be an effective way to educate traditional managers. And, if the PMO is also responsible for defining and rolling out standard processes, IT teams can turn this into an opportunity.
Build On Agile Success
At the end of the day, successful projects will "sell" managers on any new approach. Agile teams really need to invest in a good PR strategy - one that's understood by their business partners and not just by IT staff. Turn the conversation around to focus on business benefits, including:
Business competition. Faster time to market for new products will improve the company's competitive positioning and ultimately affect the bottom line.
Reduced risk. Shorter iterations means quicker customer feedback. At the very least, problems will be identified quickly.
Reduced costs. In many cases, Agile teams deliver partial solutions that effectively address the customer's needs - without having to implement the full set of perceived requirements.
Enlightened management. Companies that make the change to servant leadership find their entire organization, not just the IT group, to be more agile.
Top-down management support may not be necessary for individual Agile projects, but it is essential for wide scale Agile adoption. Start building this momentum when you launch your first Agile project.
About the Author
Liz Barnett is the Editor in Chief of the Agile Journal and Principal
Analyst at EZ Insight Inc. Previously Liz spent 10 years as a Vice
President and Research Analyst at Forrester Research, joining Forrester
as a result of its acquisition of Giga Information Group. Liz held
management positions at Accenture, PepsiCo, and Atelier Research. She
also was the Research Director for the advanced software development
and advanced network computing research services at New Science
Associates, prior to its acquisition by Gartner Group. Liz holds a
patent for developing a distributed application development/CASE tool.
Liz earned her B.S. in operations research and industrial engineering
at Cornell University.
[ii] See "Management Challenges to Implementing Agile Processes in Traditional Development Organizations," Barry Boehm and Richard Turner, IEEE Software September/October 2005.
