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 | estimation | Evolving DA | Experiment | Financial | GDD | Geographic Distribution | global development | Goal-Driven | goal-driven | goals | Governance | Guideline | Improvement | inception | Inception phase | Large Teams | layer | 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 | serial | Support | Surveys | Teams | Technical Debt | Terminology | Testing | testing | Toolkit | Transformation | velocity | Workflow | show all posts

About this Blog


View Posts By:

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

Recent Posts

The Four Layers of the Disciplined Agile Tool Kit

The Disciplined Agile Foundation Layer

The Team Lead Role: Different Types of Teams Need Different Types of Leaders

Disciplined Agile is a Hybrid


The Disciplined Agile Foundation Layer

Disciplined Agile Foundation Layer

The Disciplined Agile (DA) tool kit is organized into four layers: Foundation, Disciplined DevOps, Value Streams, Disciplined Agile Enterprise (DAE).  This blog focuses on the Foundation layer, the purpose of which is to provide the underpinnings of the DA tool kit.  The foundation layer itself is organized into four distinct topics:

  1. The DA mindset
  2. Fundamental concepts
  3. People
  4. Choosing your WoW


The DA Mindset

The Disciplined Agile Mindset

The Disciplined Agile (DA) mindset is captured in the form of principles, promises, and guidelines. Disciplined agilists believe in the DA principles, so we promise to adopt these behaviours and follow these guidelines when doing so. There is a purpose for each aspect of the mindset:

  • Principles. The principles provide a philosophical foundation for business agility. They are based on both lean and flow concepts.
  • Promises. The promises are agreements that we make with our fellow teammates, our stakeholders, and other people within our organization whom we interact with. The promises define a collection of disciplined behaviours that enable us to collaborate effectively and professionally.
  • Guidelines. These guidelines help us to be more effective in our way of working (WoW) and in improving our WoW over time.

The Disciplined Agile Mindset


Fundamental Concepts

Fundamentals of Agile, Lean, and Serial

Disciplined Agile (DA) is a hybrid in that it adopts ideas and strategies from a wide range of sources. DA encompasses three categories of fundamental concepts:

  1. Agile. Agile is both a mindset and a skillset. As a mindset Agile is the manner in how you look at your environment; it is the desire to collaborate with and to learn from others; and it is the willingness to share your skills and knowledge with others.  As a skillset Agile varies based on the domain in which you operate.  For example, an agile skillset for a marketing professional may include experimental strategies such as minimum viable products (MVPs) and marketplace sensing strategies, whereas an agile skillset for a software professional may include test-driven development (TDD) and chaos engineering techniques. Agility is the ready ability to move with quick and easy grace to respond to changes in your operating environment.  
  2. Lean.  Lean produces value for customers quickly through a focus on reducing delays and eliminating waste which results in increased quality and lower cost. Lean philosophies and strategies infuse DA, and in fact much of the DA mindset reflects lean thinking. This includes ideas such as optimizing flow, making all work and workflow visible, keeping workloads within capacity, and attending to relationships throughout the value stream to name a few. 
  3. Serial. DA adopts great ideas from serial - often referred to as traditional, waterfall, or even predictive - ways of working (WoW). There are many strategies and concepts from the past which are critical to our success in the future, and DA chooses to leverage them where they make sense. For example, DA's project-oriented lifecycles have explicit, named phases which are clearly serial in nature. DA recognizes that inception efforts, sometimes called  project initiation or simply initiation activities, such as initial planning, initial scoping, and initial design can be critical to your success.  These efforts are very different than the construction/realization efforts that happen after this, and different yet again than the transition/delivery efforts that then follow, and different again than the operational efforts that bring actual realized value to your customers.



Disciplined Agile Roles and Teams

The people portion of the Foundation layer addresses two key aspects of agility:

  1. Roles (and responsibilities). The DA tool kit captures a wide range of roles that people may fill.  This includes common agile roles such as Team Lead/Senior Scrum Master, Product Owner, Architecture Owner, and others.  It also includes function-specific roles such as Program Manager, Financial Specialist, Governor, Security Engineer, Sales Manager, and many others.  All of these roles have associated responsibilities, and of course there are common rights and responsibilities that everyone has.
  2. Teams. Every team is unique and faces a unique situation.  As a result, DA supports several team structures which your teams can adopt and evolve to meet their needs.  There are suggested structures for small, medium, and large (program) teams.  There are team structures that support geographic distribution.  There are team structures that support learning teams such as communities of practice (COPs)/guilds and centres of excellence (CoEs), and structures that support common services teams.


Choosing Your WoW

Choose Your WoW

A fundamental philosophy of agile is that teams should own their own process, or as we like to say in Disciplined Agile (DA) teams should choose their way of working (WoW). Of course this is easier said than done in practice. The challenge is that every team is unique and faces a unique situation – in other words, context counts. Furthermore, there are no “best practices,” rather, every practice has tradeoffs and works well in some situations and poorly in others. Worse yet, you really don’t know how well a technique will work for you until you actually try it out in your environment. Given all of this, how can a team choose its WoW?

While working with organizations to help them to learn how to improve their WoW, we’ve developed a technique that we call guided continuous improvement (GCI). GCI extends the kaizen-based continuous improvement approach, where teams improve their WoW via small incremental changes, to use proven guidance to help teams identify techniques that are more likely to work in their context. This increases the percentage of successful experiments and thereby increases your overall rate of process improvement.

Posted by Scott Ambler on: July 29, 2020 12:06 PM | Permalink | Comments (5)

Why are there phases?

Disciplined Agile Lifecycle - High Level

Yesterday Mark and I double teamed on a webcast overviewing DAD to a university class.  After the webcast we got the following question:

I am wondering if it would make sense to entirely eliminate the word “phase” from DAD’s vocabulary. What about simply talking about different types of iteration? For instance, inception could become something like “pre-construction iterations”, construction could become “construction iterations”, and transition “transitions iterations”…  That may be a bit cumbersome, but the word phase does scare people away.

Yes, the word phase might scare some people away.  We’ve thought long and hard about the terminology that we use and were also a bit worried about the word “phase” at first.  For some reason phase has become one of those dirty words in the agile community, along with other words such as governance or documentation.  The primary concern seems to be that phase implies a serial approach, something many agilists believe to be foul and evil.  Yet the reality is that projects do in fact proceed in a serial manner.  There are some project initiation activities at the start.  Then there are construction iterations/sprints one after the other in yes, a serial manner.  Then there is an effort to deploy/release your solution into production.  This is clearly “serial in the large”.

But, why the term phase?  Why not iteration?  Or season for that matter season (Gary Evans has a very coherent argument for that term)?  Because phase is accurate (albeit an agile swear word).  In the various IT surveys that I’ve run over the years I’ve found that the average agile team spends about 4.5 weeks performing initiation efforts, has construction iterations that are about 2 weeks in length, and takes an average of roughly 4 weeks to release their solution into production.  So perhaps these initiation and release efforts could each be thought of as two iterations (on average, your mileage may vary) but they really aren’t iterations in their own right usually.  Maybe they’re different length iterations?  There are several ways of thinking about it, but notice how the application of the term iteration doesn’t really make perfect sense.  Then we have numbering issues.  Is the initiation effort iteration/sprint 0?  If it’s two iterations would they be -1 and 0?  Sigh.

One thing that we have done which some may feel to be radical is we’ve chosen to adopt phase names from Unified Process (UP) – Inception, Construction, and Transition.  We could have made up different names, such as Initiation, Development, and Release respectively.  Or adopted Start Up, Construction, and Hardening (yuck, there’s more to Transition than hardening and frankly I would consider a late “hardening” effort to be a clear sign you’ve likely got a process problem you need to deal with).  And I have no doubt that there are many other options for each phase name.  Whatever names we choose someone isn’t going to be happy, and why not give a bit of a nod to a proven software development framework such as UP?

Another interesting thought is that by having named phases it makes it clearer where potential governance points in the lifecycle are.  In the diagram below you can see how several of the suggested light-weight milestones – Stakeholder vision, Sufficient functionality, and Delighted stakeholders – corresponds to the end of a phase.  Or perhaps more accurately, fulfilling the milestone is an indication that your team is moving from one phase to the next.


In the end, I think we’re pretty clear that when you tailor DAD that you can use whatever terminology you like.  In fact one financial institution that adopted an early version of the DAD basic lifecycle, the one based on Scrum, reworked the diagram to use Scrum terminology.  I think it’s a bit goofy but it works for them.

The term phase might in fact scare a few people away.  But, it’s hard to imagine that anyone that concerned about what something is named will be flexible enough to be successful at DAD anyway.

Posted by Scott Ambler on: February 08, 2012 06:36 PM | Permalink | Comments (0)

"Man is a game-playing animal, and a computer is another way to play games."

- Scott Adams