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

The Disciplined Agile Enterprise (DAE) Layer

Disciplined Agile (DA)'s Value Streams Layer

The Disciplined DevOps Layer

Would you like to get involved with the 20th Anniversary of Agile?

The Four Layers of the Disciplined Agile Tool Kit

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)

How Geographically Distributed Are Agile Teams in Practice?

Many people, particularly those new to agile, will tell you that agile teams must be small and co-located.  That is certainly a smart way of organizing a team, but is isn’t required.  In fact agile teams are more likely to be geographically distributed in some way than they are to be co-located.  In practice, not theory.

In November of 2016 we ran the 2016 Agility at Scale survey.  It was targeted at people who were currently working on agile teams, or who had recently worked on agile teams, and we asked them straightforward questions around the size of the team, how distributed it was, what complexities they faced, an so on.  The following graph summarizes the responses around geographic distribution.

Geographic distribution and agile teams

The survey found that less than one-third of agile teams are near-located, where all of the IT members are either co-located or at least in a shared open space.  Previous studies have found that this number drops to one-in-ten teams being near located when you also include primary stakeholders.

Don’t let anyone tell you that you can’t do agile with a geographically distributed team because others are clearly doing so in practice.  Yes, geographically distributed agile is different than near-located agile, which is one of the reasons why you need to take a pragmatic, context-sensitive approach to agile solution delivery.  The Disciplined Agile (DA) toolkit provides the foundation from which to scale your approach to solution delivery to address a range of scaling factors, including geographic distribution.  In fact, you may find our article around geographically distributed agile teams to be an interesting read.

Related Posts:

Posted by Scott Ambler on: February 06, 2017 09:20 AM | Permalink | Comments (0)
ADVERTISEMENTS

"New York is my Lourdes, where I go for spiritual refreshment; a place where you're least likely to be bitten by a wild goat."

- Brendan Behan

ADVERTISEMENT

Sponsors

Vendor Events

See all Vendor Events