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.”
Excerpt
Here’s a excerpt of the simple, lightweight practices in Agile Software Development:
“User Stories
“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.
“Simple Design
“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.
“Test-Driven Development
“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.
Great to see these approaches getting more attention in the startup world. I’ve been soaking in both agile methods and startup companies a long time, and I think they go perfectly together. They provide just enough structure to make everybody effective, without unnecessary constraints or process bloat.
One of my clients, sidereel.com started with an XP-ish process from the first week. They had an alpha for investors in 2 months, a private beta in 3, and a public beta in 4 months. Now they’re happily funded, up to a dozen people, and just shy of Alexa 1000 site. Weekly iterations meant they always had new progress to show potential investors. And being able to change direction easily meant they could try a lot of things out and invest heavily in areas the users liked.
Speaking of which, I and a colleague are interested in trying out some variations of the Planning Game with a couple of user-focused startups. If any VH readers want to be guinea pigs, we’re looking for Bay Area teams that are early in the process, actively struggling to put together a product plan, and have both business and technical people involved full time. If there’s anybody here that meets those criteria, just drop me a line. My email address is my first name at my domain name.
Nice article. I will be checking the book out. Another book I have been reading recently which I can really recommend is Agile Principles, Patterns, and Practices in C# by Robert C. Martin
Thank you for the book recommendation.
Agile development should come with a warning: Once you’re exposed to it you might not be able to tolerate other practices.
This is what happened with me.
I became convinced that the agile approach is the way to go when it comes to web development when I applied parts of it to personal projects. So I couldn’t understand how the company I work in could see things differently.
They’ve already spent over 6 months on documentation and requirements gathering and they are clearly going on an insanely stupid path.
I’m planning on leaving them to start my own company simply because I can’t stand the stupidity people approach web development with. The worst thing I heard in one of the useless and frustrating meetings I attended was: “Who cares about the users, as long as we get approval from the project committee.”