Agile Journal - Sell Your Agile Successes

Home

Write for Us

Sell Your Agile Successes

Written by Liz Barnett

Tuesday, 08 April 2008

Agile teams must be the champions of their own success. Self-promotion is not only important to building credibility and management support, but it is also a key component of compliance with corporate governance initiatives. By providing transparency into projects' status, issues, and risks, Agile teams will deliver value to IT and business partners and a vehicle for improving non-Agile teams' management.

Instead of selling the benefits of some new development or management process, Agile teams need to sell what the business wants:

Quantifiable business value, not working code.
Frequent delivery of customer-driven requirements, not long (or endless) development cycles.
Reduced costs, not budgets achieved by sacrificing quality.
Risk management through effective communication and problem resolution, not audits.
Real-time visibility into projects' status, not delayed or inaccurate reporting.

By proactively communicating progress and success, Agile teams will be able to turn the conversation with management from one of deadlines and overruns to one of benefits and value. There are two major components to this strategy. First, teams must dispel the myths that surround Agile processes, even after almost a decade of use. Only then can teams begin educating their organizations on Agile benefits. Second, teams must communicate status by conveying value, rather than the traditional modes of reporting cost and time data that rarely reflect a project's status. The concept of promoting team success and a variety of business metrics should be a core goal for Agile teams in 2008.[i]

Selling the Benefits, Dispelling the Myths
Negative perceptions still surround Agile development and management processes. Many of these stem from either a perception that Agile processes are undisciplined and random, or the assumption that since requirements are not entirely defined up front, there is no way to measure or manage a project's progress.

In a number of Agile Journal articles, our contributors have discussed common myths applied to Agile projects and how teams were able to dispel these myths. Chief among them are assumptions that Agile projects lacked scope control, scalability, commitment to testing, and the ability to fit with current management practices.[ii]

Agile teams must assume that these biases exist and be proactive in educating management and their business partners of these inaccuracies. Preaching about processes won't cut it; Agile teams must develop communication programs that demonstrate Agile values with concrete examples from their projects and address objections head-on.

Agile teams must also drive education throughout the organization. Teams can draw upon the leading Agile consulting firms and tool vendors, whose businesses rely on communicating benefits in terms that the business will believe. The Agile University, working with a number of different vendors, offers a wide range of courses for beginner and experienced teams. For example, "Agile Project Management: Innovation in Action" helps managers transform their project planning and management approaches to incorporate customer-driven requirements and frequent change and feedback. The "Collaboration Explained" workshop can help Agile project leaders and team members create a collaborative team environment that can deliver value and resolve conflict.

Communicating Benefits, Not Data
The pressure to provide transparency into project teams' status is pervasive, and is in no way specific to Agile development. Governance initiatives, whether driven by regulatory requirements or internal audits, are at the top of CIO's lists and all projects must comply. In some organizations, the project or program management office (PMO) sets the standards for teams' compliance, but these requirements may also come from business units or internally from the CIO. Regardless, Agile teams must provide the same information as is demanded of non-Agile projects.

The management dashboard is an important component of any communication strategy. Most teams will be forced, at least at first, to feed project information into an existing management dashboard that tracks projects' progress (dates and costs) and risks.

It may actually be easier for an Agile team to participate in these initiatives. Even though the metrics within an Agile team are different from those on traditional IT projects (e.g., velocity of team progress; burn charts to reflect remaining and completed work), they actually contain the information that is most relevant to project management. For example, progress against plan or budget is the most commonly reported metric to a PMO. On an Agile project, individual features (stories) are either done or not done - there is no need for teams to compute an intermediate "estimate to complete." So when aggregated to the project level, the data coming from Agile teams will be a better reflection of the project's status, than data estimated from a team a legacy process.

Over time, Agile teams have the ability to change the overall management dashboard by educating management and non-Agile teams on different types of metrics that may better reflect a project's benefits. The most important change here will be to measure and communicate value created by a team's deliverables. Teams will adopt metrics that truly measure a team's ability to deliver business requirements, and thus value to the business. "Not only can you prioritize the features you release based on the value the user will receive, but you will also have quicker access to post-release information to best derive business value."[iii] Some Agile teams have also begun tracking customer satisfaction metrics, thus transforming the management dashboard to more of a business scorecard.

In addition, the Agile team's emphasis on collaboration and team ownership is a concept that should make its way into management communication. "Team ownership - and thus team "credit" for completed work - must override any individual accolades. Individual expertise should not be ignored, but cannot dominate as is the case in most traditional projects where heroic efforts by specific staff tend to hog the glory."[iv]

It still comes down to dollars and days, but when a team can articulate the value delivered in those dollars and days, business will achieve far more than high quality code. Delivering business value, as measured in business revenue, stock price, market share, or other business metrics, must be the ultimate goal of any Agile initiative.

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 earned her B.S. in operations research and industrial engineering at Cornell University.

[i] In the December 2007 issue of the Agile Journal, I defined four goals that will be key to Agile adoption in 2008: investing in staff, adopting practices incrementally, leveraging existing assets, and publicizing successes. Previous articles have discussed the first three of these goals.

[ii] A number of Case Studies and articles in previous issues of the Agile Journal discuss common myths. See articles in the Case Study section as well as the Agile Manager column for good examples.

[iii] The concept of measuring business value has been discussed in a number of Agile Journal articles, including "Agile Projects Must Measure Business Value," http://www.agilejournal.com/articles/from-the-editor/agile-projects-must-measure-business-value.html

[iv] See "Collaboration Circa 2007" for more on strategies for effective collaboration and communication, http://www.agilejournal.com/articles/from-the-editor/collaboration-circa-2007.html.

Comments (0)