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:

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

Recent Posts

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?

PMI and Disciplined Agile at Agile20Reflect

Update: Scaling Factors of Tactical Agility

Categories: Context, scaling

Scaling Factors Update

We've have recently updated our thinking around the tactical scaling factors that we apply in DA to help understand the context faced by a team or organization. Figure 1 depicts the original scaling factors and Figure 2 the new scaling factors.  Below we discuss what changed and how this can affect anyone taking a Disciplined Agile (DA) certification exam.

 

Figure 1. The (original) scaling factors of the SDCF.

Scaling factors of the Software Development Context Framework (SDCF).

 

Figure 2. The scaling factors of the SCF.

Scaling Factors of the Situation Context Framework (SCF)

What's Changed?

The changes we made were motivated by our experiences applying the scaling factors outside of IT teams.  Originally these scaling factors were described by the Software Development Context Framework (SDCF) which we evolved into the Situation Context Framework (SCF) in late 2020.  Here is what has changed:

  1. Renamed Technical Complexity to Solution Complexity so as to generalize the concept.
  2. Added Skill Availability as a scaling factor. 
  3. Reworked the naming of several options for the scaling factors to make the spectrum of choices clearer and more general.

 

Implications for DA Certification Exams

As you can see in Scaling Factors we have made it clear that the exam will test you for knowledge about the original version for now (in Figure 1) and that when we update the courseware and exam to reflect this update we will let you know. In general our intent is that whenever material on the web gets ahead of what is being tested for that we'll make it clear that this has happened.  More on this in a future blog posting.

 

Further Reading

  1. The blog posting Choosing Your WoW: The Situation Context Framework (SCF) overviews the SCF in detail, including descriptions of each scaling factor.
  2. The article Scaling Factors provides a good summary of the scaling factors portion of the SCF.
  3. The article Tactical Agility at Scale: Scaling Agile at the Team Level provides a summary for how DA applies the SCF.

 

 

 

 

 

 

 

Posted by Scott Ambler on: January 19, 2021 03:59 PM | Permalink | Comments (2)

Is it Disciplined Agile Delivery (DAD) or Disciplined Agile (DA)?

Categories: scaling, Toolkit

The quick answer is of course “Yes”.  ??

A couple of years ago we caused a bit of confusion when we expanded the scope of Disciplined Agile Delivery (DAD) to address the activities of an information technology (IT) department.  When we did this we realized that the scope of the toolkit and the name no longer matched, so we decided to rebrand to be simply the “Disciplined Agile (DA)” toolkit.  Having said that, sometimes it makes sense to say DAD and sometime DA depending on what you’re focusing on at the time.

The Scope of Disciplined Agile (DA)

As you can see in the following diagram, which depicts the scope of the DA toolkit, it’s clear why there has been some confusion because DA covers a lot of ground.

Scope of Disciplined Agile

Let’s explore each aspect depicted in the diagram:

  1. Disciplined Agile Delivery (DAD).  DAD addresses all aspects of solution delivery from beginning to end, in a streamlined manner.  This includes initial modelling and planning, forming the team, securing funding, continuous architecture, continuous testing, continuous development, and governance all the way through the lifecycle.  The framework includes support for multiple delivery lifecycles, including but not limited to a agile lifecycle based on Scrum, a lean lifecycle based on Kanban, and a modern agile lifecycle for continuous delivery.
  2. Disciplined DevOpsDisciplined DevOps is the streamlining of IT solution development and IT operations activities, and supporting enterprise-IT activities, to provide more effective outcomes to an organization.
  3. Disciplined Agile IT (DAIT).  As the name suggests DAIT addresses how to apply agile and lean strategies to all aspects of IT.  This includes IT-level activities such as enterprise architecture, data management, portfolio management, IT governance, and other capabilities.
  4. Disciplined Agile Enterprise.  A Disciplined Agile Enterprise is able to anticipate and respond swiftly to changes in the marketplace.  It does this through an organizational culture and structure that facilitates change within the context of the situation that it faces.  Such organizations require a learning mindset in the mainstream business and underlying lean and agile processes to drive innovation.

Some History

The first “1.0 release” was the original Disciplined Agile Delivery book in June of 2012.  As the title suggests the focus was on DAD, although it laid the groundwork for Disciplined DevOps in that it baked in the development side of DevOps right into DAD.  In 2015 we began publishing our work in both Disciplined DevOps and Disciplined Agile IT (DAIT) and renamed the toolkit to Disciplined Agile (DA) to reflect this expanded scope. Since 2017 we have begun to flesh out Disciplined Agile Enterprise strategies and will soon begin the share them here on this site.

Posted by Scott Ambler on: April 18, 2017 05:52 AM | Permalink | Comments (0)

Can You Outsource and Still Be Agile?

Categories: Outsourcing, scaling

We often hear that agile software development is fine for small co-located teams, but that you couldn’t possibly take an outsourcing approach with agile.  The customer organizations would love to do agile but are convinced that vendors are unable to do so, and the vendor organizations typically say they’d love to be agile but that the customers don’t ask them to work that way.  It’s a fair question to ask if agile and outsourcing are being combined in practice, so we decided to look into this issue.

The following diagram summarizes the responses to our question from our 2016 Agility at Scale study around whether agile teams were organizationally distributed (one of the tactical scaling factors potentially faced by agile teams).  As you can see, over half of agile teams are organizationally distributed in some way, with 58% of agile teams including contractors, consultants, or outsourcers in some way.  Interestingly, about one agile team in six includes outsourcing.

Agile and outsourcers, contractors, and consultants

Answering the question of how to be successful at agile and outsourcing is worthy of a detailed article in its own right, something we’ll do in the near future.  Until then, here are some initial thoughts based on our observations at multiple organizations around the world:

  1. It starts with procurement.  If you want a service provider to provide a team that is capable of working in an agile manner then that is what you need to procure.  A traditional procurement process that is looking for a team to work from a detailed requirements specification up front, that is expected to focus on development and then hand off their work for another team to perform “final testing”, is pretty much hobbled from the very beginning.  It is very possible, and highly desirable, to have a procurement process that is capable of procuring agile software development services.  In fact, there is a wealth of knowledge out there about agile contracting if you choose to look into it.
  2. The customer must work in an agile manner.  There are several key strategies to support this:
    • Negotiate how you will work together up front.
    • Take a light-weight, evolutionary approach to requirements.
    • Provide a technical roadmap.
    • Fly a few key people to the service provider.
    • Consider co-locating your Product Owner with the service provider.
    • Provide your development guidelines to the service provider.
    • Actively govern the team.
    • Respect the service provider.
  3. The service provider must work in a disciplined agile manner.  There are several key strategies to support this:
    • Be trustworthy.
    • Be truly transparent.
    • Have one-week iterations/sprints.
    • Include code analysis tools in your builds.
    • Provide the customer access to your team’s automated dashboard.
    • Align your culture to that of the customer.

We will write a more detailed article that expands on these points in the near future.  Stay tuned!

Related Posts

Posted by Scott Ambler on: March 03, 2017 05:23 AM | Permalink | Comments (0)

Do Agile Teams Take on Hard Problems?

Categories: Domain complexity, scaling

We often hear that agile software development is fine when you face a simple problem, but that agile isn’t sufficient for more difficult problems.  Of course this falsehood is promoted by people who have little or no agile experience, or who have been involved with a failed “agile adoption” (usually these teams adopted ad hoc strategies thinking they were agile).  Anyway, we decided to look into whether agile teams are taking on hard domain problems in practice.

The following diagram summarizes the responses to our question around agile teams and compliance from our 2016 Agility at Scale study.  As you can see, 40% of respondents indicated that their agile team faced either complex or very complex problems, and that a further 38% faced medium complexity.  Interestingly, only one in eight respondents said that their team faced a straight forward problem.

Agile and Domain Complexity

The bottom line is that agile strategies, and in particular disciplined agile strategies, are in fact applicable for taking on complex problems.  More importantly, this is happening in practice around the world on a regular basis.

Related Posts

Posted by Scott Ambler on: February 19, 2017 02:53 PM | Permalink | Comments (0)

Do Agile Teams Face Regulatory Compliance?

Categories: Compliancy, scaling

We often hear that agile is great for simple situations but as soon as you face compliancy issues that it doesn’t work.  Is it possible to be agile when you face regulatory compliance, such as PCI and FDA compliancy?  Is it possible to be agile when you face organizational compliance, such as working in a CMMI regime?  Important questions that we decided to look into.

The following diagram summarizes the responses to our question around agile teams and compliance from our 2016 Agility at Scale study.  As you can see, 62% of respondents indicated that their agile team faced some form of regulatory compliance, 20% some form of organizational compliance, and 15% said both.  In fact, two-thirds of agile teams operate under one or more compliancy requirements.

Agile Regulatory Compliance

For further reading about compliancy, please read our detailed blog posting Agile and Regulatory Compliance.

Related Posts

Posted by Scott Ambler on: February 15, 2017 08:40 PM | Permalink | Comments (0)
ADVERTISEMENTS

"It is better to have a permanent income than to be fascinating."

- Oscar Wilde