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

It Requires Discipline to Evolve Transition From a Phase to an Activity

Because Disciplined Agile Delivery (DAD) addresses the full delivery lifecycle it explicitly addresses the effort required to transition your solution into production, or in the case of product teams into the marketplace.  This transition effort may be referred to as release, deployment, or even the “end game”.  For teams relatively new to agile this transition effort is a phase, or if you don’t like the term phase then an iteration which very likely has a different time frame than construction iterations.  However, as we indicate in the DAD book, as teams gain more experience with agile and lean techniques the “transition phase” can be evolved into a “transition activity” with a little bit of discipline.  That is the focus of this blog posting.

The DA toolkit is goal-driven, not prescriptive, and as a result it describes the transition effort in terms of goals:

  1. Ensure that the solution is ready to deploy.  To achieve this goal you will need to address several issues, such as planning the transition effort, verifying that the solution meets the stakeholder needs for the current release, and validating that the solution is of sufficient quality.  As with other DAD goals, there are several ways each of these issues can be addressed, each with advantages and disadvantages.  There is no single strategy that’s right for all situations.
  2. Ensure that stakeholders are ready to receive the solution.  Similarly, there are several issues you need to consider when addressing this goal, including how you communicate that the release is coming, how to train and educate stakeholders in the new solution, and how to prepare the operations and support environment for the new release (one of the many aspects of a disciplined DevOps strategy built right into DAD).
  3. Deploy the solution.  Issues to consider when achieving this goal is identifying what should be released, how you can back out the release if you run into trouble, and how to determine that the release was successful.  The last issue, determining success, isn’t as obvious as you would think.  Does success mean that the solution is up and running in production?  Or does success mean that you have satisfied, or better yet, delighted stakeholders?

It is straightforward to empirically observe that the complexity of your transition effort can vary depending on the context of your situation.  For example, a simple standalone application such as a website can be easily deployed regularly because it effectively involves copying some files to a server (farm).  Organizations in this sort of situation may choose to deploy their software many times a day.  However, as we showed in the DAD book, for non-trivial enterprise deployments the transition effort can be significant.    In fact, the November 2010 Agile State of the Art survey found that the average agile team spent six weeks in their transition efforts, with some respondents indicating spending one day or less and some indicating twelve weeks or more.  There are several reasons why this happens:

  1. Transition isn’t agile yet. Many organizations are adopting agile techniques for construction but not for other aspects of the delivery lifecycle.  This is often referred to as “Water-Scrum-Fall”.  As a result these organizations are inflicting traditional, labor intensive transition practices on their agile teams.
  2. We’re dealing with more than just software.  It’s often a bit more difficult than simply copying some files onto a production server.  Mainstream agile methods describe the goal of creating “shippable software” at the end of every iteration.   That’s a wonderful, overly simplistic philosophy that doesn’t hit the mark in practice. In DAD we prefer to use the phrase “consumable solution” indicating that shippable does not necessarily mean usable software.  Furthermore, in many situations more needs to be delivered than just software – there may also be hardware upgrades, the business processes surrounding the use of the system may evolve, and even the organization structure of the people using the system may evolve.  In short, disciplined agilists adopt a solutions over software mindset.
  3. Transition occurs infrequently.  Some agile project teams adopt a long release cycle, often six months or more, and as a result don’t have sufficient opportunities or motivation to get good at deployment.  Sometimes this is due to the nature of the solution they’re working on but more often than not it’s because of the cost of transition – the greater the effort to transition into production the greater the cost to do so, therefore you need to spend more time building the solution to add sufficient value to justify the cost of transition.
  4. Lack of vision.  Many IT organizations don’t believe it’s possible that releasing solutions into production can be evolve from a multi-week phase to a multi-hour, or even multi-minute, activity.  Or they realize it’s possible for others to do so but not them (I find it amazing how many people believe they’re in a special situation or blame others, often senior management, for not being able to adopt fundamental strategies that would improve their approach).

Because of the potential complexities of releasing a solution in most mid-to-large sized organizations the deployment of solutions is carefully controlled.  This is particularly true when the solutions share architectures and have project interdependencies, one of the reasons why DAD promotes the need for enterprise awareness within agile teams.  For many 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.  To do so requires a great degree of discipline in areas such as:

  1. Quality practices.  First and foremost, testing and any related fixing should be done as much as possible during construction iterations.  Transition is not a “stabilization phase” nor is it a “test phase”, it’s a deployment effort.  Granted, you should still run your regression test suite(s) one last time as part of your overall deployment effort, with the potential that if tests fail you will need to do some fixing, but this should be a minimal effort.  The implication is that quality practices – including testing, refactoring, reviews, code analysis, and so on – be performed continually throughout construction.
  2. Pre-production integration and deployment testing.   These are two of the most challenging types of testing, and sadly they’re often given short-shrift in the agile literature.   The goal of pre-production integration testing, sometimes called production testing, is to test the solution in the best approximation of the production environment as possible.  This can be particularly challenging in larger organizations where hundreds of systems are already running in production and dozens are being worked on at any given time.  To make this testing economical during construction many organizations find that they need to go beyond the “whole team testing” approach with a parallel independent testing team that focuses on complex forms of testing that development teams can struggle with.  Similarly deployment testing can also be a challenge because its goal is to determine whether you can successfully deploy into production.
  3. Regular coordination between project teams and with operations and support staff. Throughout construction you will want to ensure that the development, operations, and support teams are all aligned.   One aspect of DAD’s enterprise awareness is to include DevOps strategies, such as treating operations and support staff as key stakeholders that you need to work closely with throughout the lifecycle, in the process itself.  The better the coordination the smoother, and therefore quicker, transition will go.
  4. Adoption of continuous deployment practices.  The fundamental idea behind continuous deployment is that the more often you choose to deploy the better at it you will get.  This happens because you have more opportunities to hone your deployment skills and also because you’re motivated to find ways to simplify or automate deployment activities.

I’ve seen teams evolve transition phases of several weeks down to several hours through adoption of the disciplined strategies mentioned above.   A disciplined agile team may start with relatively long Inception, Construction, and Transition phases and over time shrink all three down.   Over time the Inception phase mostly disappears, particularly if you maintain team consistency between releases, and as I’ve argued in this posting the Transition phase shrinks to a very small activity.  When deployment becomes inexpensive it enables you to have shorter construction phases and thus more regular releases – teams go from annual releases to bi-annual, then to quarterly releases, then monthly, weekly, and yes, sometimes even daily.  Your team will need to choose a release cadence that makes sense for you.

These days it is fairly easy to observe multi-billion dollar companies, particularly e-commerce companies but even staid organizations such as financial institutions, deploy on a monthly, weekly, and even daily basis.  If other organizations choose to work this way then why can’t you?

Posted by Scott Ambler on: September 21, 2012 12:15 PM | Permalink | Comments (0)

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.

Milestones

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)
ADVERTISEMENTS

A mind once stretched by a new idea never regains its original dimensions.

- Anonymous

ADVERTISEMENT

Sponsors

Vendor Events

See all Vendor Events