Nivi · November 4th, 2008
“For heavens sake, if you haven’t gotten comfy with Agile techniques and thinking, get on it right now.”
Summary: Start learning how to be lean by reading Agile Software Development. It isn’t the cheapest book in the world but it’s one of the cheapest investments you will make in your startup. It includes 14 simple and counterintuitive practices that will help you engineer your engineering and product teams. This post includes several excerpts from the book.
In Lean startups find their moment, we defined lean as the never-ending process of eliminating waste. We described its benefits: eliminating waste makes your business fast, cheap, high quality, and effective—yes, all the good stuff, all at once. We defined waste as anything that is not absolutely necessary for creating customer value. And we described the two greatest wastes: overproduction and inventory.
We also said that lean probably seems abstract so far. Time to make it more concrete.
Agile Software Development
We first learned how to be lean from a book called Agile Software Development by Robert “Uncle Bob” Martin. Uncle Bob is one of the creators of agile and agile is just another word that software developers use instead of lean. This isn’t the cheapest book in the world but it’s one of the cheapest investments you will make in your startup.
Chris Sepulveda recommended this book when we hired Pivotal Labs to help us with software development. I remember having one of those aha! moments when I first read it, “Oh, so this is how you quickly translate a founder’s vision into happy customers (hint: it isn’t by specifying the requirements up front). This is how you deliver software on time (hint: it isn’t by working overtime). This is how you eliminate bugs (hint: it isn’t with QA). This is how you make developers effective (hint: it isn’t by putting them in a quiet room by themselves). This is how you know when you’ll be done (hint: it isn’t with a Gantt chart). This is how you engineer an engineering and product team.”
Here’s a excerpt of the simple, lightweight practices in Agile Software Development:
“In order to plan a project, we must know something about the requirements but we don’t need to know very much… we only need to know enough about a requirement to estimate it.
“The specifics of a requirement are likely to change with time, especially once the customer [the founder or product manager] begins to see the system come together. There is nothing that focuses requirements better than seeing the nascent system come to life. Therefore, capturing the specific details about a requirement long before it is implemented is likely to result in wasted effort…
“The Planning Game
“The essence of the planning game is the division of responsibility between business and development. The business people (a.k.a. the customers) decide how important a feature is, and the developers decide how much the feature will cost to implement.
“At the beginning of each iteration [an iteration is one week], the developers give the customers a budget, based on how much they were able to get done in the last iteration. The customers choose stories whose costs total up to, but do not exceed that budget.
“With these simple rules in place, and with short iterations and frequent releases… the customers will be able to determine how long their project will take and how much it will cost.
“An [agile] team will probably not start with infrastructure. They probably won’t select the database first. They probably won’t select the middleware first. The team’s first act will be to get the first batch of stories working in the simplest way possible. The team will only add the infrastructure when a story comes along that forces them to do so.
“You aren’t going to need it. An [agile] team seriously considers what will happen if they resist the temptation to add infrastructure before it is strictly needed. They start from the assumption that they aren’t going to need that infrastructure.
“All production code is written in order to make failing tests pass. First we write a test that fails because the functionality for which it is testing doesn’t exist. Then we write the code that makes that test pass.
“Once a test passes, it is added to the body of passing tests and is never allowed to fail again. This growing body of tests is run several times per day, every time the system is built. If a test fails, the build is declared a failure. Thus, once a requirement is implemented, it is never broken. The system migrates from one working state to another and is never allowed to be inoperative for longer than a few hours.”
And here’s a pdf of Chapter 1 that I got from Uncle Bob’s website.
By themselves, these practices actually have too many flaws to be effective. Agile Software Development includes the nine remaining practices that you need to make an agile process work.
Parts of this book are for anyone, and parts are for developers. If you’re a founder or a product manager, read everything up to and including Chapter 3. If you’re a developer (I’m not), I’m guessing you should read everything up to and including Chapter 7—or read the whole book.
So what does any of this have to do with eliminating waste? More on that later.