Project Management

Disciplined Agile

by , , , , , ,
#ChooseYourWoW | #ContinuousImprovement | #Kaizen | #ProcessImprovement | Adoption | agile | Agile certification | agile transformation | Analogy | Architecture | architecture | book | Business Agility | Certification | Choose your WoW | CMMI | Coaching | Collaboration | Compliancy | Configuration management | Construction phase | Context | Continuous Improvement | COVID-19 | Culture | culture | DAD | DAD discussions | DAD roles | Data Management | database | DevOps | Discipline | disciplined agile delivery | Documentation | DW/BI | Enterprise Agile | Enterprise Architecture | Enterprise Awareness | Essence | Evolving DA | Experiment | Financial | GDD | Geographic Distribution | global development | Goal-Driven | goal-driven | goals | Governance | Guideline | Hybrid | Improvement | inception | Inception phase | Kanban | Large Teams | Lean | Lifecycle | lifecycle | Metrics | mindset | News | News and events | Non-Functional Requirements | non-functional requirements | Operations | Outsourcing | People | Philosophies | Planning | PMI | PMI and DA | Portfolio Management | Practices | Principle | Process | process improvement | Product Management | Product Owners | Program Management | Project Management | Promise | quality | Release Management | Requirements | requirements | Reuse Engineering | Risk management | RUP | Scaling | scaling | scaling agile | Scrum | Support | Surveys | Teams | Technical Debt | Terminology | Testing | testing | Toolkit | Transformation | Workflow | show all posts

About this Blog


View Posts By:

Scott Ambler
Glen Little
Mark Lines
Valentin Mocanu
Daniel Gagnon
Michael Richardson
Joshua Barnes

Recent Posts

Failure Bow: Choosing Between Life Cycles Flowchart Update

Evolving Disciplined Agile: Guidelines of the DA Mindset

Evolving Disciplined Agile: Promises of the DA Mindset

Evolving Disciplined Agile: Principles of the DA Mindset

Evolving Disciplined Agile: The DA Mindset

Explore Scope: Update


We just wanted to share a quick update with you. We’ve recently evolved the Explore Scope process goal based on feedback that we’ve received about our new book, Choose Your WoW!

Explore Scope process goal

The changes we’ve made to this process goal include:

  • Adding new scoping techniques. We added three scoping techniques that we’ve found effective in practice: modified impact maps, value proposition canvases, and event storming. 
  • Splitting “Explore Purpose” out of General Requirements. It became clear that a subset of the “General Requirements” options were focused on exploring the purpose of what we were doing, so we refactored them out into their own decision point.
  • Moving Level of Detail of the Scope Document to the bottom of the list. This is arguably the least important of all the decision points, so we moved it to the bottom of the list.

We’ve updated Choose Your WoW! to include this release of the Explore Scope process goal.  We will soon be updating Introduction to Disciplined Agile Delivery (DAD) 2nd Edition and An Executive’s Guide to Disciplined Agile, so if you have Kindle versions of these books expect updates to come through soon.

Posted by Scott Ambler on: April 10, 2019 08:05 PM | Permalink | Comments (0)

New goal: Develop Initial Test Strategy

Categories: Goal-Driven, Testing

Fire works

We have recently published a new Inception process goal, Develop Initial Test Strategy.  The potential need for this goal was identified a little over a year ago by an organization that we were actively working with and since then we have worked with several other organizations where it was also clear that this process goal was needed.

The basic idea is that during the Inception phase the team should consider developing an initial test strategy so as to identify how they will approach verification and validation. This includes thinking about how you intend to staff your team, organize your team, capture your plan, approach testing, approach development/programming, choose a platform for test environment(s) platform, choose a platform equivalency strategy, test non-functional requirements, automate test suites, obtain test data, automate builds, report defects, and govern your quality efforts. The goal diagram is depicted in Figure 1 and the update goals overview for Disciplined Agile Delivery (DAD) is shown in Figure 2.

Figure 1. The goal diagram for Develop Initial Test Strategy.

Develop Initial Test Strategy process goal

Figure 2. The process goals diagram for DAD.

The Process Goals of Disciplined Agile Delivery (DAD)

Posted by Scott Ambler on: January 30, 2017 01:02 PM | Permalink | Comments (0)

Principles for Effective Software Process Toolkits


The Disciplined Agile process decision toolkit is guided by the following principles:

  1. Choice is good, and making informed choices is better.  Every team is a collection of unique individuals that face a unique situation within the context of a unique organization. One process size does not fit all. To provide choice the DA toolkit supports several delivery lifecycles and is process goal driven. Most importantly the DA toolkit describes the tradeoffs involved with a myriad of agile and non-agile practices enabling people to make intelligent decisions regarding which practices to adopt given the current situation that they face.
  2. Optimize the whole. The DA toolkit addresses the full IT lifecycle, showing how it all fits together. Without an understanding of the larger process environment teams run the risk of locally optimizing their own processes to the detriment of the whole. For example, your data management team may have their own streamlined process based on traditional DAMA strategies, your delivery team may have their streamlined process based on the principles of the Agile Manifesto, and your operations team may have their streamlined process based on ITIL. Yet your overall process is ineffective because these three locally optimized strategies contradict and degrade one another when combined.
  3. Every team owns its process. Teams, and the individuals on them, must be free to improve the way that they work based on their learnings over time. In agile parlance we say that these teams “own their process”.
  4. Improve continuously. Individuals, teams, and organizations must strive to continuously learn and improve the way that they work. The DA toolkit includes the process goal Improve Team Process and Environment which describes options for doing exactly what its name implies. It also has an explicit process blade Continuous Improvement that describes strategies for sharing improvements across teams, thereby speeding up your organization’s process improvement efforts.
  5. Embrace process change. IT departments are complex adaptive systems. One implication of this is that any improvements that a team makes may change the way that they work with other teams, motivating process improvements within those teams. Those changes may motivate improvements within other teams and so on. Disciplined agile teams are enterprise aware and understand that they will need to work with other teams to help them to understand and adopt new innovations, and be prepared to be helped by others to do the same.
  6. Repeatable results are far more important than repeatable processes. Effective teams focus on producing repeatable results, such as delivering high-quality software that meets stakeholder needs in a timely and cost effective manner.  Because each team finds themselves in a unique situation, to be most efficient they need to follow a unique process tailored to reflect that situation.  That “unique process” may be comprised of a relatively standard lifecycle and common practices such as architecture envisioning, database regression testing, non-solo development, and many others (granted, those practices may be tailored to reflect the situation too).  Each team in your organization must be allowed to follow their version of the process, ideally sharing similar process components defined by a common process framework, to achieve the results required of them.
  7. Empiricism is far more important than theory. Observing how well a technique works in practice, and more importantly the context of the situations in which it (doesn’t) work is far more valuable to practitioners than theories or prognostications about what should work. Theory has its place, but it is a poor cousin to empiricism. The DA toolkit was originally developed based on observations of dozens of organizations worldwide, and has evolved since then based on learnings from many more. Furthermore it is backed up by our ongoing industry research.

IT departments are unique, complex adaptive systems. Anyone working in such environments needs a process framework that is sufficiently flexible to address the range of situations faced by your teams. The Disciplined Agile process decision framework is light-weight yet sufficiently flexible to support scaling at both the tactical and strategic levels.


Posted by Scott Ambler on: September 28, 2015 06:27 AM | Permalink | Comments (0)

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)

Disciplined Agile Enterprise Architecture: A Goal-Driven Approach

This posting, the latest in a series focused on a disciplined agile approach to enterprise architecture (EA), overviews the activities that a disciplined agile EA team may perform. Some methods will choose to prescribe a single approach, such as capturing architectural requirements in the form of epics or pre-building “architectural runways,” but the Disciplined Agile (DA) toolkit promotes an adaptive, context-sensitive strategy.  DAD 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 Enterprise Architecture process blade and overview its process factors.

The following diagram overviews the potential activities associated with disciplined agile enterprise architecture.

Disciplined Agile Enterprise Architecture

The process factors that you need to consider for enterprise architecture are:

  1. Support stakeholders. Enterprise architects will work with business and IT stakeholders on a regular basis to understand their needs and to help them develop a vision for the organization.
  2. Support delivery teams.  Enterprise architects will work with IT delivery teams, and ideally be active members of IT delivery teams, on a regular basis.  They may guide the teams in the business and technical roadmaps, help them to identify potentially reusable assets, to identify technical debt, and transfer their skills and knowledge to team members.
  3. Negotiate technical dependencies.  Like it or not, there are dependencies between the solutions that we create.  For example, if your system invokes a web service, or calls an API, provided by another system then you have a dependency on that system.  Enterprise architects will often find that they need to negotiate these dependencies with other teams, either at a high-level in their role of Enterprise Architect or sometimes at a detailed level in their role of Architecture Owner on a delivery team.
  4. Tailor architectural framework.  The enterprise architecture team may choose to adopt, and likely tailor, an existing enterprise architecture framework.  These frameworks typically suggest a multi-view collection of artifacts to create and techniques for doing so.
  5. Explore architectural views. Organizations are complex and as a result they must be understood from a variety of view points.  It’s not just a matter of writing “architectural epics” on a collection of index cards.
  6. Evolve enterprise architecture. Enterprise architects will collaborate with one another, and with their stakeholders, in a variety of ways.  They may choose to hold architecture envisioning/modeling sessions or regular meetings where they share learnings with one another.  They will often work together, or with IT delivery teams, to investigate new technologies or identify candidate architecture strategies.
  7. Evolve roadmap(s). An important output of your enterprise architecture effort will be one or more roadmaps describing your technology strategies and/or your architectural strategies. In agile organizations this roadmapping occurs in a rolling wave approach where the roadmap(s) are updated regularly.
  8. Capture enterprise architecture.  There are two broad categories for how enterprise architects can capture their work: as documents or as working/executable examples.  High-level models work well for documentation, although sometimes you may find the need for detailed documentation as well.  Executable artifacts, such as executable reference architectures or architectural runways, are usually preferred over documentation by delivery teams.
  9. Govern architecture. Architectural activities within your organization should be governed in a lightweight, collaborative manner.  This is an important activity for enterprise architects as well as for your IT governance team.

Our next blog posting will describe the workflow of enterprise architecture with other key IT activities such as portfolio management, reuse management, and IT delivery teams.

Related Readings

Posted by Scott Ambler on: June 03, 2015 01:24 PM | Permalink | Comments (0)

"If you havenÆt got anything nice to say about anybody, come sit next to me."

- Alice Roosevelt Longworth