Phase 2 - Developing a Minimum Viable Product
After a Discovery phase we develop a 'minimum viable product'. This needs to do just enough to be able to test our key hypotheses and/or to understand whether we can overcome key project risks, without doing so much that it's too expensive or takes too long to develop.
This phase is important because sometimes projects move the more complex parts to the end of a project - such as integration between systems or discovering whether users will adopt a new technology. Developing an MVP enables us to understand how to deliver a solution and whether it will work through real-life testing before we commit further resources to the solution.
In Hackney, we talk about building a Minimum Viable Product rather an Alpha phase to emphasise the importance of getting working code in users' hands quickly, and so we avoid making technical investments that we have to jettison before building a beta.
We can use this method even when we've decided to re-use or buy software rather than build it. Our 'MVP' might be a small number of internal users, or using the software for a small number of cases.
Team and skillsDuring this phase, it is particularly important to work with a team that can share the understanding of what users need and continue to support the project in the next phase of work. You would normally expect to be working in a team of 3 and potentially a team as large as 8. Much larger than this and the team may be too big to be cohesive. The team will contain:
GovernanceThe Product Owner will make the day-to-day decisions in response to the insights gathered from users. The key moments for decision-making will be in the activities to estimate the size of the user stories, the prioritisation and the sprint planning workshops. Beyond the sprint team, the Product Owner will need to explain these decisions to the project sponsor, head of service and possible the Cabinet Member - depending on the prominence of the work. Getting this input in the prototyping phase helps avoid later changes of direction in subsequent phases of work. We have developed a role description to help Heads of Service and Product Owners understand the commitment. During this phase, you should be sharing weeknotes and holding a show & tell at least every fortnight. We have created a guide to holding a great show & tell. At the end of the phase, the team will need to commission an assessment of the work against the Service Standard, consistent with previous phases. This should involve the infrastructure teams and applications management so that they are sighted on the scope of the project and prepared for any change requests when the project later delivers working solutions into the production environment.
ToolsThe key tools during an MVP phase will be:
TimingThis phase should take between 6 and 12 weeks, depending on the technical complexity of the service. A project involving simple web-based interfaces or off-the-shelf software should take nearer 6 whilst a 12 week phase enables the team to test the development of APIs. The phase could be designed to tackle the biggest risks to the project first, which can then inform the overall length of the phase.
OutcomesAt the end of the prototyping phase the team will have:
End of phase checklistWe have:
Team and skills
End of phase
Last updated on 25/06/2018