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


View Posts By:

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

Recent Posts

Embracing Mindset Diversity in Disciplined Agile

Disciplined Agile: An Executive's Starting Point

Using Lean Agile Procurement (LAP) in complex procurement situations

Vendor Management in the Disciplined Agile Enterprise

Asset Management: What Types of Assets Might You Manage?

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.

Release Management Goal Diagram

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.

Secure Funding process goal

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)

Does your team own its process or merely rent it?

Process ownership

An important philosophy within both the agile and lean communities is that a team should own its process. In fact, one of the principles behind the Agile Manifesto is “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.” The idea is that teams should be empowered to choose their way of working (WoW), to "own their process," including both their team structure and the process that they follow, to meet the unique needs of the situation that they find themselves in. Teams that own their process will tailor it over time as they learn how to work together, adopting new techniques and tweaking existing ones to increase their effectiveness.

As with most philosophies this one is easy to proselytize but not so easy to actually adopt. When it comes to process improvement, teams will exhibit a range of behavior in practice. Some teams see process as a problem and actively seek to ignore process-related issues. Some teams are ambivalent towards process improvement and generally stick with what they’ve been told to do. And some teams see process improvement as an opportunity to become more effective both as a team and as individuals. This range of behaviors isn’t surprising from a psychology point of view although it can be a bit disappointing from an agile or lean point of view. It has led me to think that perhaps some teams choose to “own” their process but many more still seem to prefer to simple rent it.

The behaviors of people who rent something are generally different than those who own something. Take flats for example. When you rent a flat (called an apartment in North America) you might do a bit of cosmetic work, such as painting and hanging curtains, to make it suitable for your needs. But people rarely put much more effort than that into tailoring their rental flat because they don’t want to invest money in something that isn’t theirs, even though they may live in the flat for several years. It isn’t perfect but it’s good enough. When you own a flat (called a condo in North America) you are much more likely to tailor it to meet your needs. Painting and window dressings are a good start, but you may also choose to renovate the kitchen and bathroom, update the flooring, and even reconfigure the layout by knocking down or moving some walls. One of the reasons why you choose to own a flat is so that you can modify it to meet your specific needs and taste.

You can observe similar behaviors when it comes to software process. Teams that are merely “process renters” will invest a bit of time to adopt a process, perhaps taking a two-day course where they’re taught a few basic concepts. They may make a few initial tailorings of the process, adopt some new role names, and even rework their workspace to better fit the situation that they face. From then on they do little to change the way that they work together. They rarely hold process improvement sessions such as retrospectives, and if they do they typically adopt changes that require minimal effort. Harder improvements, particularly those requiring new skills that require time and effort to learn, are put off to some point in the distant future which never seems to come. Such behavior may be a sign that this “team” is not even be a team at all, but instead a group of individuals who are marginally working together on the same solution. They adopt the trappings of the method, perhaps they spout new terminology and hold the right meetings, but few meaningful changes are actually made.

Process owners behave much differently. Teams that own their process will regularly reflect on how well they’re working and actively seek to get better. They experiment with new techniques and some teams will even measure how successful they are implementing the change. Teams that are process owners will often get coaching to help them improve, both at the individual and at the team level. Process owners strive to understand their process options, even the ones that are not perfectly agile or lean, and choose the ones that are best for the situation they find themselves in.

The Disciplined Agile (DA) tool kit is geared for teams that want to own their process. The DA tool kit is process goal-driven, not prescriptive, making your process choices explicit and more importantly providing guidance for selecting the options that make the most sense for your team. This guidance helps your team to get going in the right direction and provides options when you realize that you need to improve. DA also supports multiple life cycles because we realize that teams find themselves in a range of situations – sometimes a Scrum-based life cycle makes sense, sometimes a lean life cycle is a better fit, sometimes a continuous delivery approach is best, and sometimes you find yourself in a situation where an exploratory (or “Lean Startup”) life cycle is the way to go.

You have choices, and DA helps guide you to making the choices that are right for you in your given context. By providing process guidance DAD enables your team to more easily own its own process and thereby increase the benefit of following agile or lean approaches.

Posted by Scott Ambler on: March 03, 2014 07:37 AM | Permalink | Comments (1)

Agile Risk Management: A Disciplined Approach

Costa Concordia cruise ship that ran aground

We’ve recently been asked how risk management is addressed on agile teams. This is an easy question to answer because risk management strategies are built right into the Disciplined Agile (DA) toolkit.

Let’s start with two definitions. First, a risk is an exposure to a potentially negative outcome. Risks come about from uncertainty. Second, risk management is the identification, exploration, and mitigation of risks. Risk management should be part of both your team management efforts, even on self-organizing agile teams, as well as part of your organizations governance efforts.

Regardless of your delivery paradigm, there are several common categories of risks faced by IT delivery teams:

  • Business risk. This includes significant shifts in requirements due changing business priorities, often due to realization new market opportunities, in reaction to moves made by competitors, or because you are opening completely new market opportunities. Another common risk is an overly optimistic/aggressive schedule which motivates your team to take unfortunate shortcuts. A third type of business risk is a misaligned budget: either there isn’t sufficient funding to do the job effectively (e.g. there’s no travel budget for a geographically distributed team, there’s no funding for coaching on a team new to agile, there’s no funding for training, and so on) or there is far too much funding available and the team is motivated to invest it in wasteful activities.
  • Technical risk. IT teams face technical risks as the result of combining technologies in new ways, evolving technology platforms, new technologies, and lack of experience within the team in these situations.
  • Operational risk. This category of risk pertains to production-oriented issues surrounding the support and operation of a solution. Will your solution work within the existing organizational ecosystem? Does your operations team have the skills and resources to run your solution? Does your support/help desk team have the experience and knowledge required?
  • Process risk. As DAD clearly shows, every technique has advantages, disadvantages, and specific situations where the technique makes sense. The implication is that there are risks taken on when you apply a technique outside of its range of applicability or your comfort zone.
  • Organizational risk. IT teams face organizational risks such as dysfunctional politics, competing visions, challenges pertaining to your agile transformation challenges, reorganizations, and many others.

Recognizing that IT delivery teams must deal with risks on a regular basis DAD builds in several agile risk management strategies:

  • Continuous engineering practices.  This is a collection of practices with very short feedback cycles, thereby enabling you to adjust course quickly. These practices include behavior driven development (BDD), test-driven development (TDD), continuous integration (CI), continuous deployment (CD), and many others.  All of these practices require discipline and skill to adopt.  Although these practices are technical in nature, in practice they mostly reduce business risk through shortening the cycle between a stakeholder having an initial idea and the team providing a solution which reflects that idea.
  • Agile architecture practices.  The DA toolkit suggests a collection of continuous architecture strategies throughout the entire lifecycle.  These include, but are not limited to, identifying an initial technical strategy, proving the architecture early in construction, deferring architecture and design decisions to the most appropriate moment, architecture spikes, just in time (JIT) model storming, and many others.  These practices reduce technical risk.
  • Risk-value lifecycle.  The DA toolkit supports several lifecycles, and hence several work prioritization strategies.  One such strategy is the Unified Process (UP)’s risk-value approach where both risk and value are considered when prioritizing work items.  The end result is that work items with higher technical risk are implemented early in the lifecycle, enabling disciplined agile teams to mitigate technical risk early in the effort.  DAD teams then follow Scrum’s value-driven approach where the work is prioritized based on its business value to the organization, which is effective at addressing some forms of business risk.  The risk-value prioritization approach results in a lower overall risk profile than just the value-driven lifecycle of Scrum.  DAD also supports lean and continuous delivery versions of the lifecycle which expand upon the risk-value strategy to consider other factors such as required release dates and team health considerations.
  • An explicit Inception phase.  The fundamental purpose of the Inception phase is to help your team get going in the right direction.  Executed properly, the Inception phase helps you to reduce business risk by coming to stakeholder agreement regarding the team’s strategy, technical risk by exploring a viable technical strategy, and operational risk through planning with production-staff from the very beginning.
  • Risk-based, light-weight milestones.  The DAD lifecycles include explicit milestones as part of DAD’s overall governance strategy.  These milestones motivate teams to address common issues such as formulating an agreed-to vision early in the effort (business risk), proving the architecture early (technical risk), regularly considering the viability of the effort (business risk), ensuring the team has produced sufficient functionality to justify deployment (business risk), ensuring the solution is production ready (operational risk), and ensuring that the stakeholders are delighted with the result (business risk, organizational risk).
  • Development intelligence.  One of the governance strategies that the DAD process framework promotes is development intelligence (DI) where a team/project dashboard is populated with metrics generated automatically by the tools the team is using.  This provides real-time insight for the team to organize itself and potentially improve its approach.  It also provides insight into your organization’s governance effort, supplying real-time data which can enable senior management to make better decisions and thereby better support your agile teams.  Development intelligence, and it’s extension IT intelligence which addresses the entire IT portfolio and processes, helps you to reduce process risk and to a lesser extent organizational risk.
  • DevOps principles and practices. DAD weaves DevOps strategies through the entire framework.  This strategies are: Including operations and support staff as explicit stakeholders who work closely with the team; the lifecycle explicitly depicts production/operations; DevOps-oriented milestones (Production Ready and Delighted Stakeholders) are included as part of the governance strategy; development practices such as instrumenting solutions for operational monitoring, continuous deployment, and installation testing (to name a few); and management practices such as deployment planning. The strategies help to reduce both operational and organizational risks.
  • Sophisticated go-forward decision points.  One of the business risk management strategies promoted by Scrum and RUP is to make a “go/no-go” decision at the end of each sprint/iteration.   DAD takes this strategy further by recognizing that you have several options to consider – your team can continue with its current approach (go), it can stop (no-go), it can decide to change direction (pivot), or it can decide to experiment (run a split test).  The two new options are adopted from Lean Startup. DAD’s lean and continuous delivery lifecycles promote the idea that you make these go forward decisions when you need to, that you don’t need to wait until the end of an iteration to do so.
  • Risk-oriented process goal.  The DA toolkit promotes a non-prescriptive, process goal-driven approach.  DAD explicitly includes a goal, Address Risk, the goal diagram for which is presented below in Figure 1.

Figure 1. The Address Risk process goal.

Address Risk process goal


  • IT risk management is built in. IT-level risk management is built into the IT Governance process blade.  Although a risk may be small for a single team, when that same risk is taken by multiple teams in parallel in aggregate the risk may be more than your organization should take on.  Hence your risk management efforts at the delivery team level must be monitored regularly and aggregate risks mitigated appropriately. The process goal diagram for IT governance is shown below in Figure 2.

Figure 2. IT-risk management is an aspect of IT Governance.

Disciplined Agile IT Governance


Risk management isn’t explicitly built into first generation agile methodologies like Scrum or XP, although a handful of implicit risk mitigation techniques are.  As a result you still need to develop a risk management strategy for yourself when you limit your team to these sorts of agile methods.  The DA toolkit, on the other hand, has built risk management strategies into the toolkit in a lightweight and comprehensive manner.  From the point of view of process risk, having such guidance built into your process is a low-risk and desirable approach.  For further reading about risk management, we highly suggest the list of references maintained by Glen B. Alleman.

Posted by Scott Ambler on: November 28, 2013 04:00 AM | Permalink | Comments (0)

Exploring Scope on Disciplined Agile Teams

When a disciplined agile project or product team starts one of the process goals which they will likely need to address is Explore Initial Scope.  This is sometimes referred to as initially populating the backlog in the Scrum community, but as you’ll soon see there is far more to it than just doing that.  This is an important goal for several reasons.  First, your team needs to have at least a high level understanding of what they’re trying to achieve, they just don’t start coding.  Second, in the vast majority of organizations IT delivery teams are asked fundamental questions such as what are you trying to achieve, how long will it take, and how much will it cost.  Having an understanding of the scope of your effort is important input into answering those sorts of questions.

The process goal diagram for Explore Scope is shown below.  The rounded rectangle indicates the goal, the squared rectangles indicate issues or process factors that you may need to consider, and the lists in the right hand column represent potential strategies or practices that you may choose to adopt to address those issues.  The lists with an arrow to the left are ordered, indicating that in general the options at the top of the list are more preferable from an agile point of view than the options towards the bottom.  The highlighted options (bolded and italicized) indicate default starting points for teams looking for a good place to start but who don’t want to invest a lot of time in process tailoring right now.  Each of these practices/strategies has advantages and disadvantages, and none are perfect in all situations, which is why it is important to understand the options you have available to you.

Explore Scope process goal diagram

Let’s consider each process intent/decision point:

  • Choose the level of detail.  How much effort should you put into capturing the requirements, if any at all.  A small co-located team may find that capturing user stories on index cards to be sufficient, whereas a team that is geographically distributed across several locations will find that it needs to capture point-form notes about each story using an electronic tool, and a team in a life-critical regulatory environment may need to capture even more detail to the point of doing big requirements up front (BRUF).
  • Explore usage. Although much ado has been made of user stories, and they can be applied quite effectively in a range of situations, the fact is that they’re only one of several options for your team to explore usage of the solution (scenarios, personas, and use cases being other options).
  • Explore the domain. Some teams will choose to do some domain modeling via a data model or class diagram, as well as address other views as appropriate.
  • Explore the process. Many teams will discover that they need to explore the overall workflow, or business process, supported by their solution so as to help them better understand their usage requirements.
  • Explore user interface (UI) needs. Many agile teams will also choose to create user interface prototypes, either low-fidelity UI prototypes using paper or even high-fidelity UI prototypes using a prototyping tool or code, particularly when they face a complex domain.
  • Explore general requirements.  There are several types of functional requirements modeling techniques that can be valuable that don’t fit well into the previous categories.
  • Explore non-functional requirements.  How will non-functional requirements pertaining to availablity, security, performance, and many other issues be addressed?  Teams in straightforward situations may find that capturing them as technical stories may be sufficient.  Teams facing technical complexity, and sometimes even domain complexity, soon discover that they need a more sophisticated strategy.
  • Apply modeling strategy(ies).  How will your team go about working with stakeholders to elicit/discover their perceived needs?  Will they hold informal modeling sessions in an agile modeling space?  Will they hold formal modeling sessions, perhaps following a Joint Application Design (JAD) strategy?  Will they interview people one-on-one?  Combinations thereof?
  • Choose a work item management strategy.  Early in the project you will want to determine how you intend to address changing stakeholder needs throughout the project as this will affect how you address the other process issues in this list.  For example, do you intend to adopt Scrum’s value-driven product backlog strategy, DAD’s risk-value driven work item list, a lean work item pool strategy (as followed by DAD’s lean lifecycle), or even a formal approach?  A team in a strict regulatory environment may be required to have a more formal approach to change management than a team without this restriction.

I wanted to share two important observations about this goal.  First, this goal, along with Identify Architecture Strategy, Coordinate Activities, and Accelerate Value Delivery seem to take the brunt of your process tailoring efforts when working at scale.  It really does seem to be one of those Pareto situations where 20% addresses 80% of the work, more on this in a future blog posting.  As you saw in the discussion of the process issues, the process tailoring decisions that you make regarding this goal will vary greatly based on the various scaling factors.  Second, as with all process goal diagrams, the one above doesn’t provide an exhaustive list of options although it does provide a pretty good start.

I’m a firm believer that a team should choose their own way of working, including their team structure, their work environment, and their process, to reflect the situation that they find themselves in.  When it comes to process tailoring, process goal diagrams not only help teams to identify the issues they need to consider they also summarize potential options available to them.  Agile teams with a minimal bit of process guidance such as this are in a much better situation to tailor their approach that teams that are trying to figure it out on their own.  The DA tool kit provides this guidance.


Related Reading

Posted by Scott Ambler on: July 17, 2013 07:34 AM | Permalink | Comments (0)