Project Management

Disciplined Agile

by , , , , , , , , , ,
This blog contains details about various aspects of PMI's Disciplined Agile (DA) tool kit, including new and upcoming topics.

About this Blog

RSS

View Posts By:

Tatsiana Balshakova
Glen Little
Mark Lines
Valentin Mocanu
Daniel Gagnon
Michael Richardson
Joshua Barnes
Kashmir Birk
Klaus Boedker
Mike Griffiths
Scott Ambler

Recent Posts

Requisite Agility applied in Project Management

Disciplined Agile and PMBoK Guide 7th Edition

Comparing Agile and Lean Backlog Strategies

Disciplined Agile 5.3 Released

Measure Outcomes - A New Process Goal

Requisite Agility applied in Project Management

Requisite Agility applied in Project Management

This blog provides an overview of how Requisite Agility can be applied to Project Management.

In the age, of the convergence of AI, IoT, Blockchain, Cloud Computing, Robotics and AGV’s, as the pace of change and disruptions accelerates, requires us to be more open to the unknown and therefore to be more nimble, flexible and adaptive than ever before.

Project Managers have always been concerned with ensuring deliveries based on quality specifications, on time, within budget. In our new realities, requirements change in real-time. Our deliveries on time to forecast is meaningless if the competitors are faster. A budget only matters if the organization is synchronized in real-time changes with the markets and communities it serves.

In the Origin of Species, the biologist Charles Darwin described evolution as the “survival of the fittest”. The fittest did not mean the species with the most resources and health. The fittest species were the ones who were most resourceful and adaptive in the face of changes in their context and environment.

We need to distinguishing Agility and Agile. Agile is a specific set of tools and practices developed for small, stable, software teams using semi-autonomous teams, visual metrics and rapid iterations and release of usable code. Agility is the ability to think and act quickly and flexibly. It is a characteristic that exists in every living thing in the universe.

Agility as a characteristic by itself is not enough. For example, a professional boxer can have amazing agility in the gym. Lightning-fast hand speed, head, foot and body movement and an open adaptive mind. But he, she or they will lose when he is in the ring with someone who has greater agility.

Agility by itself is not enough. We need is Requisite Agility. Requisite means what is required or necessary in any given situation. In our boxing example, requisite is measured by the agility of the opponent. A new mindset is required in complex ecosystems and competitive environments.

Requisite agility is the capacity to make fast and flexible changes in relation to required context and conditions. The best example of requisite agility is our heart. It is constantly sensing and adapting in relation to changing circumstances. If it did not make these requisite adjustments, we would die.

There are at least five ways Requisite Agility (RA) can be applied to project management.

Waterfall Project Management

Requisite Agility in Project Management

Control and Obedience

Command-and-control cultures rely on top-down approvals of bottom-up status reports. The individual is the unit of production. In a Project Charter has the name of the person “accountable” which means who will be recognized, rewarded or punished. Regardless of systemic, structural and cultural impediments. The role of the supervisor is to plan, organize, lead, inspire, control and educate. (POLICE). Project Management enforces this culture.

Collaborative Intelligence
Sensors (human and technical) are in distributed networks (like our brain). The more nimble and more adaptive the connections between the parts the greater the intelligence, productivity and resilience in people, teams and organizations. Managers at all levels apply Gemba on a daily basis.

Teams are the unit of production. Individuals are accountable to the team they serve on. The team is invested in the success of every individual on the team. Project Management facilitates the nurturing and development of collaborative intelligence.

Functional Fragmentation

The organization is designed around horizontal control relationships of supply (organisational capabilities) and demand (customer needs).

Each downstream team or function is the internal customer of groups upstream, demanding their needs to be met. Customers make demands to fulfil capacities they lack. Project Managers are passive sensors and enforcers of budget, quality and time constraints that are out of their control.

Synchronous
RA transcends industrial concepts of supply and demand. The doctor is as dependent on the patient’s capability as much as the patient is on the doctors. In a healthy relationship both work together. Both are dependent on the synchronicity of the system as a whole. Project Managers are active systemic sensors engaged in continuous feedback, learning and adaptation. In a world Beyond Budgeting they are no longer helpless observers of a system designed out of their control.

Compliance-Driven Values

Values are written on the wall. Policies on ethics, fraud, fairness, equity and diversity are published.  People are expected to comply.  Project Managers police the compliance of abstract values. The unintended consequence of these sincere, good intentions is to create a low-trust, fear-based culture. But the only true source of integrity comes from within.

Seva
Seva is the Sanskrit word for being in union with and in service of humanity. Agile Coaches or Scrum Masters are servant-leaders. They are not in a parent-child relationship, they engage in mature adult-adult relationships based on mutual service and success. Project Managers are attuned to the presence or absence of Seva in themselves and the people they work with.

Unidisciplinary
There have always been ‘trades’ so it was natural for the industrial age to force people into even deeper specialization. Disciplines define us. Power is centralized. Cross-functional teamwork, alignment and dependencies hold a fractured foundation together. But resources, rewards, metrics, and performance systems revert to the individual as the unit of production.  We work with each other in an inter-disciplinary manner but ultimately we are expected to “stick to our lane” and are measured by the success of our functional silo.

Transdisciplinary

In the digital age technical specialization has become even more critical. We recognise that organizations are living systems, where the health is in the quality of relationships between the parts. Power is decentralized in networks of relationships.  The boundaries of industry sectors are blurring. Value streams are being aligned across eco-systems. Value is created in the white space, beyond the boundaries of the disciplines that define us. Being transdisciplinary reduces risk, increases innovation and makes us more resilient because it draws more value out of specialization.

Change Management

Change Management models based on the formula of “unfreeze, change, refreeze” are too flat footed in the era of digital transformation. Project Management adheres to Chronos (clock) Time: Deadlines and on-time-delivery are necessary but not sufficient. What is the value in meticulously tracking change requests in a proactive, team-based learning organization that is continuously and purposefully changing and improving?

Shaping Transitions
Project Managers (PM’s) adjust their approach across different levels of complexity. PM’s are trusted advisors in the business, not outsiders used as enforcers to ensure compliance. PM’s attune to how customers experience value. PM’s attune to the coherence and cadence of community or customer needs, desires and potential. They apply this awareness to engage in continuous, real time learning and development of people, teams and the organization as a whole.


PMI’s own research shows the dramatic difference in performance outcomes between organizations that apply agility and those that don’t.

 Requisite Agility enables organizations to deliver performance outcomes even higher than those who are only focused on agility, alone.

Posted by Kashmir Birk on: December 10, 2021 05:18 PM | Permalink | Comments (1)

Disciplined Agile and PMBoK Guide 7th Edition

Categories: PMBoK, PMI and DA

PMBoK 7th Edition and Disciplined Agile

We are often asked what the relationship is between Disciplined Agile (DA) and A Guide to the Project Management Body of Knowledge (PMBOK®Guide) 7th Edition (PMBoK7). We thought we would share our thoughts on the topic, presented as a frequently asked question (FAQ) list. 

 

Q: Is PMBoK7 based on DA?

A: No, PMBoK7 was written independently of DA. Like DA, PMBoK7 is based on ideas and experiences from a wide range of people and sources so there’s clear overlap.

 

Q: How much coverage does DA include of PMBoK7?

A: A lot. As you can see in the DA Browser, techniques captured in both PMBoK7 and PMBoK6 are referenced extensively in DA. Having said that, we’re in the process of updating those references so that they point to the same topics in PMIstandards+, which is PMI’s digital version of our standards, guides, and how-to content.

 

Q: How much coverage does PMBoK7 include of DA?

A: It depends on how you look at it.  Explicitly, very little.  Implicitly, a fair bit. As we indicated earlier, there is a lot of overlap between what PMBoK7 covers and DA.  Both capture known, effective, and practical strategies.

 

Q: Why doesn't PMBoK7 include more DA concepts, given that it was published after PMI purchased DA?

A: DA was purchased by PMI in August 2019 and PMBoK7 was published in June 2021. Given that PMBoK7 is an ANSI standard, the submitted version of PMBoK7 was pretty much finalized at the point that PMI acquired DA. 

 

Q: How do the PMBoK7 principles map to the DA mindset?

The following table presents a mapping of the PMBoK7 principles to the principles, promises, and guidelines of the DA mindset.  We intend to publish a detailed blog on this topic in the near future.

PMBoK7 Principle

Disciplined Agile

Be a diligent, respectful, and caring steward

  • Principle: Be awesome
  • Principle: Enterprise awareness
  • Promise: Create psychological safety and embrace diversity
  • Guideline: Leverage and enhance organizational assets

Create a collaborative team environment

  • Principle: Be awesome
  • Promise: Keep workloads within capacity
  • Guideline: Create effective environments that foster joy
  • Guideline: Attend to relationships through the value stream
  • Guideline: Create semi-autonomous, self-organizing teams

Effectively engage with stakeholders

  • Principle: Delight customers
  • Principle: Enterprise awareness
  • Promise: Collaborate proactively
  • Guideline: Apply design thinking

Focus on value

  • Principle: Delight customers
  • Principle: Organize around products/services
  • Promise: Accelerate value realization
  • Guideline: Apply design thinking
  • Guideline: Attend to relationships through the value stream
  • Guideline: Adopt measures to improve outcomes

Recognize, evaluate, and respond to system interactions

  • Principle: Optimize flow
  • Principle: Context counts
  • Promise: Make all work and workflow visible
  • Guideline: Attend to relationships through the value stream
  • Guideline: Apply design thinking
  • Guideline: Adopt measures to improve outcomes.

Demonstrate leadership behaviors

  • Principle: Be awesome
  • Principle: Be pragmatic
  • Principle: Enterprise awareness
  • Promise: Create psychological safety and embrace diversity
  • Guideline: Attend to relationships

Tailor based on context

  • Principle: Context counts
  • Principle: Choice is good
  • Promise: Improve continuously
  • Guideline: Validate our learnings
  • Guideline: Apply design thinking

Build quality into processes and deliverables

  • Principle: Delight customers
  • Principle: Be awesome
  • Principle: Optimize flow
  • Promise: Improve continuously
  • Guideline: Adopt measures to improve outcomes
  • Guideline: Leverage and enhance organizational assets

Navigate complexity

  • Principle: Be pragmatic
  • Principle: Organize around products/services
  • Promise: Make all work and workflow visible
  • Promise: Collaborate proactively
  • Guideline: Attend to relationships through the value stream
  • Guideline: Create semi-autonomous, self-organizing teams

Optimize risk responses

  • Principle: Be pragmatic
  • Principle: Enterprise awareness
  • Principle: Delight customers
  • Principle: Optimize flow
  • Promise: Make all work and workflow visible
  • Promise: Collaborate proactively

Embrace adaptability and resiliency

  • Principle: Be pragmatic
  • Principle: Enterprise Awareness
  • Promise: Improve continuously
  • Guideline: Adopt measures to improve outcomes.
  • Guideline: Leverage and enhance organizational assets

Enable change to achieve the envisioned future state

  • Principle: Context Counts
  • Principle: Choice is good
  • Principle: Enterprise awareness
  • Promise: Improve continuously
  • Promise: Collaborate proactively
  • Guideline: Validate our learnings
  • Guideline: Attend to relationships through the value stream
  • Guideline: Change culture by improving the system
  • Guideline: Adopt measures to improve outcomes

 

Q: How do PMBoK7 and DA differ?

A: PMBoK7, and the supporting materials in PMIstandards+, is a deep dive into Project Management. DA’s scope is much broader in that it addresses enterprise agility, putting a wide range of strategies that include but go beyond project management into context.  Where PMBoK7 is deep, DA is broad.

 

Q: Where can I learn more about DA?

A: The Disciplined Agile Hub on PMI.org is a great starting point, as are the Introduction to DA and the Disciplined Agile Tool Kit pages.

 

Q: Where can I learn more about PMBoK7?

A: You can access A Guide to the Project Management Body of Knowledge (PMBOK®Guide) 7th Edition here. As a PMI member you can download a personalized PDF free of charge.

 

Acknowledgements

I'd like to thank Mike Griffiths for his input that went into this blog.

Posted by Scott Ambler on: November 09, 2021 03:46 PM | Permalink | Comments (10)

Comparing Agile and Lean Backlog Strategies

Categories: agile, Backlog, lean, Requirements

One of the changes that we made in the DA 5.3 release on September 30th was to update our advice around managing backlogs. We had been using older terminology from when we first developed Disciplined Agile Delivery (DAD) and we had an out-of-date description of what was being advised in the Scrum community (they've adopted a more disciplined strategy in recent years).  So we've acted and updated this aspect of the tool kit.

Recent Refactorings

There are three refactorings that are pertinent to our discussion:

  1. Introduction of the Intake Work process goal. In the DA 5.2 release of July 9th, 2021 we created a new process goal, Intake Work by refactoring it out of the existing Address Changing Stakeholder Needs process goal.  The Intake Work process goal is depicted in Figure 1. The reasons for this refactoring was that Address Changing Stakeholder Needs wasn't cohesive in that it had two purposes, the first to explore the changing needs and the second to intake the work into the team.   
  2. Introduction of the Manage Backlog decision point. For the 5.3 release we refactored further, and split the Manage Work Items decision point into two, creating the new Manage Backlog decision point.  The reason for this refactoring was that the original decision point wasn't cohesive, it had two purposes, the first to capture strategies to manage backlogs and the second to manage/visualize work items.
  3. Update to Explore Scope. We updated Explore Scope's Choose a Backlog Management Strategy decision point to reflect the changes we made to Intake Work.

 

Figure 1. The Intake Work process goal.

 

Managing Backlogs

As you can see in Figure 1 there are four fundamental strategies for managing your backlog of work.  These strategies are ordered, you know this because there is an arrow beside the list, indicating that the strategies towards the top of the list are generally more effective than the strategies towards the bottom.  In order from most effective to least effective, these strategies are:

  1. Lean backlog. Lean backlogs are typically organized into four groupings: Potential work that the team may commit to; Committed work that the team will perform, which is typically sequenced into several classes of service; Work in process (WIP) that the team is currently performing; and completed work that is ready to move on to the next stage in your overall process.  Lean backlogs are overviewed in Figure 2. 
  2. Agile backlog. Work items are managed as an ordered list/stack. Higher-priority work items appear at the top of the list, are granular and captured in greater detail, and are sequenced.  Lower-priority work appear towards the bottom of the list, lack detail, and are effectively in unsequenced priority buckets. In previous versions of DA we referred to this strategy as a Work Item List and it has always been our default recommendation for agile team.  This strategy was an extension to Scrum's (at the time) product backlog which was a prioritized list of requirements, but over the years Scrum's approach has evolved into this more disciplined strategy. Agile backlogs are overviewed in Figure 3.
  3. Requirements (product) backlog.  A unique, ranked stack of requirements that needs to be addressed. Requirements at the top of the list should be captured in greater detail than lower-priority requirements at the bottom of the list. In earlier versions of Scrum this was a prioritized list of functional/usage requirements, often captured as user stories.  Some teams would include defects and some form of quality requirements (often captured as technical stories) on the backlog, as they were considered valid requirement types as well. Requirements backlogs are overviewed in Figure 4.
  4. Unsequenced backlog. All of the work is effectively the same priority, although sometimes there may be the concept of two priorities - what is in the current release and what needs to be in future releases.

 

Figure 2. Lean backlog overview.

Lean backlog overview

Figure 3. Agile backlog overview.

Agile backlog overview

Figure 4. Requirements (product) backlog overview.

Requirements (product) backlog overview

 

Comparing Backlog Strategies

The following table compares the four backlog strategies.  For more information, please refer PMI's Disciplined Agile (DA) Browser.

Table 1. Comparing Backlog Strategies
Backlog Strategy Advantages Disadvantages
Lean
  • Best where priorities are changing continually.
  • Easily supports several work sequencing schemes in parallel.
  • Harder to see the work as a single stack of sequenced work items if there are multiple classes of service.
  • Requires discipline to pull new work fairly from the various classes of service. It's common to see one or more classes, such as paying down technical debt, starved in favor of implementing new functionality.
Agile
  • Best suited where the team follows one of the agile life cycles.
  • Clearly indicates the order in which work will be performed, enabling effective prioritization discussions with stakeholders.
  • Supports the forecasting of cost and schedule estimates via techniques such as burndown or burnup charts.
  • Requires ongoing maintenance and refinement, adding overhead to your process.
Requirements (product)
  • Clearly indicates the order in which work will be performed, enabling effective prioritization discussions with stakeholders.
  • Supports the forecasting of cost and schedule estimates via techniques such as burndown or burnup charts.
  • Forecasts tend to be overly optimistic due to non-requirement work not being accurately taken into account.
  • Requires ongoing maintenance and refinement, adding overhead to your process.
Unsequenced
  • Enables the team to perform the work the the order they deem to be the most effective.
  • You don't know what's next to be worked on, making it more difficult to do look-ahead planning/refinement.
  • Team members tend to work on what they want to, or what they find easy.
  • By not working in priority order, when the team runs out of time or funding, they risk missing critical functionality because it needed to be cut.

 

 

Acknowledgements

I'd like to thank Curtis Hibbs and Klaus Boedker for their great work on Figures 2-4, which I reused from our upcoming Disciplined Agile Product Owner workshop.

 

Posted by Scott Ambler on: October 04, 2021 12:03 PM | Permalink | Comments (14)

Disciplined Agile 5.3 Released

Categories: agile, Disciplined Agile

Disciplined Agile LogoWe released Disciplined Agile (DA) v5.3 earlier today, September 30th 2021.  While there are several visible changes that we've made, discussed below, most of this release is "behind the scenes" in that we've updated descriptions of many techniques and added many new references that link to articles, blogs, or books describing a given technique.

The "visible changes" include updates to several process goals:

  • Intake Work. We refactored out several options from the Manage Work Items decision point to introduce a new decision point, Manage Backlog. We also updated the options for backlog management to reflect current industry practice.  This is a fairly important change that will be described in a detailed blog post.
  • Explore Scope. We updated the Choose a Backlog Management Strategy decision point to reflect changes to Intake Work. Early in a project it's critical to identify how you will manage your backlog later during Construction as this decision will inform your decision around how much detail to gather during Inception.
  • Measure Outcomes. We added several new potential metrics to existing options, and introduced the Increase Initiative Health decision point.
  • Organize Metrics. Added Aggregate Measures and Report Measures decision points.  An earlier blog, Apply Consistent Metrics Categories Across an Agile Portfolio, covers the key strategy for aggregating measures.  The report measures decision point is self explanatory, covering strategies such as status reports, metrics reports, automated dashboards, and more. 
  • Plan The Release. Updated estimation strategies.

We also updated the following process blades:

  • Continuous Improvement – Added the Analyze Root Cause decision point to the goal diagram.
  • Product Management – Added the Measure Offering decision point to describe explicit measurement options. Added the Capture Roadmap decision point to describe options for documenting/communicating your product roadmap.

It is important to note that for the DASM and DASSM exams that we are still testing you against the DA 5.0 version of the model.

Related Resources

Posted by Scott Ambler on: September 30, 2021 06:59 AM | Permalink | Comments (9)

Measure Outcomes - A New Process Goal

Categories: agile, goal-driven, goals, Scrum

We recently released the 5.2 version of the Disciplined Agile (DA) tool kit, and in that release we added three new process goalsIntake WorkOrganize Metrics, and Measure Outcomes.  The focus of this posting is the Measure Outcomes process goal, the goal diagram for which is posted in Figure 1.

 

Figure 1. The Measure Outcomes process goal diagram (click to enlarge).

Measure outcomes process goal

The Measure Outcomes process goal describes potential improvement outcomes, or improvement goals, and suggests potential metrics to measure progress against those outcomes. Disciplined Agile doesn't prescribe what to measure, that would be naive because every team is unique with its own priorities and desired outcomes. 

All of the potential outcomes in Figure 1 are important.  However, you will want to focus on a subset at any given time, and that subset is likely to evolve as your improvement focus evolves. Context counts. 

 

 

Related Resources

Posted by Scott Ambler on: July 22, 2021 12:00 AM | Permalink | Comments (4)
ADVERTISEMENTS

"If nominated I will not run, if elected I will not serve"

- General William T. Sherman

ADVERTISEMENT

Sponsors