Adopting a Full Lifecycle Requires Discipline

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.

Have any Question or Comment?

3 comments on “Adopting a Full Lifecycle Requires Discipline


Do you have any recommendations for learning more about the risks/advantages of:

Option 1: building dedicated but different inception and execution teams?


Option 2: is the normal preferred approach to have the inception team become the base of the execution team (then add new team members based on specific needs of the project)?

i.e. What are the pros/cons of putting a strong inception team together, and keeping that inception team together to move onto new inceptions, transitioning knowledge to a separate but dedicated execution team? (The folks from the inception team would still be available to chat with the execution team, i.e. they would be “insiders” but not part of delivery)

I’m asking this in the context of a services organization that would deliver the “inception phase” of a project to a client, with a hope of this moving into the “execution phase”. The idea being to set the execution team up for success.

My default slant is that I would prefer the small team involved in the inception phase continuing on as dedicated members for the execution phase (due to overall project team gelling, intact knowledge, customer relationships already built, expectations set,…). But I have limited input as to how teams get set up, and would like to have my eyes wide open to issues/benefits for both approaches based on what situation I find myself in.

I have just bought your DAD book today, so if there are particular areas you’d recommend I read first, or any other sites you can point me to, that would be great.


JP, sorry I took so long to reply but I’ve been exceptionally busy the past few weeks with the release of the book and other things. Anyway, I’ve come back up for air!

I really, really, really dislike option #1. With separate teams you have a hand-off which in turn leads to a loss of knowledge, greater risk and greater cost. One advantage of this approach is that you could potentially have people who are expert at initiating projects on staff who can do so in a consistent manner. A very big disadvantage, one that is seldom discussed, is that this team would have very little opportunity for real feedback about their work. They would have moved on to the next project, or even the next one, before stakeholders start providing concrete feedback about the initial requirements, viability of the architecture, and so on based on actually working with a running solution. I’ve argued in the past that the traditional data and business analyst communities have very clearly suffered from this problem for a long time.

Another problem with option #1 is that it typically leads to more documentation and bureaucracy, which in turn lead to greater risk and cost. Because you might not win the execution work you’ll probably be required to create sufficient artifacts to hand off to another team. This is a huge overhead. Then, if there is a hand off, the new team is likely to redo a lot of the work that you did just to get up to speed on the domain.

Option #2, where the inception team evolves into the execution team is much better. In the situation that you describe above a viable approach might be to include some of the client’s staff in the inception effort. Your staff would provide the expertise to get the job done and mentor their staff in project initiation skills as appropriate. Your people would eventually move on and the client staff take over. Or, in the case where the client doesn’t have the staff they would have your team start to ramp up once they become convinced of your ability to deliver. If they feel you are unable to deliver they should cancel the project and start over with another team.

The only situation I could see following option #1 would be with clients who are, ummmm…. , challenged when it comes to governing IT projects.

You’ve likely already done so, but the best part of the book to read would be the inception chapters. If you find the book useful, could you please consider posting a positive review on Amazon or whatever site you purchased it from? Thanks in advance.


Leave a Reply

Your email address will not be published. Required fields are marked *