Aug 22, 2022
I was reading the other day about a government team that had compressed their Beta down in time to 12 weeks. It got me thinking about the factors that might enable you to compress or might require you to extend the duration of your Beta work.
In government, and elsewhere, in order to get funding for Beta you have to predict (*) how much money you’ll need, how you plan to tackle the work, what team you’ll need etc. for Beta. So, it’s important to get a sense of the factors that affect the duration of the work. Hopefully you’ve already done good quality Discovery and Alpha work to understand the problem and prototype possible solutions…
Some things to think about
- Do you have good quality Discovery and Alpha work to build your forecasts on?
- How complex or big is your product? How easy is it to slice scope into smaller chunks?
- Is there significant business process or organisational change going on around your delivery?
- Is it a greenfield delivery or is there legacy features to replace and legacy data to migrate?
- Do you have to integrate with other systems?
- Are those systems modern or legacy systems? Are the systems you have to integrate with also being built at the same time as your service?
- If you have to integrate, are there specific times when you could integrate (some legacy systems might have 6 monthly releases for example)
- Are you working as part of a broader cycle where some things only happen at specific times of the year?
- If you’re working as part of a programme of work, does the organisation structure enable delivery?
- Are you working in an organisation where agile, user-centred delivery is the norm and is well supported by Enabling Teams?
- Does governance empower delivery teams? Are decisions made at the right level?
- Is there strong sponsor backing for your work? This can help remove obstacles.
- Availability of people to research with, test with etc.
- How much continuity there is in team (including people immediately around delivery) composition from Alpha or Discovery?
- How experienced is the team in doing this kind of work? How experienced are they in the domain and in working in the organisation? Do you have all the people you need?
- Do you have the tools, space and other resources to get on with your jobs?
- Are their call-off contracts that you can draw down on or a central capability you can use or do you have to organise things yourselves e.g. a call-off contracts for user research participants, for external accessibility testing, for penetration testing etc.
I’m sure there are lots of other things that will affect the pace of your work, interested to hear others’ experience and thoughts as always…
(*) There’s a separate question of whether what you are being asked to predict can be predicted but I won’t get into that today. (And also whether you should even have projects for this type of work).