Is your project dead before it’s begun?

Yesterday I attended a monthly user group meeting held at the University of Calgary by the Calgary Agile Methods User Group (CAMUG) . The presentation was put on by Jonathan Rasmusson, a well known active participant in the Agile community since 2000 (he’s also our Agile Mentor consultant at MediaLogic). Jonathan introduces an aspect of agile projects that is often underestimate as to it’s effectiveness if applied properly before the project begins. This concept Jonathan calls “The Agile Inception Deck” which basically lists 10 exercises you should do before starting any software project:

  1. Remind ourselves why we are here? It’s good to set the stage. Ask the questions like why are we working on this project and why is this project is important to our stakeholders. The purpose will remind us of the goals and help us through the good times as well as the not-so good times.
  2. Produce an elevator pitch. This gives a quick and to the point statement that all project stakeholders (anyone who has an interest or a gain upon the successful completion of this project) can collectively share and own. Jonathan refers to Geoffrey Moore’s “Crossing the Chasm” which entails filling in the following sentences: For (target customer) who are dissatisfied with (the current market alternative) the product is a (new product category) that provides (key problem-solving capability). Unlike, (the product alternative),we have assembled (whole product feature that makes it a compelling choice for the target customer).
  3. Design a “cereal box” to sell your product. This exercise is about creating a shared understanding about the product and making sure that it highlights the Benefits of the product versus the Features it has. In this example a Feature of a family van would be 266 horsepower but the more important Benefit would be passing safely on the highway.
  4. Create a Not List. Identify all things that this product is not. This helps scope down the product and makes less risky. For example, the product will help you do your taxes in record time but it is not an accounting system or the product or project will allow online PayPal payment processing but it is not a full blown e-commerce shopping cart.
  5. Meet your neighbours. This exercise helps identify all groups that this project may be affecting, either directly or down the road. Identify and diagram organization contexts such as Business Operations, Business Information Systems, End-Users, Quality Assurance, etc. Introducing the project to many potential groups in the company increases areas for better collaboration as well reduces the likelihood that later on there’s a conflict with other company initiatives.
  6. Map the terrain. This is best done using a system diagram identifying such entities as legacy systems, logical scope, integration points, internal and external systems, technical vision, etc. This helps to distinguish the systems that are and are not part of this project. It also shows some restrictions and constraints that the project must work within.
  7. What keeps you up at night? Ask the big questions at up front because as the project progresses it will be harder to do so. Risks can be anything that may prevent the project from being completed successfully. The idea here is to record anything and everything that the team thinks could prevent the project from being successful. To me this means brainstorming all potential risks, then qualifying and quantifying likelihood and impact, ranking the risk in a matrix, coming up with counter measures for risks that require a mitigation strategy.
  8. Size it up. This step helps set everyone’s expectations for what the general scope of the project will be and the high level expected completion date. To me this means looking at the product backlog, gathering epic stories, estimating high level story points, utilizing past team velocity, story prioritization, and an initial product burn down estimate. This helps the development team and product owner understand the general scope of the project as well allows for project resource allocation.
  9. Clarify who’s calling the shots? Jonathan identifies one of the most important exercises of The Agile Inception Deck is to distinguish the management structure and clarify who has the last word from the customers side. Usually the smaller the number of people calling the shots the better. In Scrum this role is known as the Product Owner.
  10. Trade-off sliders. If you have a project where the scope, cost, and schedule are all high priorities and there is no give in any one aspect then that’s a sign of a project that is dead before it’s begun. This reminds me of a quote from Mary and Tom Poppendieck in their book titled “Lean Software Development An Agile Toolkit” “Agile methods tell us that the customer cannot specify all four of the software development variables (cost, schedule, scope, quality).If the timeline and cost variables are fixed, then the scope of the work must be variable or the definition of the scope must be at a high level so the robustness of each feature can be negotiated…”. Produce a trade-off slider for the project including the 3 sliders scope, cost, and schedule (quality is non-negotiable). Add a couple more sliders based on project goals and work with the client to ensure that an evenly distributed trade-off slider is produced.

So the next time you start having project smells, think about The Agile Inception Deck and how it could have saved you a lot of headache (I will!). And promise to never start a new project without one.

During the presentation Jonathan brought up a well known prayer “The Serenity Prayer” that I thought was brilliant and very agile, the prayer goes:

“God, grant me the serenity to accept the things I cannot change; the courage to change the things I can; and the wisdom to know the difference.”

4 thoughts on “Is your project dead before it’s begun?

Comments are closed.