The February 2009 edition of Harvard Business Review has an interesting article written by Thomas H. Davenport: How to Design Smart Business Experiments.

The objective of designing a simple test process for ideas is to avoid the two common pitfalls of acting on a hunch or overanalyzing, the middle ground being to quickly (and cheaply) reach a go / no-go decision based on significant evidence. Note that this simple test process is better suited for tactical decisions than for big, strategic decisions.

The author highlights the following steps:

1. Create hypothesis: Examples of hypothesis would be "does project planning software improve our ability to meet deadlines for our projects?", or "does advertising in local industry publications improve sales of our web solutions for SME?" The hypothesis also contains an estimation of economic metrics, such as increased profits or savings that implementing the idea will achieve.
2. Design test: Designing the test implies defining how to collect statistical evidence to test the hypothesis, such as how to execute the test, how to control execution, over which period of time, and what are the key metrics.
3. Execute test: The test is carried on according to the design.
4. Analyze test results: Test results are analyzed according to test design. One of the main outcomes of analyzing the results is to determine whether further testing is needed or not.

In my opinion, steps 1 to 4 should be performed iteratively. Few ideas can be tested in one pass. Therefore, analyzing test results can be used to refine the initial hypothesis. Of course, additional iterations are unnecessary for tests that resulted in a clear go / no-go outcome.

Finally, if the idea is deemed worthy, we have to plan and execute the rollout.

Lean is agile, but agile is not always lean. This might seem a simple question of terminology, but it raises interesting considerations.

I have always been mildly annoyed at how empty the word "agile" is. As I and many others concluded, agile is but a short list of relatively abstract principles. What we need is practices. Principles are underlying truths that don't change over time and space whereas practices are the application of principles to a particular situation. There is a huge gap from principles to practices, and this gap can only be bridged though real-world applications.

Lean software development is more tangible than agile because it leverages a richer collective experience. Lean software development has been designed by doing. Lean principles were discovered progressively when practices repeatedly proved successful. Since lean originates in manufacturing, it leverages a much more extensive history than the 8-or-so years agile has been around. Although I would be wary of any practice that is transferred from one industry to another, in this particular case the transfer is pretty straightforward. If you're not convinced, take a look at Mary Poppendieck's Principles of Lean Thinking.

Note that we should not consider agile and lean as competitors. Quite on the contrary. Lean being a specialization of agile, the success of lean further demonstrates that, yes, agile principles make sense. Whereas agile practices sometimes lack a successful track record, lean brings 30 years of successful history.

Although I have significant experience with agile, I'm a newbie to lean. Reading and discussing about lean practices helped me see some agile principles in a new light. Let's go over what lean brings to agile software development:

1. Waste
2. Discipline
3. Test-driven development (TDD)
4. Speed = quality
5. Success measurements
6. Team size and location

I used multiple sources to write this article. The main one is the book "Implementing Lean Software Development - From Concept to Cash", by Mary and Tom Poppendieck. I recommend reading this book if you're interested in lean software development.

Next page: Waste

Pages: 1 · 2 · 3 · 4 · 5 · 6 · 7

If you have only one hour to learn about Scrum, you will enjoy this Google TechTalks presentation of Scrum by Ken Schwaber.