In french, we say “Le cordonnier est toujours le plus mal chaussé” which I found an English equivalent in “the shoemaker’s son always goes barefoot”. I believe this is nowhere more true than in the software industry !
“Software is eating the world” they say. Software is now able to do things that only humans used to be. So why the hell are we driving our projects as if we were a horde of amateur hitch hikers ?
What does it mean to be data driven ?
Being data driven would allow us to answer questions such as :
- How much is the feature we delivered last week contributing to the bottom line ?
- How much is the feature we are currently developing expected to contribute to the bottom line ?
- What are the estimated cost and value of increasing our test coverage of 1% ?
- What are the estimated interests and nominal amounts of our current technical debt ?
- Which is the most valuable : improving our build system or building this new feature ?
Most projects I’ve worked in have absolutely no clue about the answers to these questions. The decision is left to experts, to the one with most influence, or simply to the developer, who can do how he thinks is best …
Hopefully, some people are thinking differently, they believe it is possible to quantify all this, they even explain how !
Details a very practical guide about the lean startup process, which is a very good starting point to any kind of lean software development.
This book explains with real world examples how to use Kanban board to control your work queues and improve your flow of work, a real basic for any lean product development.
The Principles of Product Development Flow: Second Generation Lean Product Development by Donald G. Reinertsen
This book is rather theoretical, but it links all subjects together : lean startup, risk management, Kanban, and economics. I guess it’s a must read on the subject.
If the flow book gives a big picture view of what you want, this one explains how you can actually measure all the aspects of your product development in $ value.
Although this book is getting old, and is a bit outdated when compared to agile development practices, it provides real world examples of how scientific measurement can be applied to software product development.
Reading these books was a real eye opener for me. The software development world is plagued with cargo cult and supposed best practices. We follow advises, but most often without verifying if they actually work ! I believe that by applying the techniques in these books, we could create standard ways to measure the values of productivity, technical debt, quality, testing …
I see real opportunities to avoid a lot of useless argument between proponents of A and B, but also to communicate better with all stakeholders and finally, to reduce stress for all of us.