The leading Agile approaches such as Scrum and Kanban attempt to be as applicable as possible to a wide range of circumstances and situations within their domain. They do this, not by providing detailed, complex guidance that attempts to deal with every eventuality – and from which the practitioner must then select and tailor (in the manner of the RUP or PRINCE2 for example) but instead, by being very lightweight and generic in nature.
Thus, depending on exactly what definition you look at, Scrum consists of just 3 roles, 3 or 4 deliverables and 3-5 meetings, events or ‘ceremonies’ all underpinned by 5 values. The Scrum Team must determine how to work within the Scrum framework, seeking to continuously improve their approach through regular inspection and adaptation. Similarly Kanban lays down 6 principles and 6 core practices to achieve much the same end.
Successful Project Initiation
The simplicity of these approaches is their greatest strength. It is also however something of a weakness, in that the real world is never so simple. It is never straightforward to apply such simple models to complex environments – especially given that Scrum and Kanban themselves provide little or no guidance on how to do so.
Initiation of a project or any other significant piece of work is an important case in point. It is important that it is done well in order to get the team off to the best possible start, but Scrum and Kanban provide little or no guidance in this regard at all. Kanban simply states that you should ‘start with what you do now’, and Scrum assumes that the Product Backlog already exists or apparently somehow spontaneously comes into existence!
The one concept that is most commonly cited to deal with initiation work is Sprint 0. This is not a formal part of Scrum, but the term is often used to describe the period of work when initial requirements, architecture, plans and the development environment are established. Thus, it is generally argued, Sprint 0 may be the one iteration in which a team may perhaps not deliver any tested code.
I am not a great fan of the Sprint 0 concept. It implies that initiation will be a fixed duration, which is equal to one Sprint – typically either 2 weeks or one month. I have found that in some situations it need not take this long, and in others it may take longer. On large projects with a wide range of stakeholders it may take many weeks just to co-ordinate diary slots and organise a series of workshops. If the project is to select and implement a package solution then it can take many months to understand requirements, short-list, select and pilot potential solutions before the best can be identified and procured so that the ‘development’ work (in this case installation, configuration, integration and implementation) can properly begin.
Focus on the Principles of Lean and Agile
Rather than focus on the concept of Sprint 0 for initiation, it is better to focus on the underlying principles of Lean and Agile.
An amount of ‘up-front work’ is necessary in order to provide overall vision, scope, objectives, initial high level requirements, architecture, estimates, plans and agreement on roles, responsibilities, working practices etc. Insufficient consideration of these factors early on at the beginning will inevitably cause significant problems later. However, they will need to be changed and adapted as the work progresses and the initial theoretical discussions, analysis, design and planning workshops must not go into too much detail. If they do then we risk wasting time and effort with up-front work that proves to be incorrect. Moreover, the more detail that is defined up-front the more difficult it becomes to change. Expectations have been set; time, effort and emotion has been invested in the work and there are a lot of detailed deliverables that will take significant effort to amend and re-agree.
Even with Spikes and proof-of-concept work the validity of the ground-work done in initiation is only truly tested by proper, full development itself. Thus it is important that full development starts as soon as possible, with the minimum of up-front work – just enough to enable development of some of the most obvious, important or risky features to begin. This will make any shortcomings in the initial work more transparent more quickly, making it easier for them to be addressed. Meanwhile, further analysis, design, planning etc. continues in parallel with early development and beyond.
In my next blog (Sprint 0 – Part 2) I will be discussing this topic further, and exploring how some Agile methods approach ‘up-front’ work. Read Sprint 0 – Part 2 here.