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.

• 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.

[i] See Martin Fowler's blog at http://www.martinfowler.com/bliki/AgileImposition.html

[ii] See "Management Challenges to Implementing Agile Processes in Traditional Development Organizations," Barry Boehm and Richard Turner, IEEE Software September/October 2005.

[iii] See "What is Agile, Really?" at http://www.gantthead.com/content/articles/234987.cfm

[iv] As defined in Wikipedia http://en.wikipedia.org/wiki/Servant_leadership. Also, see Robert Greenleaf's books including Servant Leadership: A Journey into the Nature of Legitimate Power and Greatness 25th Anniversary Edition.

 {mos_sb_discuss:8} 

Comments (0)

Write comment

Show/hide comment form