Fp Martinelli Graykowski

PM World Today – June 2010 (Vol XII, Issue VI)

© Copyright 2010 by the Program Management Academy and Steve Graykowski

PM World Today is a free monthly eJournal - Subscriptions available at http://www.pmworldtoday.net

PM WORLD TODAY – FEATURED PAPER – JUNE 2010 Agile Program Management: Separating Practice from Myth

By Russ Martinelli & Steve Graykowski

The business climate in which many companies operate today is changing so rapidly that within a short period of time, both business goals and the project execution plans that support those goals can change dramatically. In some businesses, if six months pass without a significant change to plans, there is a high probability that something was missed during planning. Therefore, there is a high probability that something will be missed in project execution and the project outcomes. This scenario is a fact of life in any business where software development is a key component of product or service development. The challenge that this environment creates is the need to be able to respond quickly to the changing climate and customer needs, while at the same time being able to maintain a level of structure to keep work output aligned to the company’s business goals. This is where Intel and salesforce.com have found value in implementing an Agile Program Management approach to their software development endeavors. Unfortunately, there exists a serious misunderstanding of Agile Program Management and how it is implemented and practiced within organizations. It is quite common for Agile Program Management to be confused with agile project management as well as with traditional portfolio management practices. This paper will help to clarify some of these misunderstanding by describing and demonstrating how Agile Program Management is practiced. Specifically, we demonstrate how program management practices enable an agile-centered software development organization to consistently deliver higher-complexity solutions while keeping the solution outcomes aligned with the top business goals of the firm. Additionally, we demonstrate how agile methodologies enable a program management-centered organization to be more responsive in providing solutions and value to its customers. Demystifying Agile Program Management Both agile software development and program management practices have proven to deliver business results. Agile software development adds value to the business by quickly and continuously delivering product features to one’s customers. Program management provides continued focus on business results and the coordination of multiple project outcomes toward the achievement of those business results. By combining the two practices, one gains a powerful solution delivery system that helps keep product or service development teams focused on business goal achievement, yet remain flexible to customer and market changes. This is especially true as solution complexity increases.




As products and solutions grow in scope to meet the ever-increasing needs and demands of users, the size and complexity of the development efforts required to produce the products and solutions grow proportionately. There comes a point for every organization when managing development efforts as a single project (agile or non-agile) is no longer feasible. When this point is reached, development of a product or solution has to be disaggregated into multiple projects and managed as a program. However, traditional program models rely heavily on up front planning, consume a lot of effort managing variation to the plan, and are slow to respond to customer and user changes. Agile Program Management on the other hand provides a flexible program-level framework that is responsive to customer’s changing needs. It anticipates and encourages change by relying on built in feedback loops that enable teams and customers to collaborate. Agile development organizations rely heavily on customer involvement and bottom up planning and execution. As product and solution complexity increases, the more likely it becomes that bottom up planning and continuous customer change will create a disconnect between execution output and the business goals of the enterprise. This is even more likely when business conditions change while execution teams remain focused solely on delivery of customer requirements. Agile Program Management uses many of the empirical practices of agile development while keeping a rigorous eye on the business outcomes. Agile programs use most of the same constructs that traditional programs use such as focusing on business goals, managing business risk, and project interdependency maps to name a few. But the manner in which the program team operates is consistent with agile principles. The cornerstones of agility - alignment, collaboration, transparency, and cadence - are also applied at the program level. The difference is that Agile Program Management delivers business value early and often through the life of the program while maintaining continuous focus on business goal achievement and integration of multi-project outcomes. Alignment: Business goals provide the basis for establishing alignment among the project teams associated with a program. When multiple agile project teams are needed to create the various elements of a large-scale product, a common mission has to be in place to continuously align the work and outcomes of each of the teams. The business goals driving the need for a development effort, along with high level customer requirements, are grouped and driven at the program level, delegated to the agile project level via the release planning process, and then used as the measure of success for each of the agile projects and the program as a whole. It is through this process that alignment is achieved. Collaboration: On any program, a high level of collaboration is required due to the cross-team interdependencies that exist. Agile programs are no different. The agile project teams need to collaborate with each other to validate assumptions, determine and track cross-team commitments, and fully understand the program business requirements. Collaborative methods include release planning, sprint reviews and retrospectives. Release planning involves the whole team in estimating the product backlog, deriving an understanding of the business requirements,




and determining the final priorities. Sprint reviews create an opportunity for stakeholders to interact directly with the program team to validate and touch what was developed. Retrospectives are used to improve the development process and are a key tool for agile teams to increase throughput. Cadence: The cadence of work and outcome delivery is set at the program level and aligned to the cadence of the organization as a whole. Each team may have different iteration lengths, but they need to be synchronized at regular check points so that iteration planning and reviews can be held at the same time across the whole program. These sync points are also used to set expectations with stakeholders to keep them informed and actively engaged with the program. The release cadence creates integration points for all teams to assemble and stabilize program components, examine feature completeness, address blocking issues, and examine dependencies. Transparency: There’s a saying in the agile community, “If it smells bad, that's a good time to act”. Agile teams do not fear bad news because they understand that the sooner an issue or blocker is realized the cheaper it will be to fix. Transparency also means that the whole program can see and touch what is in development early and often. This provides stakeholders with enough information early in the cycle to validate the business case and make any course corrections when necessary. Integration: With multiple agile project teams working concurrently to develop and deliver a product or solution, integration of work output from each of the project teams is a critical component of Agile Program Management. It is the integration of work output that requires a top down approach to product or solution definition, as the sum of the parts must equal the whole product. As the agile project teams pull from the list of business objectives and customer requirements to establish team level product backlogs and release plans, it is the combination of all the team level release plans that constitutes the program’s overall release plan. It is the program management function to ensure that the outcomes contained in the program releases integrate effectively to create the intended product or solution. Aligning Agile Outcomes to Business Goals One of the primary principles of Agile Program Management is that the iterative outcomes from agile project teams consistently contribute to the achievement of the business goals. Any product development effort – agile or non-agile – is ultimately about achieving a firm’s business goals. The benefits that agile software development methods bring to an organization are well documented and include the following:

The ability to realize return on investment quickly; The ability to rapidly adjust to changes in the environment; The ability to quickly respond to customer needs; and Reduction of risk due to exposure of problems early in the development cycle.




In order to realize the benefits above, most organizations implement agile at the development team or project level. However, many companies (including the companies we work for) have come to realize that agile software development, especially with the use of Scrum and XP, results in a product that is developed from the ground up. The whole, or integrated product, becomes a collection of project outcomes that, when aggregated, may or may not represent the true intent of the product vision. Let us look at this problem from an enterprise perspective. The development of a firm’s products or services represents the means to attain a set of business goals. If project outcomes become misaligned with the product or service vision during project execution, the result will be a misalignment between the desired business goal outcome and the actual outcome (Figure 1).

Figure 1: Misalignment between business goals and execution output

There can be many causes for this misalignment, three of the most common that we have encountered include the following:

Not all requests for changes from customers are in alignment with a firm’s business goals. In fact, some changes may be in direct conflict with the business goals. Implementation of these changes at the project level steer a product away from goal attainment.




If agile sprints and releases are time and resource constrained, any de-scoping decisions needed to keep a sprint or release on schedule may result in elimination of critical features that deliver the product vision and business value.

To fully succeed from a business perspective, there must be alignment from business goals to daily agile project outcomes. As Figure 2 shows, alignment begins with a set of business goals that the firm is trying to achieve over a specified period of time. The product vision must support attainment of the business goals along with the roadmap of product releases into the market. From an execution standpoint, agile releases, sprint outcomes and daily outcomes must all support the product roadmap. When this occurs, alignment is achieved between the firm’s strategic business goals and its execution outcomes.

Figure 2: Alignment between strategic goals and execution outcomes One of the primary benefits of implementing program management within an enterprise is that it serves as the glue that bonds execution outcomes to business strategy. Program management is strategic in nature and business focused. With Agile Program Management, the program manager is responsible for championing the business goals driving the need for a particular product development effort. He or she helps accomplish the attainment of the anticipated business goals from a leadership position in which multiple agile project teams operate to




produce the outcomes necessary to deliver the business goals. Figure 3 illustrates the Agile Program Management model graphically.

Figure 3: Aligning Agile Outcomes to Business Goals

Agile Program Management combines top-down business strategy with bottom-up iterative development and delivery. It begins with the identification of the strategic business goals by the senior leadership team of the firm. Strategies, in the form of products and services, are then developed and assigned to program managers to develop and deliver. Delivery is accomplished through the formation of multiple agile projects, each chartered to develop and deliver its appropriate portion of the product or service. The role of the agile project managers (Scrum Masters if using Scrum) is to manage the iterative creation and delivery of their portion of the product. The role of the agile program manager is to provide coordination, guidance, and leadership to the agile projects to ensure the iterative outcomes stay aligned to the business goals throughout the duration of the program. Additionally, the agile program manager, in partnership with the product owner, is responsible for insuring customer feedback is continually being received and acted upon.




Scaling Up to Meet Product, Business, and Organizational Complexity To truly represent the complexity that exists in product development, the attainment of any single business goal may require multiple product launches, each of which may be comprised of multiple software releases, and each software release may aggregate the outcomes generated from multiple cross-organizational agile project teams. This multiplication effect results in increasing levels of product and organizational complexity as a firm’s products become more sophisticated, feature-rich, and entrenched in the marketplace. When this occurs, many companies come to realize that their agile software development methods alone do not scale adequately to resolve this higher level of product and organizational complexity. Companies such as Intel and salesforce.com have found that the powerful combination of agile software development and program management practices provides the necessary scalability needed to create product development flow. Processes from planning through development and deployment can be scaled across many teams and ongoing software releases with agile program management and a synchronized organizational cadence. There are many ways to scale an agile organization depending on how the enterprise and teams are organized. A highly matrixed organization versus a strong line management organization, for example, have starkly different processes and management chains of command that need to be observed and respected. There is not a single, best approach to scale up an agile organization so the approaches described here are merely meant as noteworthy practices seen in organizations such as salesforce.com or Intel. These practices have been proven to work well in these cases and may be adapted by other organizations. Let’s start by examining the product development processes in an agile environment. Figure 4 shows an iterative planning cycle starting with Portfolio Management and ending with Release Management.

Figure 4: The Agile Management Cycle




Product capabilities are prioritized by product management and vetted across product lines. Product line managers collaborate at this stage and are focused on conceptual product design. This process serves to create a cohesive unified system with a consistent look and feel. Product features are also discussed and challenged with regard to business value. The outcome is a calibrated product backlog that is in complete alignment with the overall business goals. Program planning starts with a clear picture of the business goals used as input to integrated release planning. At this stage it is important to note that not all implementation details are known, but enough information has been gathered about the product so that resources can be allocated and agile project teams created based on business goals, product features, and major dependencies. Each agile team now has a good understanding of the project goals and features and establishes their team release plans, affirms dependency timeframes and adjusts overall priorities based on more detailed understanding of the product backlog. At this stage, the project team determines how many iterations are required to deliver the release plan. Development activities occur incrementally and continue until the release goals are met. The end of each iteration marks the point where agile project teams and the overall program team look back and retrospectively determine what changes need to be made to the plans, processes or even to the product itself based on what was just developed in terms of a potentially shippable increment. These iteration reviews represent excellent opportunities for stakeholders, customers and agile program teams to examine the working product, review planning assumptions, and recalibrate the product backlog to changing customer needs and business goals. Each agile team in the program stays aligned through regular roll-up coordination points facilitated by the program manager. These meetings create opportunities for agile teams to collaborate at the business goal and architecture level to address issues blocking progress. Cross functional representation from other parts of the organization that are potentially impacted by the work in progress also participate at this stage and may include functions such as engineering, user experience, release management, documentation and quality assurance. In addition there are program level core team meetings to monitor and manage program risk, review overall progress, and establish transparency for executive stakeholders. The program core team is responsible for keeping agile project teams focused on the development goal and helps to protects them from outside distractions. Agile Program Management at Intel Since Intel takes a systematic approach to product development, traditional program management is well established and practiced. However, due to the need for product feature flexibility, software development is becoming a more centralized activity where features are developed and delivered at both the integrated and discrete product level. This need for flexibility in feature delivery, coupled with the continued requirement that the software needs to be developed and integrated as part of an overall system prior to delivery to ensure proper




performance for the product end user has created the need to move from the traditional program management approach to Agile Program Management. Figure 5 demonstrates the Agile Program Management environment from a product roadmap perspective. In this example, two product lines are shown, each with a product line manager in charge of a respective product line, and program managers in charge of the development and launch of individual products within the product line. The product line manager ensures the product vision is set and remains aligned to the business goals driving the need for the product line, while the program managers ensure that the integrated and discrete software products are developed and delivered in alignment to both the product vision and business goals.

Figure 5: Example Agile Program Management Environment Within the Agile Program Management structure, the agile software development and release cycles are an on-going process. In this example, releases occur on six-week increments and each release is comprised of either two or three sprint outcomes. Sprint duration is determined by feature content needed for coming releases. The program manager leads the product core team comprised primarily of the agile project managers, release manager(s), product line manager, and other functional representatives determined by the various elements of the integrated product being developed. The program manager coordinates the work of multiple project teams to ensure that the work is aligned and aggregates in a product release that delivers the software features required for product launch. Follow-on market releases provide additional features to Intel’s customers. By using an agile program management approach, Intel’s customers gain value between product launches by having access to the latest new features through the market releases.




The role of the program manager has changed as this organization has moved from a traditional program management development model to Agile Program Management. The most dramatic change in the role involves a transition from command-and-control leadership to influential and collaboration-driven leadership. Agile Program Management at salesforce.com Agile Program Management at salesforce.com emerged from the need to manage large strategic initiatives and grew out of established agile software development practices. Salesforce.com is a cloud-computing company that provides a customer relationship management service and an application development platform. Since its inception, salesforce.com has been a development driven organization that started out by relying heavily on the output of a small number of teams managed by a centralized management chain that directed everything from development to production. Today the organization manages approximately 60+ scrum teams spanning many time zones and product lines. However, with salesforce.com’s rapid success that model quickly floundered as the development group grew to match pace with customer demands causing a drag in performance on the organization’s throughput. Other challenges the organization had included lack of predictability, missed dependencies, duplicated features, confusing user interfaces and functional misalignment with business goals. Overcoming the hurdles of a more complex and growing organization required significant changes to the development process. An Agile framework centered on Scrum was selected to unify development cadence and release cycles into what salesforce.com now calls the Adaptive Development Methodology (ADM). ADM allows teams to self organize and delivers value earlier in the development cycle, which now gives management the visibility into progress to business objectives and make appropriate changes. However Scrum by itself was not enough to align many teams on a common business objective. Program management was introduced into ADM to address some of challenges including:

Specialization of functional expertise Increased initiative size and complexity Cross-team dependency management Alignment on business goals and objectives Acquisition integration difficulty

Salesforce.com deploys three major releases a year as depicted in Figure 6. Within each release, all Scrum teams synchronize on a monthly sprint boundary where it is expected that each team demonstrate the potentially releasable software increment developed in that iteration.




Figure 6: Salesforce.com Organization Release Rhythm

Program management aligns teams by product line within a product division, for example the Service and Support product line rolls up into the Applications Division which rolls up with several other divisions into the whole “service”. The monthly boundaries are critical to the process and are used as sync points for executive stakeholders and product management to examine the work in progress and realign priorities based on what is being shown combined with forecasted market demands. Product backlogs are fluid and change often but never impact what a team is working on in any given iteration. The release planning process is nimble and only detailed enough as appropriate for sprint planning. Program managers lead the integrated release planning process across component teams, keep track of cross team and cross functional dependencies, and manage program level risks. Working closely, and in tight partnership with the program manager is the product line manager. Acting as the voice of the customer, the product line manager is ultimately responsible for the product capabilities and priorities that each component team is responsible for delivering. Each Scrum team is responsible for creating a bottoms up iteration plan, selecting onto their backlog the product capabilities they will deliver and how they will develop them. Each team estimates the backlog at a high level to get a relative sense of the scope of effort for the whole release then proceeds to break down the backlog into an iteration plan for development. The program management function at salesforce.com includes oversight of the release management process. These are the activities involved in deploying the code base into production environments. Product lines are rolled up across the organization into a single releasable code base. The focus of the Release Program Manager differs from the Product Line Program Manager. The Release Program Manager is responsible for ensuring all components are integrated across product lines, performance is stabilized, and that the production environment is not degraded.




Release program managers work closely with technical operations of the company, whereas the product line program managers focus on business outcomes. Summary While once thought to be on opposite ends of the flexibility and structure continuum, agile software development and program management practices are now being combined to create a flexible framework to develop and deploy large-scale or complex solutions that are aligned with and help achieve the business goals of an enterprise. Agile Program Management is an emerging and powerful capability that provides laser-focus on business goals, rapid delivery of product features to the market, and agility to respond to business and customer changes. © Copyright 2010 by the Program Management Academy and Steve Graykowski




About the Authors:

Russ Martinelli Author

Russ Martinelli is a Senior Program Manager at Intel. He has experience in leading new product

development teams and organizations in both the aerospace and computing industries. Russ is the co-author of two books “Program Management for Improved Business Results” (Wiley, 2007) and “Leading Global Project Teams: The New Leadership Challenge” (Multi-media, 2010). Russ is also the co-founder and executive director of the Program Management Academy (www.programmanagement-academy.com). Russ can be contacted at [email protected].

Steve Graykowski

Author

Steve Graykowski is the Director of Applications Program Management at salesforce.com where he specializes in cloud computing product development

using agile methods for software development. He is a key contributor to salesforce.com’s Adaptive Development Methodology (ADM). He has 24 years of experience in software technology in various roles and sectors including Stanford Research Institute, Charles Schwab and Systemhouse. He has also owned and operated a successful IT consulting firm. Steve can be contacted at [email protected].

Fp Martinelli Graykowski

Business

Transcript of Fp Martinelli Graykowski