Starting a new piece of software development work can be tricky. It often requires a non-trivial financial input to fund the work of all the required professionals such as analysts, developers, testers, and any other who might be needed. Typically, at the beginning, there is some business plan which, once approved, kicks off analysis effort. Eventually specification for a bunch of features for the new product is presented and development starts.
The business case makes several assumptions, many implicitly. There may be an idea, for example, about how the users will behave with the new system in place or that other products won’t undermine its position. Those are rarely verified later. The document also outlines potential benefits (thats the case element) which seem only to serve in the approval process. Once the money is granted nobody is there to follow up (see also Simon’s post: Business cases are in the eye of the business sponsor). This is perhaps one of the reasons anticipated improvements or savings are not expressed in a clear and measurable way as rarely they are the tracked or even used to keep development work on the right path.
The lean startup philosophy takes a different approach. Following this attitude we have recently started a new project at Energized Work with a day-long chartering exercise attended by the energised team and our customer. It included the entrepreneurs pitch, presentation of personas, the product charter focused on the following 8 weeks of development and clarification of high level user goals.
We used the A3 technique which has its origins at Toyota and is based on the PDCA (Plan-Do-Check-Act) cycle thus a great tool to provide input into development before it begins and feedback from subsequent releases. This approach proved very effective at focusing our thoughts and guiding us through the day.
- purpose – key reason for undertaking the work
- background – existing market and opportunities
- goals – we hope to achieve by completing the work
- constraints – limiting our options, budget being the key one
- assumptions – identifying explicitly what needs to be tested, in priority order
- users – a list of personas and what is of value to each of them
- success criteria – how would we know we have done well – including specific measurements and expectation
As the day progressed we went through each of the secions, focusing our exploration with regular pomodoros. By the end the board was full and we all had a much better idea of what we needed to build and why. We now had the essential context for the many decisions we no doubt will be taking with the customer as we discover more while building the product. With our assumptions explicit we were all encouraged to challenge them and ensure they still stand. All brought together created a reference guiding us to build the right thing with every story delivered.
It is important to note the scope of the exercise – not focused on building a nebulous “complete” product but on creating a validated beta within the first investment period that will, hopefully, meet our clearly stated expectations. At that time, equiped with our A3 charter and together with the customer, we will be able to reflect on progress and achivements and decide whether to proceed with the work with another tranche of funding.
The day was also a worthy investment for yet another reason. We have now had specific and measurable sucess criteria with exact values against them (listed in three columns under expectations as: measure, unit, expected value). Im sure Tom Gilb would approve.
Now the development could truly begin.
It was a refreshing and inspiring experience to be part of. It made me realise, how many projects I worked on before, were essentially crawling in the darkness. How often their positive outcome was not as carefully planned for as it might have appeared. How, inadvertently, we had to rely on gut instinct of a few key individuals and serendipity. What real opportunity were missed as teams were floundering. No, I wouldn’t want to go back there.