DAD Instructor Certification in London

Mark will be running a DAD Instructor Certification workshop for business partners and consultants in London May 15-17th.  You can find more information here…

Mark doing DAD talk at St. Louis IBM Rational User Group

Mark will be speaking about “Disciplined Agile Delivery:  Going Beyond Scrum” at a St. Louis IBM Rational User Group event on April 11th.  Details are here…

Disciplined Agile Experience workshop in Washington DC in March

Scott Ambler and Michael Vizdos are conducting our DA101: Disciplined Agile Experience workshop in Washington DC in March. Early bird and group discounts are available.  Attendees will be well on their way to Disciplined Agile White Belt certification after attending this workshop.

You can register here…

Mark interviewed on DAD

Mark was interviewed on DAD at the IBM Innovate conference:

http://www.youtube.com/watch?feature=player_embedded&v=lkDBs1Gf4TA

2012 in review

This has been a very active website in 2012.  Thank you all for your interest and participation.  We are looking forward to some great discussions again this year.

Mark & Scott

Here’s an excerpt:

4,329 films were submitted to the 2012 Cannes Film Festival. This blog had 36,000 views in 2012. If each view were a film, this blog would power 8 Film Festivals

Click here to see the complete report.

DAD process template for TFS

RDA is a Gold certified Microsoft Partner and four time winner of Microsoft partner of the year located in the Eastern US.  They have standardized their agile delivery model on DAD and have recently created a DAD process template for Team Foundation Server (TFS).  John O’Hara has written an excellent article about it here…

 

Comparing DAD to the Rational Unified Process (RUP) – Part 2

This post is a follow-up to Comparing DAD to the Rational Unified Process (RUP) – Part 1.  In that post I described in some detail why Disciplined Agile Delivery (DAD) is not “Agile RUP”.  DAD is quite different in both approach and content.  There are however some very good principles that the Unified Process (UP) incorporates that are not part of mainstream agile methods.  This post describes what parts of the UP made it into the DAD process decision framework.

DAD suggests a full-lifecyle approach similar to RUP.  DAD recognizes that despite some agile rhetoric projects do indeed go through specific phases.  RUP explicitly has four phases for Inception, Elaboration, Construction, and Transition.  For reasons that I described in the last post, DAD does not include an explicit Elaboration phase.  However the milestone for Elaboration is still in DAD which I will describe shortly.  As the DAD basic lifecycle diagram shows, DAD has three of the four RUP phases.

• The Inception phase.  An important aspect  of DAD is its explicit inclusion of an Inception phase where project initiation activities occur.  As Scott Ambler says in one of his posts “Although phase tends to be a swear word within the agile community, the reality is that the vast majority of teams do some up front work at the beginning of a project.  While some people will mistakenly refer to this effort as Sprint/Iteration 0 it is easy to observe that on average this effort takes longer than the general perception (the 2009 Agile Project Initiation survey  found the average agile team spends 3.9 weeks in Inception)”.  So in DAD’s Inception phase (usually one iteration) we do some very lightweight visioning activities to properly frame the project.  The milestone for this phase is to obtain “Stakeholder consensus” on how to proceed.  In the book we describe various strategies to get through the Inception phase as quickly as possible, what needs to be done, and how to get stakeholders consensus.
• The Construction phase.  This phase can be viewed as a set of iterations (Sprints in Scrum parlance) to build increments of the solution.  Within each iteration the team applies a hybrid of practices from Scrum, XP, Agile modeling, Agile data, and other methods to deliver the solution.  DAD recommends a risk-value approach of prioritizing work in the early iterations which draws from the RUP principle of mitigating risk as early as possible in the project by proving the architecture with a working solution.  We therefore balance delivering high-value work with delivering work related to mitigating these architectural risks.  Ideally we deliver stories/features in the early iteration that deliver functionality related to both high business value and risk mitigation (hence DAD’s “risk-value” lifecycle). It is worthwhile to have a checkpoint at the end of the early iterations to verify that indeed our technical risks have been addressed.  DAD has an explicit milestone for this called “Proven architecture”.  This is similar to the RUP Elaboration milestone without risking the confusion that the Elaboration phase often caused for RUP implementations.  All agile methods seek to deliver value into the hands of the stakeholders as quickly as possible.  In many if not most large enterprises it is difficult to actually deliver new increments of the solution at the end of each iteration.  DAD therefore recognizes this reality and assumes that in most cases there will be a number of iterations of Construction before the solution is actually deployed to the customer.  As we make clear in the book, although this is the classic DAD pattern, you should strive to be able to release your solution on a much more frequent basis in the spirit of  achieving the goal of “continuous delivery”.  The milestone for the end of Construction is that we have “Sufficient functionality” to deploy to the stakeholders.  This is the same milestone as the RUP’s Construction milestone.  During the Construction phase it may make sense to periodically review the progress of the project against the vision agreed to in Inception and potentially adjust course.  These optional milestones in DAD are referred to as “Project viability”.
• The Transition phase.  DAD recognizes that for sophisticated enterprise agile projects often deploying the solution to the stakeholders is not a trivial exercise.  To account for this reality DAD incorporates the RUP Transition phase which is usually one short iteration.  As DAD teams, as well as the enterprise overall streamline their deployment processes this phase should become shorter and ideally disappear over time as continuous deployment becomes possible.  RUP’s Transition milestone is achieved when the customer is satisfied and self-sufficient.  DAD changes this to “Delighted stakeholders”.  This is similar to lean’s delighted customers but we recognize that in an enterprise there are more stakeholders to delight than just customers, such as production support for instance.  One aspect of RUP’s Transition phase is that it is not clear on when during the phase deployments actually take place.  Clearly stakeholders aren’t delighted and satisfied the day the solution goes “live”.  There is usually a period of stabilization, tuning, training etc. before the stakeholders are completely happy.  So DAD has a mid-Transition milestone called “Production ready”.  Some people formalize this as a “go/no go” decision.

So in summary, DAD frames an agile project within the context of an end-to-end risk-value lifecycle with specific milestones to ensure that the project is progressing appropriately.  These checkpoints give specific opportunities to change course, adapt, and progress into the next phases of the project.  While the lifecycle is similar to that of RUP, as described in Part 1 of this post it is important to realize that the actual work performed within the iterations is quite different and far more agile than a typical RUP project.

At Scott Ambler + Associates we are getting a lot of inquiries from companies seeking help to move from RUP to the more agile yet disciplined approach that DAD provides.

Why “Disciplined” Agile Delivery?

Last week I was in Moscow to do a workshop on DAD.  Askhat Urazbaev, known for starting the first Agile User Group in Russia attended.  He asked some good questions, including “Why is it called the Disciplined Agile Delivery framework?  Are you suggesting that existing agile techniques are not disciplined?”  I have heard this question a lot.  As we describe in our book, clearly existing agile methods such as Scrum and XP require discipline to be effective, in fact more discipline than traditional approaches.  However, this discipline is focused on practices used within the team to improve quality and meet the commitments made to the customer.  For example, it certainly requires discipline to do test-driven development, continuous integration, to optimize team performance, and to recognize and deal with technical debt via refactoring.

In DAD, we support all these practices, but in addition we suggest that discipline needs to extend to other areas such as:

• giving adequate attention to forming an overall project vision before beginning Construction iterations
• framing the project within a lifecycle
• agreeing on appropriate lightweight milestones
• building enterprise awareness, not just team awareness
• adopting agile metrics and governance at the enterprise level

This week Scott and I are speaking at Agile East in Orlando and I just attended an excellent talk by Jim Highsmith regarding adaptive leadership on agile projects.  He referred to mainstream agile as “Agile 101″ and addressing some of these larger issues as “Mature Agile”.  This is very similar to the concept that we are trying to get across with the term Disciplined.  Mainstream agile methods address the discipline required to deliver value via Construction iterations (or without iterations with lean).  DAD extends that discipline to the full lifecycle and the enterprise.

We have written a number of posts on this blog in the “Discipline” category that you may find interesting which discuss some of these topics in more detail.