Traditional vs. Agile Risk Management

System integration software projects require formal risk management. Here’s how to do it agilely.

If you work in system integration projects, you have likely wondered how to manage project risks within your organization’s chosen Agile approach.  This is a topic seldom discussed in certification courses for Agile-based approaches such as Scrum.  The two major reasons for this are:

  1. Most of these courses focus exclusively on team-level Agile.  In other words, how does a small team of individual contributors work together under the Agile approach?  Individual small teams tend to work on smaller efforts that require much less coordination.  In most of these situations, formalized risk management is overkill.
  2. Managing risk is baked into Agile because Agile is an inherently empirical way of working.  Since Agile development is iterative and incremental, teams narrow the scope of what they build to fit within short time frames.  This enables them to, quickly and frequently, build, test, fix, deploy, evaluate and change what they build, and how. Every iteration of value delivery brings multiple opportunities to address risk “in real time.”  In other words, Agile spreads risk management across the entire development effort.

However, system integration projects are typically large and complex, with multiple teams working across organizations while managing multiple dependencies.  The larger the project, the more risk project sponsors and stakeholders assume.  A formalized approach to risk management becomes a priority.

So, what does a formalized Agile risk management approach look like?  It looks a lot like a traditional risk management approach with three main differences:

  1. Agile risk management is more adaptive than predictive
  2. Agile projects perform risk management activities more frequently and faster than traditional projects
  3. Risk management activities in Agile projects are much more coupled to project execution than in traditional projects

Before describing a formalized Agile risk management approach, let’s level set understanding about project risk management.  Along with the short background provided here, I highly recommend reading this article from pmi.org about risk analysis and management.

Risks, Opportunities, and Issues

The third edition of the Project Management Body of Knowledge (PMBOK Guide) defines risk as:

An uncertain event or condition that, if it occurs, has a positive or negative effect on a project’s objectives.

Project Management Body of Knowledge (PMBOK Guide), Third Edition

By that definition, risks are not just harbingers of negative outcomes.  They may also be opportunities to affect positive outcomes.  Once a negative risk becomes reality, it becomes an issue.

Risk Categories

Categorizing project risks is helpful.  Doing so facilitates risk tracking across the entire project scope.  It also communicates that risk management is everyone’s job, not just that of project management.  Table 1 lists a typical set of project risk categories and their associated extended categories[1]:

Table 1: Typical Project Risk Categories

Risks belonging to the external, organizational, and project management categories are typically:

  • Closely aligned to high-level project concerns outside the control of development teams
  • Less dynamic and fluid than technical risks
  • Almost exclusively in the realm of project and program management and/or product management

Much of Agile literature and training narrowly focus on technical risks. This aligns with their focus on Agile execution by small teams.  However, external, organizational, and project management risks often impact projects far more.

The Risk Management Cycle

Figure 1: The Risk Management Cycle

Both traditional and Agile projects execute the activities of the Risk Management Cycle depicted in Figure 1.  Table 2 lists and describes each activity of the cycle[2]:

Table 2: Risk Management Activities

Predictive vs. Adaptive Planning

Risk management is an important part of project planning.  Traditional project management engages in predictive planning, while Agile performs adaptive planning.  The chosen planning approach affects how projects manage risk.

Traditional project management tries to account for all project tasks and milestones upfront.  Agile planning breaks up the planning horizon into increments. These increments facilitate changing plans when circumstances change.  To be effective, a project’s risk management approach must align to the chosen project management approach.

While all projects, whether they adopt a predictive or adaptive planning approach, perform every activity of the Risk Management Cycle, they emphasize different activities.

A predictive risk management approach emphasizes risk forecasting (prediction) and analysis. Risk analysis entails determining the probability of occurrence and expected project impact of individual risks.  The rationale is that the earlier project managers identify and prioritize project risks, the sooner they can address them before they become issues.

An adaptive risk management approach emphasizes keeping risks small by defining, developing, and delivering system functionality iteratively and incrementally.  This allows teams to handle risks while their potential for project impact is small and to continually monitor risks as solutions evolve and grow.

Traditional vs. Agile Risk Management Characteristics

I’ll now discuss the key differences between how traditional and Agile projects manage risk.

Traditional Risk Identification and Evaluation

Traditional projects develop and execute detailed plans that span the entire project timeline.  Project management often breaks up larger projects into planning packages as part of “rolling wave planning”, but each of those planning packages are themselves detailed plans.  Project plans are based on the resources needed to complete the entire scope of deliverables at a certain cost (The Iron Triangle).

Project plans start with requirements definition.  The entire set of approved requirements defines project scope.  Changes to requirements mean changes to project scope, which translate into schedule and cost changes.

Similarly, traditional risk management tries to identify and evaluate project risks and opportunities prior to or at the start of projects.  While risk management is supposed to happen throughout a project’s timeline, traditional projects tend to perform the bulk of Risk Identification and Evaluation upfront.

The problem with this arrangement is that people cannot predict the future.  The larger and more complex the project, the more likely project requirements and risks will change. 

Traditional project management develops and executes plans assuming requirements, and the design approaches that implement them, are inherently correct and will not change.  This opens projects to the greatest risk of all:  building the wrong thing.

Risk Identification and Evaluation activities in traditional projects often cannot keep up with the accelerated pace of modern software development. In many organizations, risk management is relegated to weekly or monthly risk management boards.  By the time a board adjudicates a risk it may already be an issue.

Agile Risk Identification and Evaluation

While some degree of upfront Risk identification and Evaluation happens in Agile projects, the planning horizon is typically far shorter than that of traditional projects.  Also, most Risk Identification and Evaluation of technical risks happen as part of development, rather than resulting from a separate risk management process.

Traditional Risk Handling and Controlling

Traditional (Waterfall) projects typically get one pass through the Software Development Lifecycle (SCLC).  That pass is strictly constrained by schedule, resources, and cost.  As a result, there is often little room to add risk management activities to the schedule.

Project managers and developers are incentivized to deliver according to plan.  This puts pressure on them to ignore risks until they become issues.  They also forgo opportunities in favor of “flying the plan.”

Agile Risk Handling and Controlling

The Agile SDLC is fast moving and iterative.  Every feature software development teams deliver goes through its own “mini-SDLC”.  Agile planning coupled with DevOps automation support this:

  • Agile provides frequent opportunities to evaluate what development teams build and how
  • Adaptive planning allows sponsors, stakeholders, and development teams to change requirements, plans, and approaches
  • Teams add risks to their work backlogs and prioritize them, thus integrating Risk Handling actions into team workflows
  • Shorter development timeframes with frequent deliveries / releases provide: 1) More frequent and earlier warning of emerging risks; 2) More feedback from which to gauge the effectiveness of risk management efforts

Recommended Approach

The Agile SDLC improves management of technical risks.  However, as stated earlier, external, organizational, and project management risks often impact projects far more than technical risks.  Agile teams have the flexibility to manage technical scope.  They have far less control over funding and major project milestones.

External, organizational, and project management risks influence the overall business or mission context within which teams develop solutions.  Project leadership must actively manage these risks before they impact the work of development teams. 

Agile projects should leverage traditional risk management tools and techniques to manage more strategic, slower-moving risks.  Project leaders would then work with development teams to translate such risks into actionable work items and prioritize them.  All project members should have access to risk management reporting and the ability to submit risk candidates as part of their work.

Conclusion

Too often, risk management gets short shrift, especially in Agile projects.  Risk management is an integral part of project planning, regardless of the software development approach employed.  Combining Agile requirements definition and planning, with DevOps automation, and a robust risk management process helps teams deliver valuable software capabilities, cost-effectively, and in time to be valuable.

[1,2] Lavanya, N., Malarvizhi, T., “Risk Analysis and Management,” Project Management Institute, 3 March 2008, https://www.pmi.org/learning/library/risk-analysis-project-management-7070




Agile, Waterfall, or Nothing at All?

Balancing team autonomy with project control

Software developers are “creatives.”  Most don’t fit the stereotypes of artists, designers, authors, etc.  However, even those who typify the hyper-analytical “software engineer” persona crave opportunities to work on projects where they can express their creativity by building great solutions. 

Many imagine (and often start) “green field” projects that allow them to do just that.  They want to avoid integrating their work with previous (legacy) implementations and accommodating technical and project management constraints.  They long for autonomy in deciding what to develop, how, and with what.

Most often, however, this drive for autonomy clashes with the realities of creating successful products and services.  Success entails more than writing code.  Also, developers, like practically everyone else, expect compensation for their work.  Unless the effort is altruistic or some sort of hobby, the needs of sponsors, stakeholders, customers, and users influence what the solution becomes, its development, and the mix of technologies and tools employed.

Every software development project, regardless of the chosen development or project management approach, must address the phases of the software development lifecycle (SDLC) and the constraints of the “Iron Triangle”:  Cost, Schedule, and Scope.  There is no free lunch.

Software Development Lifecycle
Figure 1: The Software Development Lifecycle (SDLC)

Balancing Team Autonomy and Project Control

Striking the right balance between development team autonomy and project management control involves aligning software development and project management approaches to deliver the greatest value possible.  That balance is different for every organization and project.

Before Agile, the need to subordinate software development practice to the needs of project management was an unquestioned assumption.  Documentation and processes that supported project planning masqueraded as engineering or technical artifacts.  It did not matter that those detailed requirements, design documents, and development plans became obsolete doorstops soon after development started.  What mattered was that they provided information with which to create management plans, schedules, and budgets.

Two major factors opened the door to experimentation with iterative and incremental software development and delivery.  The first was the decades-long track record of failure amassed by traditional software projects in delivering complete solutions on time, within budget, and at expected levels of quality.  The second was the impact of technological advances that flipped the cost differential between computer memory and employees (i.e., employees became more expensive than computing resources).

Differences between Software Development Approaches

We now have multiple software development approaches to choose from.  Each balances team autonomy vs. management control differently based primarily on how they address the following priorities:

  • Adaptive vs. Predictive Planning
  • Tactical vs. Strategic Focus
  • Innovation, Flexibility, and Speed vs. Control and Risk Avoidance
  • Iterative and Incremental Delivery vs. “Big Bang” Delivery

Spectrum of Software Development Approaches
Figure 2: Spectrum of Software Development Approaches

Adaptive vs. Predictive Planning

Figure 2 above depicts some of the most common software development approaches on a spectrum, from most adaptive on the left side to most predictive on the right side. On the adaptive extreme (cowboy coding):

  • Little to no planning occurs prior to or during the project
  • Developers execute project activities in an ad hoc fashion, based on their own judgement and project needs, rather than following a deliberate plan
  • They have a free hand in choosing what they develop, design approaches, technologies, tools, etc.

As we move from left to right on Figure 2, software development and program management process overhead increase.  So does the amount of planning done prior to software development.

As Figure 2 depicts, planners have latitude in tailoring and implementing software development approaches.  Different choices yield different amounts of process burden and upfront planning. Ultimately, project and technical constraints and circumstances shape the implementation of all software development approaches.

On the predictive extreme, project activities are tightly coordinated and sequenced based on plans that encompass the entire development project, from requirements definition to release.

Rather than performing most project planning during the Planning and Analysis phases of the SDLC, Agile spreads planning across its entirety. Agile software development executes SDLC activities as one integrated flow of work that grows and evolves solutions iteratively and incrementally.

Tactical vs. Strategic Focus

As we move across the software development approaches, from left to right, solution alignment with organizational strategic aims increases.  This is because predictive software development approaches are typically top-down in nature. Adaptive development projects are more closely aligned with short-term tactical goals and deliver capabilities in smaller increments than predictive development projects.

Alignment between strategic and tactical imperatives is possible and necessary for both predictive and adaptive approaches. However, the inherent top-down vs. bottom-up nature of predictive vs. adaptive planning results in very different ways of achieving strategic and tactical alignment.

Learn how Scrum aligns organizational strategy and IT via a product management mindset.

Innovation, Flexibility, and Speed vs. Control and Risk Avoidance

Choosing the right software development approach also depends on project sponsor and stakeholder priorities.  Projects best suited for an adaptive development approach prize innovation, flexibility, and speed.  Predictive software development approaches are most appropriate in organizations seeking to enforce top-down control and avoid risk.

The nature of a project’s technology and business/mission domains also influences choices between software development approaches. Projects best suited for a predictive approaches:

  • Have stable and well-understood technology and business domains
  • Standard and routine solution approaches
  • Project staff experienced in delivering systems of similar size and scope

An adaptive software development approach is best for innovative (non-routine) technical projects and for projects that require ongoing refinement and experimentation to arrive at the most optimal solution.

Some software projects in regulated industries or government may require predictive software development approaches.  Regulatory oversight increases the need for program management control and risk avoidance.  Most software system development projects do not require that level of oversight and control, thus making them likely candidates for adaptive software development approaches.

Iterative and Incremental Delivery vs. “Big Bang” Delivery

Another defining feature of software development approaches is whether they deliver capabilities iteratively and incrementally or as monolithic “Big Bang” releases.  While most organizations deliver software solutions incrementally across multiple releases, many develop large increments of capability over months or years. Such release increments are essentially Spiral or serial Waterfall projects.

Iterative and incremental SDLC approaches, like Agile, increase the frequency of releases and shorten the time between them considerably.  For example, software teams that employ Agile approaches such as Extreme Programming (XP) and Scrum develop release candidates every two to four weeks. Smaller, more frequent releases lower risk and provide more opportunities to align solutions to current business/mission, organizational, and technical circumstances.

Conclusion

Control is a vital element of agility.  Accelerating the pace of software delivery requires some degree of control and flexibility.  Overemphasizing control slows software development and decreases flexibility.  Underemphasizing control can turn flexibility into chaos, robbing software development teams of both planning and process stability, thereby slowing progress.

The term “Cowboy Coder” is a pejorative for a reason.  Developing functionality without disciplined technical and project management processes leads to low-quality implementations and project failure.  It also makes it harder to align solutions to market, business, mission, and oversight requirements.

The opposite extreme is ill suited for most software development efforts.  Most software development efforts do not need the amount of process and documentation overhead Waterfall software development brings. In fact, the predictive planning necessary to carry out Waterfall process and documentation runs counter to the way modern software systems are developed.

Software development teams must not ignore project and technical constraints.  Nor should they try to address every constraint and risk prior to development.  Instead, they should leverage them to create better solutions through inspection and adaptation, iterative and incremental development and release, and adaptive planning.



Agile Cheetah Now Has a YouTube Channel!

Agile Cheetah just added a YouTube channel to our list of platforms. This is another way for us to share knowledge about Agile, DevOps, and organizational agility.

You can subscribe to the channel directly from the watermark link in lower right-hand corner of the video below. Visit the channel and don’t forget to like the video and click on the notification bell to ensure you don’t miss future videos!

Product Backlog Ordering Using WSJF Video

Managing Software Project Scope: WBS vs. Product Backlog

Both decompose project scope in very different ways.

Many organizations steeped in traditional project management culture struggle to adopt Agile’s product management approach.  One of the biggest cultural stumbling blocks is the difference between how traditional project management and Agile treat project scope.  This is best exemplified by the differences between the Work Breakdown Structure (WBS) and Scrum’s concept of the product backlog.  This article describes both tools, compares and contrasts them, and makes the case for not conflating these two methods of accounting for project scope.

What is a WBS?

The PMBOK® Guide—Third Edition defines a WBS as:

“A deliverable-oriented hierarchical decomposition of the work to be executed by the project team to accomplish the project objectives and create the required deliverables. It organizes and defines the total scope of the project. Each descending level represents an increasingly detailed definition of the project work. The WBS is decomposed into work packages. The deliverable orientation of the hierarchy includes both internal and external deliverables.”

PMBOK® Guide—Third Edition

A WBS is a planning tool that helps identify, document, and present the total scope of a project.  Scope is one of the three project management constraints colloquially known as “The Iron Triangle”.

Iron Triangle
Figure 1: The Iron Triangle

The Iron Triangle represents how scope, schedule, and level of effort/resources act as mutually-dependent project constraints.  Traditional project management attempts to predict most, if not the entire, project scope prior to project execution.  Later, planners estimate the level of effort required to complete planned tasks and deliverables and build a project schedule based on those estimates.  The resulting three values feed calculation of project cost.

WBS Structure

A WBS is most often depicted as a hierarchical tree.  Every node in the tree is called an element.

Figure 2: Basic WBS Structure

Depending on the type of WBS hierarchy created, project scope may be organized in terms of:

  • Project/program activities necessary to deliver deliverables (Verb-Oriented)
  • Product components that make up a deliverable (Noun-Oriented)
  • Time-bound phases of the project plan
  • A mix of the previous three types

The root of the tree (WBS level 1) represents the entire scope of the project or product deliverable.  From there, the main branches/elements of the tree (WBS Level 2) are structured in accordance with one of the four types of WBS hierarchy types listed above.

WBS Decomposition

The tree expands as higher-level elements are decomposed into smaller constituent elements or components.  Each element represents 100% of planned work and deliverables for that element.  Child elements collectively represent 100% of the scope represented by their parent.  Decomposing across elements just enough to facilitate project scope definition, without over-specifying the project or solution, while accounting for the entirety of project scope, is an art honed by experience.

Mapping to schedule and Resources

At the lowest level of each branch of the WBS hierarchy are work packages.  Work packages map project scope (deliverables and activities) to project schedule.  A work package includes schedule activities and milestones required to complete the associated deliverable or work element/component.  In turn, control accounts map work packages to project budget (cost), facilitate the roll up of activities and milestones into an integrated schedule, and allow planners to assign specific resources (e.g., people) to specific elements of the WBS hierarchy.

Figure 3: WBS Hierarchy with Control Accounts

Another artifact that ties the scope represented by the WBS to project schedule and resources is the WBS dictionary.  The PMBOK® Guide—Third Edition defines a WBS dictionary as:

A document that describes each component in the WBS.  For each WBS component, the WBS dictionary includes a brief description of the scope or statement of work, defined deliverables, a list of associated activities, and a list of milestones.  Other information may include responsible organization, start and end dates, resources required, an estimate of cost, charge number, contract information, quality requirements, and technical references to facilitate performance of the work.

PMBOK® Guide—Third Edition

The WBS dictionary for figure 3 above may look something like this:

Table 1: WBS Data Dictionary Template Example

Types of WBS Hierarchies

Let’s delve a little deeper into the different types of WBS hierarchies.

Project Scope WBS

Figure 4: Project Scope (Verb-Oriented) WBS

A project scope WBS decomposes the project work or activities necessary to produce deliverables or products.  The first word of each WBS element name is a verb, such as, design, develop, test, etc.  In figure 4 above, the project is organized by Software Development Lifecycle (SDLC) phases (Define, Design, Develop, and Integrate & Test) and includes the project management work necessary to orchestrate the work.

Product Scope WBS

Figure 5: Product Scope (Noun-Oriented) WBS

A product scope WBS defines project work in terms of the components (physical or functional) that make up a deliverable or product.  In this case, the first word of each WBS element name is a noun, such as, Module A, Subsystem B, Aircraft Engine, Fuselage, etc.  Since each element represents a part of the overall product, this WBS type is sometimes called a “Product Breakdown Structure (PBS)”.

Time-Phased WBS

Figure 6: Time-Phased WBS

Large-scale projects can take years to complete.  In such cases, it is reasonable and advisable to break up project scope and schedule into discrete phases.  A “time-phased” WBS breaks up the project into major phases instead of activities.  Rather than planning the entire project upfront, planners follow a “rolling wave” planning approach in which they plan the upcoming phase in detail while postponing detailed planning for later phases.  Rolling wave planning affords the opportunity to improve current plans based on lessons learned in previous phases. It also provides a measure of flexibility to deal with changing project realities.

Hybrid WBS

Figure 7: Hybrid WBS

Elements from the three other WBS types can be combined to create a “hybrid” WBS.  Defense materiel project planners frequently use this type of WBS.  Such projects tend to be long-lived, so time-phased branches may be included.  Product-based branches scope complex products/deliverables.  For activities that map to specific activity phases (e.g., SDLC phases), project scope elements are appropriate.  A hybrid WBS may include project or program activities outside the scope of creating physical or functional product components or managing their creation.  Examples of such activities include training, operations & maintenance, and facilities management.

WBS Type Comparison Chart

I summarize the WBS hierarchy types in the table below:

Table 2: WBS Hierarchy Type Comparison Chart

Agile Value Delivery

Before discussing product backlogs, I need to explain how Agile software teams deliver useful capabilities. 

Agile software teams deliver iteratively and incrementally.  They release valuable increments of software functionality over the entire development effort.  These increments are “production ready” or “potentially releasable” software capabilities that customers and end users can start using right away.  While not everything released by Agile teams must be user facing, they avoid releasing individual system components or portions of components that do not deliver real business or mission value on their own.

Solutions built by Agile teams grow and evolve over time.  Each and every increment delivered is designed to work with all other increments, past and future.

Figure 8: Waterfall vs. Agile Value Delivery

Thus, Agile releases are primarily feature-based, not component-based.  Rather than delivering system components, Agile software teams strive to deliver features.  Features are cohesive and complete slices of system functionality capable of performing useful work from the perspective of customers and end users. 

What is a Product Backlog?

A product backlog is an ordered queue of deliverables.  The term product backlog is most associated with the Agile framework called Scrum.  According to the Scrum Guide, the product backlog:

…is an emergent, ordered list of what is needed to improve the product. It is the single source of work undertaken by the Scrum Team.

https://www.scrumguides.org/scrum-guide.html

In this definition, the “product” is whatever the Scrum Team develops and delivers (application, system, solution, documentation, reports, etc.). A product backlog is used to track product deliverables.

As depicted in figure 9 below, Scrum teams take into account multiple considerations when ordering product backlog items.

Figure 9: Product Backlog
Learn more about ordering product backlogs.

Product backlog items represent features.  Scrum teams decompose bigger features into smaller ones to better manage their development.

The highest-ordered items are most ready for implementation.  The Scrum Team refined them well enough to implement them.  Lower-ordered items are increasingly less ready for implementation the further down the product backlog they rank.

Comparing & Contrasting WBS vs. Product Backlog

Having level set what a WBS and product backlog are, I now discuss the similarities and differences between them.

Figure 10: WBS vs. Product backlog

Similarities

Of the four WBS types discussed in this article, the PBS is most like a product backlog.  Both are product scope-focused and decompose larger deliverables into smaller ones.

Neither a WBS or product backlog depict dependencies between elements or items.  The main artifact used to show dependencies between work activities and deliverable milestones in traditional project management is the project schedule.  User story maps help organize Scrum product backlog items (epics and user stories) based on workflow and interface dependencies.

Differences

The main difference between WBS hierarchies and product backlogs is that the WBS is a tool for linking together project scope with the other two Iron Triangle constraints:  schedule and level of effort/resources.  A product backlog is strictly focused on tracking and ordering product scope.

Modern Agile productivity tools like JIRA allow development teams to document the work they perform, how long it takes them to do it, etc.  However, that information is collected after developers pull the highest priority items from the product backlog and begin work.  The product backlog is neither a repository for nor a source of work status information.

Another difference is that tasks and activities count as part of the scope represented by a WBS (e.g., project management tasks, meetings, reporting).  While Agile software teams also deal with management and project overhead, those activities are not included in the product backlog.  From an Agile perspective, those activities are not part of the product.  They are necessary, yet ancillary activities to the work of developing, testing, and releasing software.

Finally, product-oriented WBS elements represent components while product backlog items represent features. 

Disadvantages of Decomposing Product Scope into Components

Decomposing product scope into components has three major disadvantages:

  1. Postponing integration and testing
  2. Difficulty measuring progress
  3. Formation of component team silos

Postponing Integration and Testing

In traditional software projects, there is often nothing valuable to test and evaluate, from a business or mission perspective, until most or all components are integrated into a cohesive solution.  In traditional software projects, system integration is done infrequently, often occurring only once towards the end of development.  Integrating components towards the end of a project often affords insufficient time to address problems.

Difficulty Measuring Progress

Traditional project management focuses on tracking tasks and activities and their level of completion (e.g., percentage complete).  The rationale being that if everyone executes all necessary tasks and activities, on time, and in the right order, the project will proceed as planned.  Therefore, project management’s job is to identify everything that needs to be done before the start of the project and enforce adherence to the plan. 

The problem with applying this approach to software projects is that non-trivial software systems are significantly more complex than physical systems of comparable cost.  This is because software systems can be developed and modified in infinite ways.  As software systems evolve to serve growing numbers of requirements from growing user bases, their complexity increases, sometimes at a seemingly exponential rate.  No amount of predictive planning can overcome this natural slide towards entropy.

There is also the issue of quantifying how much actual progress has been made.  What is the difference between a component being 75% complete vs. 95% complete?  If we have to wait until it is 100% complete and integrated into the larger solution before we can test and validate it, there is none.

Agile planning is adaptive, with short project planning horizons.  Software development teams achieve fast and frequent releases by keeping releases small.  Planning and releasing this way allows for more opportunities to test and validate deliverables and to fold lessons learned into ongoing planning.  Best of all, the measure of project progress is delivery of valuable capability to customers and end users rather than arbitrary estimates of completion rates.

Formation of Component Team Silos

Each WBS element maps to a set or resources (one or more teams) that do the work.  Establishing development teams for specific solution components often stifles cross-team collaboration and creates productivity bottlenecks.

For example, project management forms a dedicated database team to deliver a system database identified as a WBS component.  The result is that the team’s allocated hours and skillset are segregated around delivering a single component.  Often, the inefficiencies of managing dependencies between component teams outweigh the efficiencies gained from component team specialization.

Forming teams around system features is a staple of Agile software development. While component teams are sometimes necessary in Agile software development efforts, the default bias is towards forming feature teams. Under feature teams, system components form and evolve incrementally and iteratively, one feature at a time. Value delivery no longer depends on delivering the entire system. Instead, value delivery occurs one release at a time throughout development.

Agile Breaks the Iron Triangle

To achieve project agility, Agile breaks the Iron Triangle by making project scope variable while fixing resources and schedule.  This involves shifting our thinking about managing projects:

Table 3: How Breaking the Iron Triangle Shifts Thinking about Managing Projects

The most optimal solutions reside in the nexus of value, cost-effectiveness, and timeliness:

Figure 11: The Optimal Solution Space

Agile projects control scope and ensure teams satisfy requirements through ongoing planning and collaboration between development teams, project sponsors, stakeholders, customers, and end users.  Sponsors control budgets and approve project roadmaps; stakeholders, customers, and end users work with development teams to define solutions; and development teams plan and build functionality within those constraints.  The advantages of controlling projects primarily through managing project scope are:

  • Not sacrificing quality in favor of adhering to all three constraints of the Iron Triangle.
  • No budget or schedule surprises (since budgets and schedules are essentially fixed)
  • Basing project decisions on the actual business or mission value delivered and team performance rather than alignment to detailed (and possibly obsolete) plans

Conclusion

At the heart of the differences between traditional project management and Agile is the fundamental difference between project management and product management.  Project management focuses on managing tasks and activities to ensure they complete on schedule and on budget.  Product management focuses primarily on managing the product.

Many project and program managers are unaware of this difference.  Implementation of Agile practices corrupted by traditional project management biases often leads to failed projects.  Attempting to structure product backlogs like WBS hierarchies is one manifestation of this misalignment between traditional project management and Agile mindsets.