Every time a new initiative is starting, it’s intrinsically risky. This is even more true when the solution you need to develop, is a big one. An approach that is able, if well executed, to drastically reduce risks from the very beginning is the Agile Inception. Want to know more?!
Agile manages risk by design. In two of my previous posts, I wrote about how risks are managed, both at team and program levels, in an agile way:
Thanks to iterative and incremental development, rapid feedback cycles and closeness with the customer, Agile lowers risks since from the first iterations. The graph below clearly shows how risks decrease rapidly, compared to what waterfall does instead.
The primary reason which explains that effect is because the Agile team and the whole stakeholder community involved in that development endeavor, learn faster about the product and the context, testing earlier their assumptions, which in general decreases the overall uncertainty.
A terrific tool that helps to visualize the uncertainty (thus indirect exposure to risks/opportunities) which characterizes the envisioning and further (waterfall) development of a product or solution, is the cone of uncertainty. That diagram well describes the variation of the degree of uncertainty over time, when developing a new product; this is reflected by the error factor that teams do usually make, when estimating the effort necessary.
We notice from the picture above that most part of the uncertainty stays with the initial period, when the vision of the product, features necessary and how they could be built, are not that clear. This is even huge and risky, when the solution to develop is a big one, in a big enterprise, which involves several teams.
In such cases a good choice which helps to face that uncertainty, and inherently to lower risks, is represented by the DAD Inception. The main objective of this approach is to spend a few time, in the initial phase, to iteratively explore the main dimensions of the initiative (e.g vision, scope, architecture, quality, team, cost, time), in order to create a common high level picture among all the key stakeholders.
DAD summarizes the goals of this phase as follows: Develop Common Vision, Align with Enterprise Direction, Explore Scope, Identify Architecture Strategy, Form Team, Plan the Release, Develop Test Strategy, Secure Funding.
It is important to clarify that this is not and must not be confused with Big Design Up Front.
Indeed, it is worth noting that, in order to avoid any misunderstandings, the authors stress on purpose, words like “align“, “explore“, “identify” and “strategy” when describing the inception goals, which are intended to be high level activities and outcomes, detailed further on during the development, through the usual Agile iterative approach. In this article, the authors make that point crystal clear.
Additionally if you go through the tools and techniques suggested, they are all about lightweight ones based on collaborative working, sketching, agile modeling, etc.
Usually, those goals are achieved by running a series of workshops. A good practice is to use the first sprint (Sprint 0) to execute them.
An interesting picture (adapted from DAD disciplined agile consortium – risk-value lifecycle) that explains the impact of the Inception on risks and business value is the following.
There are some interesting things to notice
Due to the fact that the inception brings all the relevant stakeholders together, exploring the main product dimensions, misunderstandings or misalignment are managed immediately, allowing risks to decrease as well (P1).
Additionally, as soon as the vision is consolidated among the stakeholders, there’s another sudden drop (P2). Finally, thanks to the agile iterative approach, risk are manged proactively and thus it should not happen to have a growing trend, however this decreases till the end of the initiative.
It is interesting noting that business value starts to be created only when the inception is finished. Actually, nothing is delivered to the customer during that phase. Even if this could be seen as a sort of violation of the Agile principles, when facing a big project it could be acceptable to trade some time (money) initially, to drastically improve the probability of final success.
How can we wrap-up and represent the previous concepts all together?!
What are you saying?^ Your project is not that big and you have only one team involved?!
Well, the Agile Inception Deck from the Agile Samurai is what you need. Enjoy! :o)
