Chapter 1 – What are Agile, Lean, and Lean Startups and How Do They Foster Innovation?
If you are an agile software development practitioner or have worked in the industry around these practices, you are free to skip ahead. This chapter is meant as an introduction to all things agile, lean, and product/service innovation for those who are unfamiliar with the terms, values, practices, and philosophy. It is a tough chapter to write as there are literally hundreds of books that describe each of the items I touch on (and more) in much greater detail. Please do not take this chapter to be anything more than a brief overview of what I feel you need to understand to digest and implement the ideas in the rest of this book.
Agile is first and foremost a series of values in response to traditional software development practices (commonly referred to as “waterfall”). Waterfall focuses on a linear sequential planning cycle as shown in the image (looking for suggestions here if you have good images). There are many issues with this type of thinking in the highly competitive, uncertain, and rapidly changing world we’re trying to innovate in. The main issues relate to the rigidity of the plan, the time and money invested up front in making the entire plan before any execution, and the difficulty to integrate user feedback until late in the development cycle. This all leads to software products or services that are based on unfounded assumptions from a time when we knew the least about what our customers wanted or the way to execute against it.
Enter Agile and the Agile Values that were coined in 2001 via the Agile Manifesto (www.agilemanifesto.org). As the story goes, a group software development leaders (read: old white men) were skiing at Snowbird Resort in UT and came up with the following:
Manifesto for Agile Software Development
We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on
the right, we value the items on the left more.
Kent Beck
Mike Beedle
Arie van Bennekum
Alistair Cockburn
Ward Cunningham
Martin Fowler
James Grenning
Jim Highsmith
Andrew Hunt
Ron Jeffries
Jon Kern
Brian Marick
Robert C. Martin
Steve Mellor
Ken Schwaber
Jeff Sutherland
Dave Thomas
© 2001, the above authors
this declaration may be freely copied in any form,
but only in its entirety through this notice.
www.agilemanifesto.org
And thus began the revolution against many things traditionally valued in waterfall development including fixed plans, major efforts that have long lead times to providing business value, siloed communication between departments and roles and many other things. There is also a set of twelve accompanying agile principles that follow the manifesto that provide more context on how these values manifest in software development (also located on the above website).
While Agile is defined by the above manifesto, it is not a methodology of prescribed practices. Agile as a term has come to encompass methodologies, such as Scrum and Kanban, that abide by the manifesto values but add prescriptive practices to form a methodology and process. Lean values, originating from lean manufacturing and Toyota Production Systems, have also been adopted in software development and are complementary to the agile values.
The most widely used and recognized method for implementing agile values is Scrum. Often it is used synonymously with agile, which is incorrect as they are not the same. Scrum focuses on prescriptive, time boxed iterations in which value in the form of working, tested software is worked on incrementally. That is, instead of delivering an entire product, a slice of it will be delivered (read: developed and tested) and evaluated against the value it was planned to provide. This value delivery generally happens every two week cadence which is called an iteration or sprint. For more information on Scrum, please visit www.scrumguides.org.
Kanban is another popular methodology under the umbrella of agile values. Kanban places great emphasis on the visibility of work through the system by using a Kanban board. This board makes the work being done, the time it takes to cycle through the process from start to finish (cycle time), and the bottlenecks or places where work piles up and forms long queues, more visible. In making the process and workflow visible, practitioners can identify where improvements may be needed. Improvements identify potential levers to adjust to enhance the flow of value by decreasing the cycle time (process time) while increasing the throughput (finished work). Kanban boards also place a large emphasis on limiting work in process (WIP) to focus on fewer items and prevent context switching or multitasking. This helps us to stop starting and start finishing.
Lean, as mentioned previously, is adapted from lean manufacturing and the Toyota Production System. It focuses on similar flow-based visualization, like Kanban, but also considers the Theory of Constraints (The Goal, Eli Goldratt) in greater detail to exploit bottlenecks to further enhance the flow and throughput of work through the system.
Complementing WIP, Lean discusses small batch sizes to reduce waste and catch issues early (adapted from the Toyota “stop the line” mentality) by checking and receiving feedback. In keeping batches small, we can eliminate more unfinished and throwaway work because of the valuable feedback as each small batch passes through the various points or states of the system. A great example is making cookies – if you didn’t try a cookie (or hell, the dough – salmonella be damned) as you’re making them you wouldn’t find out until the end that there is an issue (e.g. baking too long/short, more/less flour) and the whole batch would be ruined. However, it’s in our nature to sample and test at a few different stages to see if adjustments need to be made to the recipe, cook time, or temperature. If we ruin one pan, we can adjust and make the next pan better. It works similarly with software development.
A final piece of software development that all the agile disciplines take into consideration is priority and value. We should always be asking ourselves the following questions: what is the next most important thing we should do? What is going to provide the most value to my customers and how can I evaluate that hypothesis quickly? How might this change affect the system in which it operates and can we anticipate (or rapidly find) unintended consequences and root causes (systems thinking)?
These questions lead nicely into the Lean Startup process, which again emphasizes trial, evaluation, and adjustment through its Build, Measure, Learn cycle. The Lean Startup, however, does this through a lens of rapid experimentation and building of a Minimum Viable Product (MVP). First, a hypothesis is stated that we are looking to evaluate. Then the minimum amount of work is put into building just enough so we can measure the effect against the hypothesis and learn if we should persevere with the idea or pivot and try something else before we have invested too much time or effort (therefore minimizing waste and maximizing learning quickly).
Now, what do agile software development methods have to do with Women in Agile, social movements, and nonprofits? The answer is twofold. First, we can learn from the models of making work visible, experimentation, minimizing waste, root cause analysis and systems thinking when crafting social movements and any type of business or service to adapt to what our customers or users wants and needs are. Second, our case study, Women in Agile, is a movement and nonprofit created by and for women and traditionally underrepresented groups whose careers are in agile software development. WiA was created by using the implementation of agile and lean methods.
Missed the intro? Get more info here and be sure to subscribe for updates!
