Home > Discipline, Goal-Driven, Inception phase > It Requires Discipline to Keep Inception Short

It Requires Discipline to Keep Inception Short


The Disciplined Agile Delivery (DAD) process framework includes an explicit Inception phase – sometimes called a project initiation phase, startup phase, or iteration/sprint zero – which is conducted before actually starting to build a solution.  The goals of this phase include: clarifying the business problem that needs to be solved; identifying a viable technical solution; planning your approach; setting up your work environment and team; and gaining stakeholder concurrence that it makes sense to proceed with investing in the implementation of the chosen strategy.  These goals are listed in the following diagram.

Inception Goals

In the Disciplined Agile Delivery book we devoted a lot space to describing how to effectively initiate a DAD project.  Unfortunately in our experience we have seen many organizations that are still new to agile 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 temporary documentation up front on an agile project 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 this phase and strive to reach the stakeholder consensus milestone as quickly as possible.

According to the 2013 Agile Project Initiation survey the average agile team invests about 4 weeks performing project initiation activities, including initial requirements envisioning, initial architecture envisioning, forming the team, initial release planning, and so on.  Of course this is just an average, some respondents reported investing less than a week to do so and some reporting investing more than two months – the amount of time required varies depending on the complexity of the effort, your stakeholders’ understanding of their requirements, your team’s understanding of the solution architecture, whether this is a new solution or merely a new release of an existing solution, and many others.

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.  You can do this in several ways:

  1. Recognize that the goal is to get going in the right direction.  For any project or product of reasonable complexity you want to spend a bit of time up front ensuring that you understand the problem and have what you believe to be a viable strategy to addressing that problem.  This doesn’t imply that you need a comprehensive requirements specification, a detailed project plan, nor a comprehensive architecture model but it does mean you need to do a bit of initial thinking and organizing.  In a small handful of cases, typically at scale, you may find that your team does require detailed models and plans but this is a very uncommon exception (regardless of what traditional THEORY may claim).
  2. Educate people that details can safely come later.  If you have the ability to plan or model something in detail today, won’t you also have that same ability a few months from now when you actually need those details?  Of course you do.   In lean software development they recommend deferring decisions – including planning decisions,  detailed design decisions, and even requirements – until the most appropriate moment.  The observation is that by waiting you can make a better decision because you have better information at hand.  This strategy of course assumes that you’re able to overcome basic logistical problems such as having the appropriate people available at the time to help explore an issue, provide requisite information, and make the decision.   It’s far less risky, and far less expensive, in most cases to address basic logistical issues than it is to apply the process band-aid of writing detailed documentation at the beginning of a project.
  3. Promote a sense of urgency.  This is the most important thing that you can do.  Just as there is risk associated with not sufficiently thinking about your strategy for approaching a new project or product there are also risks associated with doing too much up front work.  My experience is that far too many IT professionals are complacent regarding the risks associated with the project initiation activities of the Inception phase.   The longer you put off building a consumable solution the greater the risk that you’re building the wrong thing.
  4. Keep your modeling efforts as light as possible.  You very likely need to do some initial requirements envisioning and architecture envisioning early in the project lifecycle to help you think through what you’re doing.  But in most cases this modeling should be high level and light, not detailed and heavy.  In every project I’ve ever been involved with the team has been asked to identify what they’re going to deliver (at least giving a rough sense of the scope) and how they’re going to do it (at least providing a rough idea of the technical strategy) to secure funding for construction.  In short, they need to do a bit of up front thinking.  You will often find that you need to reign-in some of your staff who are experienced with traditional approaches to modeling and specification.  These people have a lot of value to add to your project, modeling is an important skill needed on disciplined agile teams, but they may need help keeping their approach light-weight and incremental.   The details can come later.  See the process goals Identify Initial Scope and Identify Initial Technical Strategy for more thoughts on this subject.
  5. Keep your planning efforts as light as possible.  Similarly you need to invest some time in high-level release planning to answer basic questions such as how long do you believe (roughly) it will take to get a release of your solution deployed and how much (roughly) this will cost.  Planning details can come throughout the Construction phase when it’s more appropriate to invest in such decisions.

I think that it’s very clear that the secret to keeping Inception short is to have the discipline to know that you need to invest some time thinking your approach through but that you want to avoid getting bogged down in too many details.  You need the discipline to do some planning but not too much.  You need the discipline to do some modeling but not too much.  You need the discipline to get going in the right direction knowing that the details will come out in time.

About these ads
  1. September 7, 2012 at 3:34 pm

    Scott,

    In the defense and space business this is called “Capabilities Based Planning.” (CBP) This approach “discovers” or elicits what capabilities are needed to fulfill the mission, stated in measures of effectiveness (MoE). This usually results in a Concept of Operations (ConOps) describing the mission and its actions in Scenarios – (1) Fly to Hubble with a robotic service vehicle, dock, and don’t break anything, (2) Change the Wide Field Camera, (3) Connect the umbilical battery to bypass the built in batteries, (4) unlock and land in the pacific and don’t kill any whales – how much does that cost, and when can it be ready to launch? This is an actual conversation at the Broad Area Announcement, NASA, Houston, 2003.

    The CBP method was developed by the Australians, adopted by the Canadian Forces, and finally came to the US DoD. It is directly applicable to Enterprise IT especially with ERP systems, since it is easy to get stuck in the quagmire of “needs and requirements” even in an agile world.

    CBP allows the program to ask “why do you need this?” “What capability does this thing you want to build support and what measures of effectiveness will be improved or what risk will be reduced, once you get it to work?”

    As well, with the Capabilities in hand, in a model of their interactions, trade offs, and impacts directly on the business (or mission) value, there is now a home for all requirements. This prevents scope creep – even in the agile world – since a requirement must support a capabilities.

    The foundation for CBP is highly developed in the defense acquisition domain, and is staring to be used in enterprise IT. A good reference paper is “Competing on Capabilities: The New Rules of Corporate Strategy,” George Stalk Jr., Philip Evans, Lawrence E. Shulman, Harvard Business Review, March 1992

    The steps in CBP are:
    (1) Define Capabilities as Operational Concepts
    (2) Define Capabilities with Scenarios or Use Cases
    (3) Assess Needs, Costs, and Risks of the Capability Simultaneously
    (4) Define Explicit, Balanced, & Feasible Alternatives

  2. September 11, 2012 at 7:09 am

    Great post about a common mistake … it is very difficult to people to understand that inception is something you must have (otherwise: who created a thing called backlog ?) but you should do it as fast as possible … they don’t do it or they do it in the wrong classic way …
    We had the same problem applying RUP: the inception had a goal (understand the problem) but RUP didn’t tell you to write a lot of docs, just to achieve the goal ! It could take from 15 minutes to 3 months …

  3. October 2, 2012 at 2:14 pm

    Great post, Scott – as I mentioned during our brief meet-up I think the motivation behind an Iteration-Zero/Inception “priming” stage is a solid idea and I’ve found it useful in the projects I’ve engaged, especially those that just can’t get started.

    In his book, The Scrum Field Guide, Mitch Lacey pitches a similar idea for a “Ranges and Changes” approach to contracting, using a two-week “priming” engagement for a small segment of the anticipated team (and that’s vital) to meet with stakeholders and begin sussing out the details of the proposed solution and building an initial Product Backlog that can be used to forecast a feasibility release plan.

    ‘Appreciate that you take the time to clarify the intent and how this isn’t BDUF in disguise or an apologia for agile frameworks.

  4. March 12, 2013 at 1:54 am

    Hi,
    Through this write up you sum up a couple
    of the most main views.
    Easy to read through and inclusive of interesting insights.

    Thanks a lot for posting It Requires Discipline to Keep Inception Short | Disciplined Agile Delivery!

  5. Nancy
    April 18, 2013 at 7:00 am

    Our group is reviewing the case study in chapter 12 of the DAD book. We have some questions regarding the section on Concluding Inception Phase – This section felt a little light to us around guidance on approval to move forward based on estimates and approval of the business benefits. Do you have any guidance on precision?

    We were hoping for some insight on the following. Justification of the business case, Ie; realizing the business benefits, ROI, business value, payback. Today in our organization we need to justify the spend with an approved business case and we base our release plan on delivering features based on benefit and risk. I was wondering if you had an example on this approach. Also we would need to ensure that any specialized resources are sourced and available for us to proceed. Our current governance process to proceed is not as simple as an agreement from a stakeholder which was described in the case study.

    It is a challenge but it really takes us time to move from one phase to the next by ensuring we have the right amount of information to proceed to satisfy our governance model.

    Any thoughts?

  6. April 19, 2013 at 8:06 am

    Nancy, you’ve identified some common issues that many organizations still face. Here are some thoughts for you:
    1. Early in a project the information that you have isn’t very accurate. Stakeholders will struggle to tell you what they want, this is human nature, and even if they were good at telling you what they want they would change their minds anyway. In addition you may not have a completely clear idea as to how you’re going to approach building/configuring the solution nor will you even have a clear idea as to who will be on your team and how available they are. All of this information is important input into your schedule and estimates. So, because the input is “fuzzy” so is your output. The implication is that at the beginning of a project your time and cost estimates should be given in ranges. These ranges will reflect the uncertainty, or the fuzziness, of the information you have at hand. In the book we cover these sorts of ideas in Chapter 10 and even promote a ranged burndown chart approach for updating the estimates based on improving information.
    2. One of the strengths of the DAD framework is that it makes your process-related options explicit. As a result there is in effect an infinite number of ways that you can tailor DAD to reflect the context of the situation that you face. So, the case study reflects only one of many ways to take a DAD-based approach.
    3. Calculation of ROI, NPV, the business case, and other issues will also be based on this fuzzy/uncertain information. I find that many organizations want you to invest time in creating these sorts of things, which clearly has a cost associated with doing so, yet rarely do they track after the fact whether you acheived what you originally promised. This is a sign that something is wrong in your governance strategy. I suspect it’s because management inherently knows that the initial ROI… calculations are little better than works of fiction yet are unwilling to realize that there’s little value in spending much time on them.
    4. In DAD we clearly promote the idea that you should identify and then mitigate risks, that you should invest a bit of effort in common to a common vision for your effort, that you should invest some time in identifying the initial scope, and other project initiation activities. We also promote the idea that you should invest as little effort as possible in doing so because you will increase project risk by doing too much up front planning.
    5. It sounds as if your organization is still suffering a bit from a more traditional mindset. This is a common problem. You need to help your management team understand that what they are requesting increases the cost, schedule, and risk to your project. In Chapters 7-10 we explicitly discuss the advantages (few) and disadvantages (many) of heavy/detailed approaches to requirements, architecture, and planning required to fulfill such requests. In Chapter 20 we describe strategies for governing agile project teams effectively. From the sounds of it your organization is still applying traditional governance strategies, or at least traditional-leaning strategies, and as a result are likely causing harm to the teams that they hope to be helping.
    6. To explore the inherent waste in your existing governance process, consider creating value stream maps to explore what is actually occuring.
    7. Feel free to contact us via http://ScottAmbler.com if you’d like some help adopting a disciplined agile approach.

  1. October 1, 2012 at 9:31 am
  2. October 23, 2012 at 7:50 am
  3. December 20, 2012 at 1:54 pm
  4. January 21, 2013 at 3:51 pm
  5. February 22, 2013 at 3:05 pm
  6. June 26, 2013 at 8:43 am
  7. October 16, 2013 at 4:47 am
  8. November 28, 2013 at 4:00 am
  9. June 27, 2014 at 12:28 pm

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

Join 600 other followers