An Agile Approach to Project Management

Leveraging Agile Practices to Improve PMO Effectiveness

Liz Barnett EZ Insight, Inc.
February 2009

ww w.thought wor ks. com/m ingle

02

TRANSFORMING PROJECT MANAGEMENT

Agile processes help teams improve productivity, project costs, software quality, relationships among business and IT decision makers, and value delivered to the business. Steadily, IT organizations are increasing their adoption of Agile practices on mainstream software development projects in terms of both project size and geographic distribution. Yet despite individual project successes, the project management organization (PMO) is not prepared to accommodate Agile projects into its existing landscape, particularly in the areas of metrics and reporting. Its top-down budgeting and planning processes do not align with the short delivery cycles, customer-driven prioritization, and continuous evaluation of requirements that characterize Agile projects. Not only must organizations address this friction between the PMO and Agile IT projects, they should take advantage of Agile projects experiences and adapt into a 21st century management organization. Just as IT execution has evolved, so must the PMO. The PMO is a centralized resource for IT project teams and a vehicle to monitor and deliver a wide range of projects with defined goals and timeframes. The PMO has three broad sets of responsibilities: (1) resource management, including staff competencies, assignment, and capacity planning; (2) metrics and reporting requirements, and their fit within corporate governance programs; and (3) definition and standardization of capabilities including project implementation and delivery processes, training, and other project support services. Project managers must consistently communicate to and report on projects across business units and development methodologies. Given the breadth of projects within a CIOs control, it is not surprising that the PMO is often heavy-handed, imposing a strict approach to metrics and guidance across all projects. Typically, PMO metrics are not consistent with the work of Agile teams, so the teams are unable to communicate project management data on which the organization can act.

This paper explores two important phases in the transition to Agile project management:
1. Providing a context in which Agile projects can co-exist with traditional projects, under the auspices of a centralized PMO, and simultaneously add value. 2. Leveraging Agile practices to improve the PMOs effectiveness across all projects.

EXAMINING THE ROLE OF THE PMO

Increasingly, the PMO is responsible for project success. To ensure delivery of projects spanning platforms, architectures, and processes, the PMO must have visibility across the company. How effective is the IT organization? How can project teams improve their productivity, quality, or delivery costs? Are projects delivering value? In this market of shrinking budgets and global competition, the PMO is a central participant in these discussions. The advent of Agile processes and their emphasis on continuous reprioritization and adaptation further complicates its role.

www.thoughtworks.com/mingle

03

Among the many responsibilities of a PMO, four have the greatest impact on Agile project teams:
1. Administering common project reporting for all stakeholders and supporting project, IT, and corporate governance. 2. Providing knowledge transfer in the forms of training, mentoring, and best practices to IT project teams (frequently termed a Center of Excellence). 3. Defining and instituting standards for project management and development processes. 4. Facilitating team collaboration via common metrics, processes, deliverables, shared resources, etc.
Agile projects must participate within the PMO infrastructure, especially when they constitute only a small percentage of the project portfolio. This requires willingness on the part of Agile team management to conform to (at least externally) traditional management practices. But not only must the Agile project adapt: the PMO must as well. It will benefit from Agile projects ability to accurately measure the status of a project and adapt to changing requirements.

Problems with Todays PMO

In some companies, the PMO functions as a gatekeeper across IT projects rather than as a collaborator. Instead of facilitating cooperation among teams and shared resources, it is relegated to an auditor of standards and a vehicle for communicating to CIOs and business partners. This creates a myopic view of current and planned projects; dashboards are limited to very basic metrics and do not convey an accurate picture of complex projects status. Legacy PMOs track project schedules, budget, issues, and risks, with data largely fed from project tracking tools. ThoughtWorks Client Principal Ross Pettit called this metric-driven management and notes that in this model time is the fundamental unit of measure for determining team progress.1 Managers track time and cost estimates for finely-grained tasks, and dependencies among tasks across phases of the lifecycle. On these projects, hand-offs of tasks from phase to phase create miscommunication and therefore the need for reworkinvalidating original estimates and increasing project risks. Pettit put it simply: This is the disparity of IT project management today: IT measures expenditure in hours, but the business isn't buying hours, it is buying software. IT shouldn't concoct indicators that assess where development might be, it needs to measure where it is.2 Traditional methodologies are ill-equipped to provide that measurementwhat Pettit has called management-driven metrics.

The Agile Disconnect

Further complicating the PMOs job is the widespread distrust of Agile processes. The impression that Agile teams are undisciplined, non-SOX compliant, and poorly managed lives on in many organizations. Of course, those assumptions are false: Agile teams are, in fact, highly disciplined, well-managed, and able to provide extensive data to fit with SOX or other regulatory requirements. To prove their merit, Agile teams must communicate effectively, by using language and metrics that the business can appreciate. In addition, Agile teams cannot operate in a vacuum.
1. See Management-driven Metrics Versus Metrics-driven Management, http://www.agilejournal.com/articles/the-agile-manager/management%11driven-metrics-versus-metric%11driven-management.html 2. Ibid.

www.thoughtworks.com/mingle

04

Certain PMO deliverables, such as detailed documentation on regulatory requirements, may be non-negotiable even if they seem excessive or contrary to Agile project-level principles. The greatest disconnect between Agile and traditional projects stems from Agile teams seemingly incongruent project metrics. Within an Agile project, teams report on velocity (rate at which teams deliver business value), burn charts (trends in remaining effort or task completion), test coverage, and running tested features (features delivered to the business). These are excellent measures of the teams progress towards high quality delivery, and align with the business need to respond to global competition (see Figure 1). But business still demands time, budget, and risk analysis information. It is not difficult for Agile teams to identify and bridge this reporting gap. Then, over time, project teams can work with the PMO to transform management practices to become more responsive to change.

Figure 1: Sample Agile Project Dashboard

TRANSITION PHASE I: LEVERAGING AGILE PROJECTS VALUE

The need for standards, collaboration, knowledge transfer, and reporting exist regardless of whether a company has instituted a formal PMO or a decentralized management function. And, most firms PMOs do address their organizations requirements. Initially, Agile teams must comply with existing PMO dashboards and should contribute proven Agile practices to the PMO knowledge base. As these projects join the heterogeneous project portfolio, the PMO will benefit from more accurate reporting and an enriched library of practices to apply to other projects.

www.thoughtworks.com/mingle

05

Comply with Existing Dashboards

All projects have budgets, resources, requirements, and deliverables supporting the initiatives business case. The typical PMO dashboard includes high level indicators (e.g., red/yellow/green bars) and Gantt charts tracking projects budgets and costs. Theres nothing inherently wrong with traditional PMO metrics, noted Dave Whalley, ThoughtWorks VP, Global Delivery Assurance. The organization needs to know the status, issues, and risks for funded projects. Metrics such as earned value analysis (EVA) and cost to complete are certainly valuable to all stakeholders. These traditional dashboards track relevant metrics, but that does not mean they are reporting accurate data. Waterfall projects start with a fixed set of metrics. Teams feed data to the PMO manually or by generating reports from project and portfolio management tools. However, as projects progress, reality sets in: requirements change, issues arise, productivity lags. Most organizations have experienced managers with projects that appear to be on track for weeks on end, only to alert management to schedule delays at the proverbial eleventh hour. Project managers then revise their metrics, often based on their gut feel, and try to determine how far off track they are from the original plan. On large projects with long release cycles, its not surprising that this data is frequently suspect. Agile projects have the benefit of more accurate reporting. By breaking requirements into small units of work (stories), teams can monitor them through the lifecycle and easily obtain a factual view of progress (see Figure 2). Short, commonly two week, cycles force frequent feedback to management and stakeholders, and thus prohibit the team from going too far off course. Units of work are measured in binary terms: they are either complete or not complete. There is no concept of estimate to complete for an individual tasksuccessful test execution determines status and no partial credit is given to work in process. The baseline data provides more precise information to the PMO. However, it is the Agile managers responsibility to transform the teams metrics into those in the PMO dashboard. If the Agile project has created a hierarchy of work units (e.g., release iteration story task), the manager can aggregate data to feed the PMO Gantt chart. An estimate to complete could be computed from data for 60 of 100 story points, or five out of 10 iterations, that have been completed. Increasingly, project teams are capturing this data in an Agile toolset, although initially teams may need to track the data manually. For example, a global provider of integrated hardware, software, and services was initially stymied by the friction between its PMO, which demanded status in terms of person-days and dates, and its Scrum teams, which estimated work as stories and tracked by team velocity. The onus was the ScrumMasters to derive required days and end-dates, by computing average team velocity (incorporating overtime, vacation days, etc.), story backlog, and remaining sprints. Similarly, release managers (part of the development team) at a virtual online marketplace addressed this translation requirement by calculating a standard-costs-per-story-point metric and thus communicating to the PMO on its terms of days and dollars. After two years of experience and frequent touchpoints with development teams, the PMO staff do not use dashboards containing burndowns and iteration plans, but have become comfortable with the concept of story points as the basis for their metrics and with having less detail in iteration plans.

www.thoughtworks.com/mingle

06

Figure 2: Providing Accurate Data to the PMO

Along with transforming metrics into PMO standards, Agile teams must comply with other legacy requirementswithout disrupting the day-to-day activities of team members. In a large U.S. investment bank, the PMO required specific metrics measured against budgets and dates, as well as comprehensive documentation to satisfy the companys regulatory compliance. Agile teams met the metrics requirement by managing a story card wall, updated after each daily meeting. Team leaders computed team status from velocity and burndown charts, and reported against PMOs high level milestones. The manager recognized the overhead required to create the compliance documents and took steps to insulate the team by staffing additional resources for this task. Legacy integration also forces some transformation. Agile teams building new capabilitiesregardless of their processes and metricsare often required to follow parts of the legacy SDLC or use standardized tools. For example, in a Top 10 U.S. retail bank, all eCommerce projects contain large mainframe components. The banks standards and policies required the use of a standard defect tracking system and a single generated report containing all severity one issues in production and development for every project. In a medical systems company, all teams were required by auditors to use a standard requirements management tool to provide traceability of delivered capability. In this case, Agile project managers adeptly built in links from the teams lightweight story tracking tool to the legacy toolset, so the team wasnt burdened by the additional overhead.

www.thoughtworks.com/mingle

07

Share Proven Agile Practices

Skills development and knowledge transfer are important roles within the PMO. These programs may be formal or informal, depending on the organizations budget, culture, and priorities. Agile teams should focus on selling the benefits that they have achieved and contributing best practices to the PMOs shared resources for use by subsequent projects. In many cases, Agile teams have retained outside expertise for training and mentoring. Over time, these teams experiences and best practices can become part of the broader portfolio as well. An IT manager of eCommerce applications at the aforementioned retail bank considered his people to be the key to Agile success, and budgeted training accordingly. One business unit hired a third-party ScrumMaster to mentor teams and quickly build internal skills. Team successes gained attention across the organization and the ScrumMaster was asked to present Agile project management techniques to the entire PMO. Now, the PMO is reflecting on its current requirements and starting to apply Agile management practices to legacy teams work.

TRANSITION PHASE II: CREATING A MORE EFFECTIVE PMO

The overall mission of the PMO should not change, but it can certainly benefit from the experiences of large and distributed Agile projects and become a more efficient and effective asset to the business. To do so, the PMO must scrutinize its process and metrics standards and address its ability to communicate with and foster collaboration among teams.

Create Valuable Metrics and Standards

The greatest benefits from Agile projects lie in the area of business metrics. In addition to measuring IT data, such as schedule or budget overruns and test coverage, Agile projects track and communicate metrics that are relevant to business goals. These include not only business value, but also customer satisfaction and risk management. Agile teams have the ability to supplement and eventually change the metrics reported to the PMO. Agile projects begin by addressing the customers highest priority features. Features tie to business benefits, and thus teams can report on benefits or value delivered and not just days completed on a project plan (see Figure 3). ThoughtWorks Pettit noted additional benefits of Agile metrics. There is a strong foundation for forecasting: the date and cost of future development can be predicted from the rate at which work has been historically delivered. Progress is reported in a meaningful denominator to the business: functionality (expressed as stories) as opposed to effort (expressed as hours).3

Figure 3: Measuring Value Delivered Over Time

3. Ibid.

www.thoughtworks.com/mingle

08

In addition to metrics, Agile teams have the ability to impact the PMOs process standards. Companies establish and fund PMOs to administer accepted business management and governance requirements. Agile projects may provide the catalyst for the PMO to reflect upon its existing functions and determine which should be kept, changed, or retired. In one banking organization, for example, input from Agile projects led the PMO to identify unnecessary and redundant documentation requirements (in this case, those that were not tied to regulatory requirements) and cut that which was not necessary. Other organizations have enhanced their testing tools to create documentation from automated tests and thus satisfy existing requirements in a new way. Yet other PMOs have instituted architecture-independent processes based on Scrum practices. In adopting these types of changes, the PMO becomes the vehicle to communicate not only best practices, but also templates and specific examples from past projects.

Enable Collaboration

There is a direct correlation between the degree of collaboration on a team and the teams ability to achieve agility. Collaboration among team members is critical to both problem definition and resolution, particularly for teams addressing frequent changes in short delivery cycles. It is essential that project managers focus on effective interpersonal communication and foster collaboration for developers, testers, business stakeholders, and other team participants.

An Agile Approach to Project Management Leveraging Agile Technology plays Practices to type of team culture. For co-located teams, the a key role in supporting this Improve collaboration solution may be a mix of physical artifacts (e.g., post-its on a white board) and PMO Effectiveness technology (e.g., team wiki for persistent discussions). But as companies form distributed teams,

the requirements for technology-based solutions increase. Teams need real-time collaboration (e.g., instant messaging, videoconferencing), flexible programming environments (e.g., distributed Liz Barnett SCM and build management), and visibility into all project artifacts and metrics (e.g., shared EZ Insight, As repository and dashboard). Inc. companies emphasize collaboration, they also need to de-emphasize non-critical tasks. Data must be collected seamlessly, without impeding the teams productivity or disrupting communication. Developers should not have to halt their daily activities Juky 2008 to enter status data into secondary tools. This is an issue that has plagued development teams for decades; the advent of short iterations makes non-intrusive metrics collection even more critical. Collaboration is not unique to Agile development, but Agile teams bring these requirements to the forefront. They are staffed with heterogeneous skills, have inflexible timeframes, and, like any other team, require access for IT and business management to projects issues and risks. Their emphasis on collaboration should pave the way for non-Agile projects to also improve productivity and quality.

INCREMENTAL STEPS LEAD TO MANAGEMENT GAIN

At its core, transition to Agile project management depends on two things: effective collaboration and rapid readjustment. Collaboration entails access to a wide range of project data and assets, beyond that which is managed on legacy projects, and productive communication among team members. Rapid readjustment requires both an accurate assessment of current status and the ability for team members to quickly resolve issues and change course as appropriate. The PMO can play an important role in both of these areas. Its effectiveness will improve as it expands its role and incorporates Agile projects into its current responsibilities. But to truly benefit the organization, the PMO must incorporate Agile approaches and experiences into its responsibilities. That is the essence of Agile project management.

www.thoughtworks.com/mingle ww w.thought wor ks.com /st udios

09

ABOUT THE AUTHOR

Liz Barnett is the Principal Analyst at EZ Insight, Inc., an analyst and consulting firm focused on global software development issues and technologies, founded in 2005. In 2006, she also launched the Agile Journal, an online publication providing in-depth analyses and case studies for Agile developers and managers, and was Editor in Chief for its first two years. 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 has held management positions at Accenture, PepsiCo, Atelier Research, and New Science Associates (subsequently acquired by Gartner Inc.). Liz earned her B.S. in operations research and industrial engineering at Cornell University. This report is the result of research underwritten by ThoughtWorks and developed by EZ Insight, Inc. The analyses and findings are derived from EZ Insights independent views.

2008 EZ Insight, Inc. All rights reserved.

Mingle: The Agile Project Management software from ThoughtWorks

Mingle, the intuitive and flexible Project Management Tool, provides one shared workspace for the entire team. Give Management true-to-life visibility into project status with a clear picture on what work has been completed and what is yet to be done. Leverage the industry's best user interface to capture and visualize all project activity. Track project progress with out-of-the-box reports (like burn-down charts, velocity, etc). Mingle leverages ThoughtWorks' 7+ years of experience in world-class Agile delivery.

www.thoughtworks.com/mingle