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

Disciplined Agile and PMBoK Guide 7th Edition

Comparing Agile and Lean Backlog Strategies

Disciplined Agile 5.3 Released

Measure Outcomes - A New Process Goal

Organize Metrics - A New Process Goal

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 (3)

Organize Metrics - 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 Organize Metrics process goal, depicted in Figure 1.

 

Figure 1. The Organize Metrics process goal diagram (click to enlarge).

Organize metrics process goal

As the name implies, this process goal describes strategies to organize the metrics approach within your team. This strategy will be driven both by your team's culture and skills as well as the needs of your stakeholders - your metrics will likely need to "roll up" to the program or portfolio level.

Your metrics strategy will focus on several important questions:

  • What is the focus of our measure strategy?
  • How will we communicate measures both within the team and externally to our stakeholders?
  • How will we measure?
  • What types of measures will we take and communicate?

Where this goal focuses on how to measure, the Measure Outcomes goal describes what to potentially measure.

 

 

Related Resources

Posted by Scott Ambler on: July 21, 2021 12:00 AM | Permalink | Comments (0)

Intake Work - 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 goals: Intake Work, Organize Metrics, and Measure Outcomes.  The focus of this posting is the Intake Work process goal.

Intake Work: Added

Figure 1 depicts the process goal diagram for Intake Work (see How to Read Process Goal Diagrams).  This is how a team pulls in work from their "upstream" stakeholders. The incoming work is examined and if ready it is prioritized and put on the team's work backlog. We introduced this process goal because we wanted to have a cohesive source of process information capturing the issues around a common activity that is critical to your team's success.

Figure 1. The Intake Work process goal diagram (click to enlarge)

Intake work process goal diagram

 

To be effective at intaking work, we need to consider several important questions:

  • When are we going to accept any new work?
  • Is the request work ready for us to accept?
  • How are we going to prioritize work?
  • Who will prioritize the work?
  • What types of work needs to be prioritized?
  • How are we going to manage work items?

 

Address Changing Stakeholder Needs: Refactored

Part of the development of Intake Work was the refactoring of Address Changing Stakeholder Needs which previously captured several decision points that focused on intaking work and several on exploring stakeholder needs.  Figure 2 depicts the updated goal diagram.  Important changes include:

  • Several decision points - Prioritize Work (What), Prioritize Work (Who), Prioritize Work (How), and Manage Work Items - were moved from here to Intake Work.
  • The Explore Stakeholder Needs decision point was moved here from Produce a Potentially Consumable Solution, simplifying that goal and helping to focus this one.

Figure 2. The Address Changing Stakeholder Needs goal diagram (click to enlarge)

Address changing stakeholder needs process goal diagram

 

Related Resources

Posted by Scott Ambler on: July 20, 2021 07:06 AM | Permalink | Comments (7)

Disciplined Agile Release Management: A Goal-Driven Approach

This posting, the latest in a series focused on a disciplined agile approach to release management, overviews the activities associated with release management. The Disciplined Agile (DA) toolkit promotes an adaptive, context-sensitive strategy.  The framework does this via its goal-driven approach that indicates the process factors you need to consider, a range of techniques or strategies for you to address each process factor, and the advantages and disadvantages of each technique.  In this blog we present the goal diagram for the Release Management process blade and overview its process factors.

The following process goal diagram overviews the potential activities associated with disciplined agile release management.

The process factors that you need to consider for release management are:

  1. Plan IT release schedule.  Your organization’s overall release schedule needs to be planned and communicated.  Many organizations have blackout periods where teams are not allowed to deploy into production (for example, many retail organizations will not allow non-critical production releases near the Christmas holidays).  There are many strategies that organizations may choose to adopt when it comes to scheduling releases, including release trains, release streams, ad-hoc releases, and release windows.
  2. Schedule solution release.  The release of an individual delivery team’s work needs to be scheduled so that it does not conflict with the releases of other teams who want to deploy into the same operational environment.
  3. Manage infrastructure configuration.  The release management team will work closely with your operations team, in fact they are often members of your operations team, to perform configuration management of your operational environment.  To safely deploy into production you must know what is currently in production and how those hardware and software elements depend on each other.  The more complex your operational infrastructure, and the more IT delivery teams you have, the more important this process factor becomes.
  4. Determine production readiness.  Part of the release process is to verify that the solution is ready to be deployed and that the stakeholders are ready to have it deployed to them.  The bigger and more infrequent your releases, the more this becomes an issue.
  5. Support delivery teams.  The release management team, when a separate one exists, will work closely with the IT delivery teams to help them deploy successfully.  This help may take the form of coaching the team on deployment techniques, on planning, and even working with them to automate their deployments.  The release management team will often help with deployment testing, the verification after the fact that a deployment was in fact successful.
  6. Govern releases.  Your organization’s overall release efforts should be governed, ideally with the aim to streamline those efforts as much as possible.  This governance will include the development of policies and guidelines pertaining to the release process as well as the identification and collection of pertinent metrics.

Release Management and DevOps

Release management is an important part of your Disciplined DevOps strategy. Having said that, many IT departments are still in their early days of adopting a DevOps approach yet still effective release management.  The implication is that the way that you approach release management will vary depending on how far down the DevOps adoption path you are.  For example, with no DevOps in place at all your release management activities are likely to be performed by a team that is completely separate from your IT delivery teams.  When you are in the process of adopting a DevOps mindset release management is likely to be a collaborative effort between the IT delivery teams and the release management team.  When you have fully adopted DevOps strategies release management is mostly performed by the delivery teams themselves.

 

Related Postings

Posted by Scott Ambler on: July 18, 2015 07:40 AM | Permalink | Comments (0)

Improve Retrospectives with Process Goals

Retrospectives are a great way for teams to explore potential improvements to the way that they work.  A team will get together, discuss what is working well for them, what is not working so well, and hopefully identify ways that they could improve.  It’s this last activity that can be challenging.  You may know that your team is facing a problem but you might not understand your options.  For example, perhaps your team is struggling with the way that it is being funded.  The current funding mechanism is to estimate the cost up front and then allocate these funds to your team.  This motivates your team to be wary of changing requirements due to the fear of going over budget, something that decreases your ability to produce a solution that meets the true needs of your stakeholders.  You have suggested to management several times that a time and materials (T&M) approach would be more appropriate, but you have gotten nowhere with that conversation.

This is where DAD’s process goal-driven approach can help out.  In this case the goal Secure Funding provides some insight.  The process goal diagram, see below, along with the supporting descriptions of each technique, their advantages and disadvantages, and advice for when the technique is applicable can help your team to understand their options and hopefully argue for a better funding strategy.  Although a T&M approach might not be palatable to your financial team right now, perhaps they would be willing to consider a stage gate approach to funding.  Or, perhaps they would be open to a T&M approach but they just don’t understand the tradeoffs between T&M and fixed cost.  With DAD’s goal-driven approach the team can arm itself with the arguments that it needs to have a knowledgeable conversation with the actual decision makers.

Of course this is just one example.  The DA toolkit addresses a range of goals pertinent to successful agile solution delivery, all of which can provide team’s insight into potential process improvement options.  Knowing your options is an easy way to up your game during retrospectives.

Posted by Scott Ambler on: March 06, 2014 04:43 AM | Permalink | Comments (0)
ADVERTISEMENTS

"My goal is simple. It is complete understanding of the universe, why it is as it is, and why it exists at all."

- Stephen Hawking

ADVERTISEMENT

Sponsors