November 7, 2013 Articles In the last five years the ‘lean’ metaphor has been developed in a new arena – business start-ups. A major factor in the growth of this approach has been the thinking and publications of Eric Ries, a Silicon Valley entrepreneur. With this background the lean start-up approach has been used in many digital sector start-ups. An important concept in this approach is the Minimum Viable Product (MVP). This is defined as the version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort. Underneath the MVP concept is the fundamental idea of the value stream where value is seen in the eyes of the customer. Clearly no business start-up will succeed unless it is generating a value stream in these terms. But the initial vision of the start-up may well not embody a feasible value stream – rather it may be mostly guess-work. Within the MVP concept is a process of testing the validity of the value stream vision by repeated learning cycles. Again the connection with traditional lean thinking is clear – particularly the Deming Cycle, Plan, Do, Check, Act. This process of value stream development should be guided by real metrics. Another aspect of lean start-up is the approach to capital utilisation. In the classic dot.com boom startup, large sums would be made available by venture capitalists which would be ‘burnt off’ by the start-up team. There would be talk of the burn rate for example. Understandably the lean start-up model uses a different approach designed to reduce waste and based on the familiar lean idea of pull. Smaller tranches of capital are pulled by the start-up team from the VC on the basis of need. Ries taught the lean start-up model at Stanford – the prestige university close to Silicon Valley. He found that it was a real challenge to make the students actually experience how confusing and frustrating start-up environments are. In these circumstances, Ries suggests, one can only learn from being wrong. When something works, it’s too easy to invent a story about how that was your intention all along. Ries suggests that the key lessons are that: Regular checking in with and regular talking to customers surfaces bogus theories pretty fast Cross-functional teams tend to examine their assumptions harder and with more scepticism than purely single-function teams Working in small batches tends to make it less likely that you’ll attribute big results to small changes (because the fact that small changes sometimes do lead to big results is counter-intuitive) Rapid iteration makes it easy to test and re-test your assumptions to give you many opportunities to drive out superstition In 2010 Ries wrote a piece for the Harvard Business Review Blog entitled ‘The Five Whys for Start-ups’. He explains this by reference to his reading of the Toyota Production System whereby what appear to be technical problems are really human problems. The Five Whys technique is a way of drilling down to the underlying human problem whether the issue is improving a manufacturing process or validating a digital service start-up. The lean start-up approach is linked to another non-traditional arena where lean ideas have been utilised – Lean Software Development (LSD). The term was first coined as the title for a conference organised by the ESPRIT initiative of the European Union, in Stuttgart Germany, October 1992. Independently, the following year, Robert Charette suggested the concept of “Lean Software Development” as part of his work exploring better ways of managing risk in software projects. LSD is one of a family of development approaches which fall under the heading ‘agile software development’. These approaches use an iterative and incremental development process, where requirements and solutions evolve through collaboration between self-organising, cross-functional teams. In February 2001, 17 software developers met at the Snowbird, Utah to discuss lightweight development methods. They published the Manifesto for Agile Software Development. Since 2007, within the agile portfolio, the emergence of lean as a new force in the progress of the software development profession has been focussed on improving flow, managing risk, and improving decision making. This has included kanban as a major enabler for Lean initiatives in IT-related work. The focus on flow, rather than waste elimination, has proved a better catalyst for continuous improvement. Following a series of project failures the Civil Service is now adopting an agile software development approach led by the Government Digital Service (GDS). The GDS is a unit of the UK Government’s Cabinet Office tasked with transforming the provision of government digital services. It was formed in April 2011 to implement the ‘Digital by Default’ strategy proposed by the report ‘Directgov 2010 and beyond: revolution not evolution’. The GDS approach to agile involves teams working in short sprints, typically a week long, to see what they can achieve in that time. Once the team gets to a ‘minimum viable product’ – whether it’s an app, a digital service, or anything else – it is made available for testing by users and feedback is collected by the product design team. This feedback and analysis of users’ behaviour informs the next stages of development across further ‘sprints’. The product is refined by analysis of all this user data and released again, then refined and released again, in an iterative process. This approach is very similar to the classic lean start-up model. The decision to go agile was taken by the Coalition at the centre of Government and so the task of rolling this design approach across departments is a major undertaking and GDS admits that getting user research into agile teams in a way that is timely, relevant and actionable is a challenge. Rather than a team of researchers taking research briefs from lots of project teams, each project team has a dedicated researcher working closely with the team of designers, developers, content designers and product owners. This allows the team to be closer to the product design and adopt a more ‘experimental’ approach – hypothesising about what design or content approaches might work and designing ways to measure what is more or less successful. GDS believe that it is easy for teams to get comfortable with a small set of research methods and to use those for everything. In contrast, an experimental mind-set means always looking for better ways and a more varied research toolkit to help secure a richer and more accurate understanding of users needs. GDS uses a mix of qualitative and quantitative methods. Researchers work closely with their web analytics colleagues to achieve better understanding of how people respond to interface design and content using A/B testing and detailed path analysis. They have concluded that getting interesting insights from research isn’t hard. Getting those insights into the design of products can be surprisingly tricky. It looks as if more initiatives are likely in the UK civil service possibly extending as far as policy development. Some writers have suggested that lean and agile are alternative paradigms. In start-ups and in software development and digital services, a different pattern seems to apply. Lean start-up has been articulated as a coherent paradigm by Ries with clear links back to classic lean. Ries’ influence has extended readily to Silicon Valley. It is easy to underestimate the prestige which lean enjoys in the United States, especially with the Shingo Prize, the manufacturing Oscars. Taking the GDS agile approach as an example of UK practice – where the programme must tackle major issues in public sector IT – we can see that elements of the LSD paradigm have been incorporated and rolled out but not under a lean banner. The rollout challenge remains whatever flags are used to describe the required methodology especially as in the case of GDS where major change is expected on political time scales. At Industry Forum we have in depth experience of achieving changes on this scale and our approach has been founded on learning by doing. This approach is likely to be effective with these newer development methods. Further information: [email protected] +44 (0)121 717 6600 Download Article (pdf)
