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

The Disciplined DevOps Layer

Disciplined DevOps

The Disciplined Agile (DA) tool kit is organized into four layers, overviewed in Figure 1.  These layers are: Foundation, Disciplined DevOps, Value Streams, and Disciplined Agile Enterprise (DAE).  This blog focuses on the Disciplined DevOps layer.

Figure 1. The layers of the DA tool kit.

Disciplined Agile Layer Overview

How is "Disciplined DevOps" different from normal/mainstream DevOps? Mainstream DevOps is the streamlining of software development, information technology (IT) operations, and support.  This strategy is often depicted as an infinite loop as you see in Figure 2.  Disciplined DevOps is an enterprise-ready approach that extends mainstream DevOps to include critical activities around security, data management, release management, and business operations.  The high-level workflow for Disciplined DevOps is depicted in Figure 3

Figure 2. The classic DevOps workflow.

DevOps infinite loop

 

Figure 3. The workflow of Disciplined DevOps.

Disciplined DevOps workflow

Let's explore the components of Disciplined DevOps.  The hexes in Figure 3 represent process blades, sometimes called process areas. A process blade encompasses a cohesive collection of process options, such as practices and strategies, that should be chosen and then applied in a context sensitive manner.  Process blades also address functional roles specific to that domain as well as extensions to the DA mindset specific to that domain. The process blades of Disciplined DevOps are:

  1. Disciplined Agile Delivery (DAD)
  2. Security
  3. Data Management
  4. Release Management
  5. Support
  6. IT Operations
  7. Business Operations (from the Value Streams layer)

 

Disciplined Agile Delivery (DAD)

Disciplined Agile Delivery (DAD) is a people-first, learning-oriented hybrid approach to solution delivery. DAD teams focus on the creation of a new, or evolution of an existing, consumable solution for their customers.  A solution may include any combination of software, physical assets (e.g. hardware), documentation, changes to the supported business process, and changes to the organizational structure(s) of the people involved. A solution is consumable when it is usable, desirable, and functional. DAD enables a flexible way of working (WoW), supporting several lifecycles in a manner that is tactically scalable.

Security

The Security process blade focuses on how to protect your organization from both information/virtual and physical threats. This includes procedures for security governance, identity and access management, security policy management, incident response, and vulnerability management. As you would expect these policies will affect your organization’s strategies around change management, disaster recovery and business continuity, solution delivery, and vendor management. For security to be effective it has to be a fundamental aspect of your organizational culture.

Data Management

Data management is the development, execution and supervision of plans, policies, programs and practices that control, protect, deliver and enhance the value of data and information assets. DA promotes a pragmatic, streamlined approach to data management that fits into the rest of your organizational processes – we need to optimize the entire workflow, not sub-optimize our data management strategy. Disciplined agile data management does this in an evolutionary and collaborative manner, via concrete data management strategies that provide the right data at the right time to the right people.

Release Management

The release management process blade encompasses planning, coordinating, and verifying the deployment of solutions into production. Release management requires collaboration by the team(s) producing the solutions and the people responsible for your organization’s operational environment(s). In the case of organizations with a “you build it, you run it” DevOps mindset these people may be one in the same, although even in these situations you will often find a group of people responsible for governing the overall release management effort. In a true DevOps environment release management is fully automated for the intangible aspects (e.g. software and supporting documentation), and perhaps even some physical aspects, of your solution.

Support

Support focuses on helping customers/end users to work with the solutions produced by your delivery teams. Ideally your solutions should be designed so well that people don’t need anyone to help them but unfortunately it doesn’t always work out that way. So in many ways your support strategy is your “last line of defense” in your efforts to Delight Customers. Support goes by many names, including help desk, customer support, and customer care.

IT Operations

The primary aim of IT operations is to run a trustworthy IT ecosystem. From the point of view of your customers, you want to do such a good job that they don’t even notice IT. For older organizations this can be a challenge due to the existence of hundreds, if not thousands, of legacy systems that have been deployed over the decades. You may face daunting technical debt in these systems – poor quality data, overly complex or poorly written source code, systems with inadequate automated regression tests (if any), different versions of the same system, several systems offering similar functionality, numerous technology platforms, systems and technologies for which you have insufficient expertise, and more.

Business Operations

Business operations is one of the process blades of the value stream layer, although as you see in Figure 3 it is a critical component of the Disciplined DevOps workflow. Business operations focuses on the activities required to provide services to customers and to support your products. The implementation of business operations will vary by value stream, in a bank retail account services is implemented in a very different manner than brokerage services for example. Business operations includes help desk and support services (integrated in with IT support where appropriate) as well as any technical sales support activities such as training, product installation, and product customization. As you can imagine close collaboration with both your Sales and Marketing efforts is required to successfully Delight Customers.

Posted by Scott Ambler on: September 29, 2020 10:55 AM | Permalink | Comments (3)

An Exploratory

Categories: agile, DAD, Lean Startup, lifecycle, SDLC

One of the key philosophies of the Disciplined Agile (DA) toolkit is that it presents software development teams with choices and guides them through making the right choices given the situation they face.  In other words, it helps them to truly own their process.  Part of doing so is to choose the software delivery lifecycle (SDLC) that is the best fit for their context.  In this blog posting we overview the DAD Exploratory lifecycle which is based in part on Lean Startup strategies.

This lifecycle can be applied in two ways:

  1. As a replacement of the Inception phase of other lifecycles.  In the Inception phase we invest a short yet sufficient amount of time and effort to validate that the initiative being considered makes sense and to gain agreement on the stakeholders’ vision.  In a situation where the actual need and value of what is being proposed is in question this approach is a very good way to determine the true market need before scaling up the initiative and moving into the Construction phase.
  2. As the implementation approach in the Construction phase.  After applying the Exploratory approach to validate your vision, a decision needs to be made regarding which of the four DAD lifecycles to apply as we move into Construction. For instance, you may choose to use DAD’s Scrum-based basic agile lifecycle if there is sufficient confidence from the learnings in the Inception phase regarding the viability of the vision.  However, if there remains some uncertainty regarding the feature set to be delivered it may make more sense to continue using the Exploratory lifecycle to build out the product in Construction.

The following diagram overviews the DAD Exploratory lifecycle.  This lifecycle is followed by agile or lean teams that find themselves in startup or research situations where their stakeholders have an idea for a new product but they do yet understand what is actually needed by their user base.  As a result they need to quickly explore what the market wants via a series of quick learning experiments.

DAD Exploratory lifecycle

Now let’s describe how the Exploratory lifecycle works.  There are six activities to this lifecycle:

  1. Envision.  Your team will explore the idea and identify a potential implementation strategy for implementing it.  This could be as simple as getting a few people together in a room to model storm both the business vision and your technical options on whiteboard and paper.  You want to do just enough thinking to identify a viable hypothesis for what your customers actually want.  This hypothesis needs to be testable, which implies that you need to identify how you are going to measure the effectiveness of the new functionality that you produce.
  2. Build a little.  Your team should invest just enough effort to build a solution that tests the hypothesis.  In lean parlance you want to build what’s known as a minimally viable product (MVP).  The amount of effort will vary, from several days to several weeks – your goal is to make something available very quickly so that you can test your hypothesis.
  3. Deploy.  Once your current solution is ready it is deployed into an environment where you can test your hypothesis. This deployment may be to a subset of your customers, in many ways what used to be called an “alpha” or “beta” release, so that you can determine whether the solution is of interest to them.
  4. Observe & measure.  Once the solution is available in production you want to determine what aspects of it, if any, are of interest to your user base.  To do this you will need to instrument your solution so that it logs data regarding important events within it.  For example, you may decide to record when a screen/page is accessed, when a sale occurs, when certain business functions are invoked, and so on.  The idea is that you want to understand which functionality end users find useful, which functionality leads to customer retention, which functionality leads to greater sales, … whatever is important to you.  Generation of this data enables you to monitor, to observe and measure, how well the new functionality is received by your user base.  This in turn allows you to make a fact-based go-forward decision.  If the functionality is well received then you may choose to continue with the existing strategy and add more functionality.  Or your strategy may be so successful that you decide that you’re ready to productize the development of this solution. If the functionality wasn’t well received your team might choose to pivot and continue in another direction or even give up completely.
  5. Cancel.  Sometimes you discover that the product idea isn’t going to work out after all.  In fact, this is particularly common in research and development (R&D) environments as well as start ups.  The advantage is that if an idea is going to fail, then it is better that you learn that it’s a failure quickly so that you can devote your energies into other strategies.
  6. Productize.  After several iterations of building a little, deploying, and then observing & measuring that you’ve identifying a product that will be successful in the marketplace (or in the case of internal application development successful with your user base).  As described above, although you may choose to continue following this lifecycle, a common decision is for the team to adopt one of the other DAD lifecycles – such as the Scrum-based agile lifecycle, the Kanban-based Lean lifecycle, or the Continuous Delivery lifecycle – and effectively treat the time they spent following this lifecycle as their Inception phase.

To summarize, the DAD process framework takes a flexible, non-prescriptive approach to software-based solution delivery.  As a result of this philosophy DAD supports several development lifecycles, one of which is the Lean-Startup-based Exploratory lifecycle described in this posting.  This lifecycle is typically followed in situations where you are unsure of what your user base wants, and sometimes even when you are unsure of who your user base (your customers) will even be.

Posted by Scott Ambler on: April 25, 2014 05:11 AM | Permalink | Comments (0)

Got Discipline?

Categories: agile, DAD, Discipline, discipline

Got Discipline

A common question we get regarding Disciplined Agile Delivery (DAD) is “What makes DAD more disciplined than other approaches to agile?”  It’s a fair question, particularly from someone who is new to DAD.  This blog posting explores this question, explicitly summarizing the critical strategies that exhibit the greater levels of discipline in DAD as compared with what Mark and I see in many agile teams today.

It is clear that many common agile practices require discipline.  For example, agile teams it takes discipline to hold concise, streamlined coordination/Scrum meetings; to consistently deliver business value every iteration; to test continuously throughout the lifecycle; to improve your process “in flight”; to work closely with stakeholders and many more things.  Discipline is very important to the success of agile teams, see The Discipline of Agile for a detailed discussion, and DAD takes it to the next level in the following ways:

  1. Reducing the feedback cycle. Techniques that shorten the time between doing something and getting feedback about it are generally lower risk and result in lower cost to address any changes than techniques with longer feedback cycles.  Many of these techniques require agile team members to have new skills and to take a more disciplined approach to their work than they may have in less-than-agile situations.  There are several common ways to shorten the feedback cycle that are common to agile software development that are adopted by DAD.  These techniques, listed in order of immediacy, include non-solo development (e.g. pair programming), active stakeholder participation, continuous integration (CI), continuous deployment (CD), short iterations/sprints, and short release cycles.
  2. Continuous learning. Continuous learning is an important aspect of agile software development in general, not just DAD.  However, DAD explicitly addresses the need for three levels of learning: individual, team, and organizational/enterprise.  It also addresses the need for three categories of learning: domain, technical, and process.  Continuous learning strategies include active stakeholder participation, coaching, mentoring, individual learning, non-solo development, proving the architecture with working code, spikes, retrospectives/reflections, sharing lessons learned between teams, and stakeholder demonstrations.
  3. Incremental delivery of consumable solutions.  Being able to deliver potentially shippable software increments at the end of each iteration is a good start that clearly requires discipline.  The DAD process framework goes one step further and advises you to explicitly produce a potentially consumable solution every iteration, something that requires even greater discipline.  Every construction iteration your team requires the discipline to create working software that is “done”, to write deliverable documentation such as operations manuals and user documentation, to address consumability (usability), to consider organizational change issues pertaining to your solution, and operations and support issues (an aspect of DevOps).
  4. Being process goal-driven.  The DA toolkit promotes a process goal-driven approach. For each goal we describe the issues pertaining to that the goal. For example, with initial project planning you need to consider issues such as the amount of initial detail you intend to capture, the amount of ongoing detail throughout the project, the length of iterations, how you will communicate the schedule (if at all), and how you will produce an initial cost estimate (if at all). Each issue can be addressed by several strategies, each of which has trade-offs. Our experience is that this goals-driven, suggestive approach provides just enough guidance for solution delivery teams while being sufficiently flexible so that teams can tailor the process to address the context of the situation in which they find themselves in. The challenge is that it requires significant discipline by agile teams to consider the issues around each goal and then choose the strategy which that is most appropriate for them.
  5. Enterprise awareness.  Whether you like it or not, as you adopt agile you will constrained by the organizational ecosystem, and you need to act accordingly.  It takes discipline to be enterprise aware and to work with enterprise folks who may not be completely agile yet, and have the patience to help them.  It takes discipline to work with your operations and support staff in a “DevOps” manner throughout the lifecycle, particularly when they may not be motivated to do so.  Despite the fact that governing bodies such as project management offices (PMOs), architecture and database authorities, and operations may indeed be a source of impediments to your DAD adoption, these authorities serve important functions in any large enterprise.  Therefore a disciplined approach to proactively working with them and being a positive change agent to make collaboration with them more effective is required.
  6. Adopting a full delivery lifecycle.  Despite some agilists reluctance to admit that projects go through phases the DAD process framework explicitly recognizes that they do.  Building serious solutions requires a lot more than just doing the cool construction stuff.  It takes discipline to ignore this rhetoric and frame your project within the scope of a full delivery lifecycle.  The basic and advanced DAD lifecycles explicitly depict pre-delivery activities, a three-phase delivery lifecycle, and post-delivery activities (operations and support).
  7. Streamlining inception activities.  We devoted a lot of material in the DAD book to describing how to effectively address how to initiate a DAD project.  Unfortunately in our experience we have seen many organizations treat this phase as an opportunity to do massive amounts of upfront documentation in the form of project plans, charters, and requirements specifications.  Some people have referred to the practice of doing too much transitory documentation up front on an agile project (known as Sprint 0 in Scrum) as Water-Scrum-Fall.  We cannot stress enough that this is NOT the intent of the Inception phase.  While we provide many alternatives for documenting your vision in Inception, from very heavy to very light, you should take a minimalist approach to the Inception phase and strive to reach the stakeholder consensus milestone as quickly as possible.  If you are spending more than a few weeks on this phase, you may be regressing to a Water-Scrum-Fall approach.  It takes discipline to be aware of this trap and to streamline your approach as much as possible.
  8. Streamlining transition activities.  In most mid-to-large sized organizations the deployment of solutions is carefully controlled, particularly when the solutions share architectures and have project interdependencies.  For these reasons release cycles to your stakeholders are less frequent that you would like because of existing complexities within the environment.  However, the ability to frequently deploy value to your stakeholders is a competitive advantage; therefore you should reduce the release cycle as much as possible.  This requires a great degree of discipline in areas such as pre-production integration and deployment testing; regular coordination between project teams and with operations and support staff; Change management around both technology and requirements; and adoption of continuous deployment practices to such a degree that very frequent deployments are the norm and the Transition “phase” becomes an automated transition activity.
  9.  Adopting agile governance. It is easier to avoid your traditional governance and tell management that “agile is different” than it is to work with your governors to adapt your governance to properly guide the delivery of your agile teams.  Every organization has a necessary degree of governance and there are ways to make it especially effective on agile initiatives.  It takes discipline to work with your governors to help them understand how disciplined agile teams operate and then discipline to accept and conform to the resulting governance process.
  10. Moving to lean. For all DAD process goals we describe a range of options to address the issues pertaining to that goal.  These options ranged from traditional/heavier approaches that we generally advised against except in very specific situations to agile strategies to very lean strategies.  Generally, the leaner the strategy the greater the discipline it requires.

Adopting a disciplined approach to agile delivery requires the courage to rethink some of the agile rhetoric and make compromises where necessary for the benefit of the “whole enterprise” and not just the whole team.  In our experience most agile projects make certain compromises that are not classically agile in order to get the job done.  Rather than hiding this and fearing reprisals from those who would accuse you of regressing to a traditional approach, it is better to have the courage to take a pragmatic approach to using agile in your situation.

Effective application of DAD certainly requires discipline and skill, but in our experience the key determinant of success is the ability and willingness of the team to work well together and with  stakeholders, both within and external to the team.  For more writings about discipline within DAD, select “Discipline” from the blog category list.

Posted by Scott Ambler on: October 16, 2013 04:45 AM | Permalink | Comments (0)

Adopting a Full Lifecycle Requires Discipline

Categories: agile, DAD, lifecycle

Despite some agilists reluctance to admit that projects go through phases the DAD process framework explicitly recognizes that they do.  Building serious solutions requires a lot more than just doing the cool construction stuff.  It takes discipline to ignore this rhetoric and frame your project within the scope of a full delivery lifecycle.  The Agile (Scrum-based) and Lean (Kanban-based) DAD lifecycles explicitly depict:

  1. Pre-delivery activities.  There are portfolio management activities which occur long before your project begins, including the initial identification of potential projects, their prioritization, and finding initial funding for the Inception phase.
  2. Three-phase delivery lifecycle.  Projects have phases that they go through.  All efforts are initiated at some point, all of them go through a construction effort (or a configuration effort in the case of purchased solutions), and hopefully some sort of deployment effort.  This is why the DAD lifecycles include explicit Inception, Construction, and Transition phases to respectively address these aspects.  We’ve confirmed via surveys that the agile teams invest time in project initiation/inception activities, often referred to as Sprint 0 or Iteration 0, and time performing release/transition activities.  From a product point they will go through at least the Construction and Transition phase many times throughout the life of the solution.
  3. Post-delivery activities.  The fact that your solution is operated and supported in production, or in the marketplace for commercial products, is included.  We do this to reflect the DevOps reality many DAD teams are in the position that they are working on a new release of an existing solution, and therefore are very likely to be getting defect reports and enhancement requests coming in about previous versions.  As a result they require the discipline to treat these things as potential new requirements and act accordingly.

Without a doubt construction is an important aspect of the overall Disciplined Agile Delivery process, but it’s not the only aspect.  Yes, for many people this is the fun part of delivery, it certainly is for me.  But the reality is that as development professionals we need to explicitly consider more than just construction if we’re to be effective.  It takes discipline to adopt a broader lifecycle that goes beyond the fun stuff that we would prefer to focus on.

Posted by Scott Ambler on: May 16, 2012 04:49 AM | Permalink | Comments (0)
ADVERTISEMENTS

"Thus the metric system did not really catch on in the States, unless you count the increasing popularity of the nine-millimeter bullet."

- Dave Barry

ADVERTISEMENT

Sponsors

Vendor Events

See all Vendor Events