Some quotes from The Lean Startup:
- Lean thinking defines value as providing benefit to the customer, anything else is waste.
- Most customer don’t know what they want in advance.
- Learning is the essential unit of progress for startups.
- Build, measure, learn.
- A solid process lays the foundation for a healthy culture – one where ideas are based on merit and not by job title.
When I worked at bigger companies, we got to take courses on how to be “Lean.” When I’ve worked at smaller companies, we simply did the “Lean” things as we had smart people who realized that that was the only way to survive.
Your first bullet, about anything which doesn’t define value to the customer is waste, simply isn’t true. You still need to appease the authorities, for example: the police with a warrant, the FCC with certifications, and any legal obligations around software licensing. The customer doesn’t care about any of these things but they can become quite a big expense depending on what your company does. Be sure to minimize these things so that you can focus more on just what the customer wants, but also budget for these things or else you’re likely to fail in the real world.
Thanks for the feedback – point taken – 1st bullet point is a bit exaggerated to make a point – all businesses and projects (including a consultant like me) have overhead and do things that don’t directly benefit the customer.
In discussing this book with another person, a comment was made:
the Lean Startup has excellent ideas, but I think they apply most directly to SaaS businesses with some sort of statistically significant user base for testing. The general principles of being lean, building as little as possible, minimizing waste, etc, are still valid, just harder to run quantitative experiments with. “learning” as a unit of progress is a tricky thing.
I’ve been puzzling over metrics, as I’m not very good at utilizing them. Even as a consultant, I’m lazing and don’t measure and track billable hours/week as I should be doing. Measuring things is hard and takes discipline. And in the end, many things cannot be measured and measuring the wrong things or misinterpreting results is worse that not measuring at all.
On one project we are using Kanban boards to track tasks and I suggested we start adding start/end dates to cards (Start when card moves to doing column, and end when card moves to done column). Initially this was deemed impractical by some developers as some tasks are unpredictable, some take more time than others, etc. However, as I thought about this, I decided that goal here was not to judge developers on their SLOC/hour, cards/week, etc, but rather encourage developers to estimate their work better (what you will get done in the next 1-2 weeks). If your cards routinely take you 2 months to finish, perhaps you should break things down a little more. Kanban cards should have good velocity for a board to work well. However, most of us get lazy, create over-general cards that encompass weeks worth of work. There is value in breaking down work into smaller chunks as it improves focus and better communicates with the team what we are doing. But alas, I’m talking about a metric that is not about direct customer value 
, however there is indirect value.
You can be lean and do hardware. The whole concept of Lean was popularized and effectively used by Toyota to build cars given their unique constraints of money, space, and workers. The cycles go a lot quicker with software, but it can be used for all kinds of businesses.
One way to be lean with physical things is to run the right kinds of experiments. The most valuable thing I recall from my big company lean training was all about “design of experiments” and how using specifically designed sets of experiments which allow for a tiny number of actual physical things needing to be built and tested but you could quantify the impact of many different factors all at once. You don’t have to understand the things you test from first principles, you can have the experiments derive the equations which actually affect your product for you. The name that sticks in my head about this is Taguchi (Taguchi methods - Wikipedia).
If this happens automatically, such that no one has to add the dates themselves, I think it would be a useful way to generate data. Just be careful how you use the data.
Your desire to simply help people to better understand how good they are at estimating is good, but that can be a delicate conversation.
If you have to do agile/lean in software development, I believe Kanban is the best way to manage that. If you can avoid formal agile/lean practices, that’s much better, but often this is not possible.
The best methodology I’ve seen for software development is called “Get shit done.” It works great as long as you have a team which is on board with it and all highly skilled. Everyone gets aligned by a leader on what the high level goal is, everyone gets to point out things that need to happen to hit that goal (and this evolves as the project progresses), and then everyone is free to work together to accomplish the things in the way they see fit. I imagine it’s super hard to manage this, but the speed at which things can be accomplished is the fastest of all methodologies I’ve seen. This is not a viable way to do consulting/contracting, the customer would have to be SUPER trusting and that’s unlikely to happen.