Following the first instalment of my blog on Sprint 0 – I wanted to give some further thought to how certain Agile methods approach ‘up-front’ work, specifically within the context of Sprint-0.
Successful Project Initiation
Some of the less popular Agile methods such as Disciplined Agile Delivery (DAD) and the DSDM AgilePM approach attempt to lay down a framework of Agile project lifecycle phases – including an initial phase when this ‘up-front’ work should be done. They provide more detailed guidance on how to do it and what the deliverables should be. The DSDM AgilePM lifecycle framework for example is illustrated in the accompanying graphic.
Such approaches need to be tailored and adapted to each circumstance and have a greater risk of being interpreted and implemented in a traditional waterfall fashion by those who are new to Agile. Inception, Construction, Transition in DAD does not equal Analysis, Design, Build and Test but it is often interpreted and implemented in that way.
Moreover, the very existence of ‘phases’ with gateway reviews in-between them can lead to the outputs of the first of their first phases being regarded as ‘fixed’ and subject to a rather un-Agile degree of change control.
In addition the DSDM AgilePM approach in particular does not employ iterations during its Feasibility/Foundations phase/s where the project is initiated – iterations (or Timeboxes in DSDM Agile PM parlance) commence only in the Exploration/Engineering phases of development. This removes an element of transparency, focus, review, retrospection and embedded continuous improvement from the initial work.
Use Iterative Sprints for Initiation
In DAD the Inception phase is organised as one or more iterations, with planning at the start and reviews and retrospectives at the end of each.
At the end of each iteration an assessment is made as to whether the Inception milestone has been met. Do the scope, vision, high level requirements, architecture, plans, organisation and working practices have sufficient agreement to enable proper development to start, and for work to move into development proper? Sometimes this only takes one iteration (Sprint 0) – sometimes more.
Thus on larger projects I have found the best approach is to abandon the Sprint 0 concept for initiation in favour of simply running Sprint after Sprint with the goal of initiating the work properly but rapidly so that it can move into full development as quickly and as smoothly possible. Further analysis, design and planning then continue by refining the Product Backlog in parallel with development in a just-in-time manner.
In my next blog I will discuss techniques and practices for successful Initiation of Sprint 0.