Book Review: The Lean Startup

The Lean Startup by Eric Ries was a book I had heard about so many times that I had to read it myself. I had heard about Lean Startup methodology and read about it in many blog posts, but I hadn't read the book. In a way the topic was familiar even before starting, but still there were learning to gain from the book.

Ideology of Lean Startup is really valuable. I believe there's some truth behind what Eric Ries is talking about. The main idea of Lean Startup is that is valuable to measure the ideas in the market and be willing to learn from the results and pivot the course if needed.

I especially liked what Eric wrote about what actually is an MVP. In my own believes I often seen MVP to be much less than companies are themselves thinking it to be. Also validated learning, innovation accounting and the whole build-measure-learn loop were valuable parts of the book.

What I didn't like was that the book wasn't anywhere close to minimum viable book. It was utterly too long and once in a while even boring. I believe the ideas of the subject could have been delivered in 100 pages. That would have proven the value of the thinking. Now it was as any other ordinary book, lengthened to almost 300 pages in order to seem as a "normal" book. I just hate that approach. When there isn't that much to say, why to waste so many pages on it.

I feel bit bad to criticize the book since, I think that everyone should learn about the Lean Startup methodology. It is valuable and would help many companies and startups to succeed. I believe the book just isn't the best way to learn about the subject.


Written by +Henri Hämäläinen

Estimates or #noestimates

Everyone working is Software industry have been involved in estimates in a way or another. Most of the people have known for ages that the one thing that's sure for estimates is that those are wrong. More complex the software or organization creating the software, more difficult it has been to estimate how long creating software takes.

There's been buzzing around for some time the #noestimates movement. The basics of it, as I understand, is that software teams should get rid of making estimates, since those do more harm than good. But I think there goes so much discussion under #noestimates, that I'm not fully sure what all it contains.

I've seen estimates to do lot of harm in many organizations. Estimates have caused poor quality, unhappy people and lot of unnecessary waste on creating those and reacting to those. But then on the other hand, I couldn't see organizations to live without any estimates on software.

Value of estimating versus the time used to it

Value of the estimates versus the time used on creating the estimates is one of the key questions on estimating. Too often estimating takes lot of time. People use hours or easily even days to figure out how much time creating some software takes.

I guess it's not valuable to discuss too much about what's wrong with estimating. People are known to be terrible at estimating. One excellent source to understand more is Nobel prize winner Daniel Kahneman's Thinking, Fast and Slow which introduces at least WYSIATI, anchoring effect and lots of other reasons we can't estimate. So I'm not going to use more time on arguing about the subject, but use is as a given fact that people are bad at estimating.

So what is the reason estimates still exist. Why estimates are still done, even though those are always thought to be wrong. I believe estimating goes to the same category as planning. As Eisenhower said: "Plans are worthless, but planning is everything", there's something similar with estimates. Estimates as such are not accurate, but the journey is valuable and some figures are always needed.

Sometimes the time spent doing the estimates doesn't match the value that estimates can give. Estimates should be used as a tools for decision making. Most often the decision is that should something be tried to do or not. The decision should be about the start, not about the completion. That's what Agile and iterative thinking should help on, there should come multiple decision making points and clarifications about the completion when knowledge increases during the development.

Companies can't live without estimates

Liked it or not, companies can't live without estimates. Most of the companies have limited resources in developing software (and everything else too). Those few who currently seem to have unlimited resources, still need to serve their customers quite often to keep their positions.

In real life, there are customer commitments and internal commitments that need to be handled somehow. Most of these are based on estimates, things that are most probably not accurate. Still those don't change the fact that sometimes these commitments need to be given. Think about yourself, would you be willing to purchase a house building project, if your contractor would say that we don't really know how much it will cost, when it will be ready and what it will contain. Of course you want to get an estimate, or even a fixed price with fixed timeline and features.

Many companies actually are in estimating business. They estimate the costs of development, they estimate their sales, they estimate the timelines and then take known risk with price and profit margin. This is how most of businesses still work. The luxury of making fixed profit is with fixed hour rate businesses. So basically some of consultants, lawyers and couple of others. There the risk is in not getting clients and not in making bad estimates.

Other than actual businesses relying on estimates, many companies have internal dependencies to SW development estimates. Product marketing for example, can't wait for product to be finished before marketing activities can start. They might need easily few months head start to get all the activities ready when product would be ready to ship. There easily are tens of these dependencies inside companies to the software team estimates: sales , marketing, documentation, hardware creation, operations, training, partners and so many others.

Software estimates, as much as software teams hate those, and as much those are wrong are mandatory part of all businesses. Those of you who still hesitate, think about Lean value stream map. For customer, software is just a small part of product. Even a plain software product. I can't even invent a software that wouldn't need other activities to go parallel to software creation to shorten the full cycle.

What's the solution then

Estimates are problematic. Sometimes estimates cause waste, sometimes lack of estimates cause waste. When sales uses SW development estimates as promises, those can create business, but at the same time those might cause quality issues, stress and unhappy people. So what could be done to estimating, when to do estimates and how.

I can reveal already now, that I'm not a believer of black or white solutions, so I don't think there is a one solution for all. But here's couple of thoughts how situation with estimating could be improved.

Estimated targets and predictions

One possible solution is to go towards having targets from early estimates and then predictions separately. At least when estimates are not in the team level, but in the project or feature level, it would be beneficial to have a target and then constantly update the predictions based on progress. Both of these figures should be always visible and that would give to everyone else idea what is the real situation.

In this approach there are many potential problems also. People tend to keep the first estimated targets as the goals and then predictions as a follow-up of the situation. This might give the feeling of failure, when the first estimates will most often be wrong. Still this approach should give everyone the idea, that decisions are made with something that will most probably be wrong.

Software aided and fact based estimating

As discussed, people are terrible at estimating. In a way it's easy to say that computers can't be worse. Saying this, I've never seen a good software that could do this properly. There are quite many variables that needs to be taken in to account to have a proper estimate. Still I believe that it would be possible to create framework that would give rough estimates of projects or features.

This framework should benefit from the historical data that has been stored to many software tools that has been used in the organizations. As an input, the framework would need to get software components that require changes. Then based on throughput times in past and historical progress of projects estimating software could give an idea how long something will take. Even thought these estimates would be quite rough ones, still it would give valuable data for human made estimating. And I believe it still would be closer to the truth than many other estimates. As said, unfortunately I haven't seen system like this yet in place. I would be surprised if there wouldn't be any software projects ongoing in this field. I just haven't bumped in to those yet.

It's ready when it's ready

There are few companies who have been good on preventing the harm what bad estimates have on markets. Apple is the prime example of this. I'm hundred percent sure, that even the guys in apple are bad at estimating. They concentrate on the product quality, so they can't guess when they are ready. They have taken the approach on telling when things are ready when those are ready. In Apple case it works for their benefit, but many other companies need to be able to have some timelines beforehand.

Still the approach it's ready when it's ready has something to learn from. It starts with understanding, that estimating software project length is difficult. When this is realized, then companies should build their activities based on this. Sales shouldn't be selling exact dates too early, handovers and dependencies between different teams should be minimized and people shouldn't be rewarded or punished because the estimates they have given.

Software, even the minimum viable product, won't be ready before it's ready. There isn't any amount of estimating activities before hand which can tell for sure when the ready will be. Activities in companies need to be able to react to each others timelines and not work with fixed timelines.

Summary

Estimating is a key aspect of business in software business (and basically in any other business). There are too many aspects and ideas to improve estimating for a one blog post. Some people believe in time boxed development, others think Minimum Viable Product will help and some believe tools will be the thing that will fix the issues. I don't believe there is one solution to fix it. I see the key thing to be that people start to understand that estimating is really hard and people are bad at it. Most businesses need estimates and can't live without those.

As a feedback to many of Agile and Lean discussion ongoing in different forums, I have to say that too many people forget the business behind software. It's so easy to talk about no estimates thinking, Agile practices or Lean values without understanding the effects of it to the businesses. Software is a key part of many businesses, but it won't make money without the other activities in the companies.

Everyone involved in the estimating processes should acknowledge what is the decision estimates are used for. Minimum Viable Estimate could be a good guidance for everyone. What is the minimum level of estimate we need to know in order to make the decision in hand. And as reminder to everyone, estimates don't get better with estimating, those get better with implementing.


Written by +Henri Hämäläinen

Book Review: The Essential Deming: Leadership Principles from the Father of Quality

This time I got my hands on the book The Essential Deming: Leadership Principles from the Father of Quality. I have to admit that I wasn't really excited to read the book. Demings thoughts have been coming up from so many different directions, that I wanted to give him a shot. I'm glad I did, his thoughts were marvelous.

This book isn't really a book and neither it is written by Deming. This book is a collection of Demings writings, personal notes and speeches from throughout his career. It goes through all the main thought Deming was talking about in his books and his teachings. It tells those in a bit shorter format, but I think it was enough for me.

The book goes quite far back to 1950's and 1960's in telling what has been the problems with companies back then. Strangely the problems haven't really changed that much from those years. Of course many aspects have changed, but the underlying problems are the same. Also many of the solution proposals hopefully suit to current organizations as well.

I mark to books pages I will come back later for reference or future investigation. From the books I've read this might have had most markings done by me. There were quite a few good thoughts and sentences that will come handy in the future.

I have to admit that Demings thought were not totally strange to me. I've read those from multiple sources beforehand, but this was the first time I read his own words. That might have helped me a bit on understanding this book. It's not difficult book to read, but it needs some thinking to understand.

It was an excellent book and I enjoyed it. Even though it's old, thoughts are valid and valuable. This is a book which many if not all the the people who care about their organizations improvement should read.

Written by +Henri Hämäläinen

Separate Testing is Waste

Thinking very Lean, testing is waste. Testing takes time and doesn't bring any value to the customer. Most of the it only provides information, that product works as expected. Only time testing brings value to the customer is when errors are found.

Testing is seen as an important activity. There is lot of focus on improving testing and the coverage of testing. More and more people are working testing products and creating test cases. These activities, do improve the product quality a bit, but it isn't really a way forward.

Testing is a wide subject, and I'm talking especially on the cases were testing and product creation are seen as separate activities. There might even be separate test teams and separate product teams. Product teams do test to some extend, but the main responsibilities are given to test team. This is the big problem of testing. Separate testing should only be about knowing the risk level of releasing, not about increasing the product quality.

The aim should be to decrease the amount of testing and increasing the the product quality during the product creation. In the long run, the thing that matters is the product creation quality, not testing quality. Of course some of the product creation quality comes from testing, but this is not separate testing, but assuring the quality while creating something.

I don't believe any organization can get rid of testing. Some amount of testing is always necessary to know the risk level of releasing. Amount of testing needed should be analyzed thinking the costs and effects of fault in product release. In some businesses fault could mean bankrupt, in others, few annoyed customers. This analysis should tell the amount and scope of needed separate testing.

Testing and product creation should work together to ensure quality of the product. Organizations need to learn to build good quality products from the start. Every error should be analyzed and corrective actions should be made. Unfortunately this is utopia in most of the companies. Errors found in testing are seen as normal way to ensure quality. In the long run this will start hurting organizations and cause more and more errors.

The only way forward, is for management to start taking errors seriously. Especially having an eye on why the errors have been introduced in the first place, not why the errors were not caught in testing. Blame is often put to testing, even though it's an activity that shouldn't be done separately at all.

Written by +Henri Hämäläinen

Book Review: The Principles of Product Development Flow

I was told already about three years ago, that I should read some of Reinertsen books to understand much more about product development. Finally I read The Principles of Product Development Flow. I'm actually happy that I didn't read it earlier. It is a great book, but I have learned so much about product development during past years, that I was myself much more ready to understand the book, that I would have been earlier.

This book is not normal SW development book. I'm not sure if Agile or Scrum was even mentioned in this book. There is lot of talks about Kanban, but mainly because of queue's and because Kanban is great tool for better queue handling. This book dives in understanding where the value really is in Product Development.

One important part of this book is that it goes through why Lean is different for SW than it is for manufacturing. There are different economical factors affecting SW than normal factory. In both handling queues are important, but for example variation might even be valuable in SW, when in manufacturing it mainly waste.

I have to admit, that even with my economical background and interest in theories, still sometimes book got bit too technical to me. It really digs in deep to all subjects and make sure it has enough scientific or case study based evidence for the presented principles.

It is really important book for product development professionals. The ideas as such are valuable to everyone, but this book isn't the easiest to read. I recommend it to everyone who really want to understand how the whole product organization should work.

To be honest, I believe many of the readers of this book, will not understand how important this book is. If I will ever get to the level of understanding Reinertsen has for Product development economics, I'll be really happy. Be brave and take the challenge.

Written by +Henri Hämäläinen

Book Review - Scaling Lean & Agile Development

I haven't lately read that many books on Agile and software development, since I have felt that I learn more about software development reading about other subject than software development. Also some of the books have been quite boring, but I wanted give Craig Larmans and Bas Voddes book a change based on good reviews I had seen.

Too often books about Agile or Lean say mainly the same things that all other books are saying. Scaling Lean & Agile Development was a fresh exception. Although it did explain many of the basic things, but it did those with easy and compact form, so it wasn't disturbing.

Book goes thoroughly through many different aspects of Agile development in larger scale. It does concentrate on Scrum in it's name, but it does look the things from really from organizational perspective. It doesn't only look from certain layers, but it tries to cover many different aspect. It actually tells about the agile transformation and thinking tools also to get into scaled agile development.

It is easy and fun to read, but it does require background knowledge of agile development, scrum and lean to  get most benefits from it. So it isn't the first book to read about agile, but somehow I feel it never is the first book.

I enjoyed it a lot and highly recommend it to anyone who are in organization which have more than one development team doing software development.

Written by +Henri Hämäläinen

Book Review: Implementing Lean Software Development

For about half a year, there was laying on my table the book Implementing Lean Software Development by Mary and Tom Poppendieck. I was working mainly as a Product Manager for a year, so software development issues were not the number one thing on my mind. Now I have been for four months in a really
interesting project to improve software development of a company. I've been really excited about it and for that reason wanted to remind myself on excellent insights I knew Poppendieck's have.

I've read Poppendieck book's before and followed their teachings for some time already. This book had slipped my radar for some reason and I'm actually glad it had. It was really nice to go through thoughts from basics of Lean and Agile software development, without still wasting many pages on those. This book excellently reminds on the basics, but still give valuable information for the more experienced ones.

Book is full of excellent examples starting from the 70's and 80's, but coming back to the latest years. It explains all the things shortly, but understandably. It is excellent source for information and ideas for further information seeking.

What I've always liked about their thinking, is that they don't ever seem to get in to the hype's. They understand that hype's are hype's and Lean and Agile are something more sustainable. Getting better in software development is never about some specific ways of working. It is always about improvement and doing things better than previously.

I don't recommend it to be the first book about Lean or Agile software development. It gives something for everyone, but it is more valuable when one has got more experience to map the information against.

It was an excellent book and I enjoyed it enormously.

Written by +Henri Hämäläinen

Book review - Lean Software Development by Mary & Tom Poppendieck

This was one of the books I've planned to read from the days I started with Agile SW development projects. This was the book many said I should read about agile. I'm almost embarrassed that it took so long for me to start with this book. Now I've finally read it. Was it worth it? Definitely.

What I love about the book Lean Software Development by Mary and Tom Poppendieck is that even it's subtitle is Agile Toolkit, it isn't a such a toolkit that offers ready made solutions. I've never believed this one size fits all thinking which is sometimes pushed with Scrum and Kanban literature and this is refreshing exception to that thinking. This one offers explanations why things tend to go in some ways and what are the user or organizational problems these tools are trying to solve.

I'm actually pleased that I didn't read this when I was a fresh starter with Agile and Lean. I somehow feel the book would have been bit too much on that time. This book really encourages to see the whole and understand the underlying causalities between different parts of SW development. For that reason it was good that I had experience on many different levels and layers of Agile and Lean SW development to be able to reflect the lessons in the book to real life situations.

Book has lot of examples, most of them which really adds value to the book. Examples are often the best way to explain how the theory actually works in practice. That was exactly the way this book used examples. Some of the examples even felt really familiar to me and I noticed being in a similar situations which were described in these examples. That helped me to map these things better to real life.

I would recommend this book to all of you who want to understand the bigger picture with Agile and Lean SW development. This is the book that really sets the grounds to understand what this all actually is about. It gives more flesh around the bones for Agile and Lean. Those who need to see the whole before really understanding the details, this is the book for you.

Written by +Henri Hämäläinen

Book I read - The Toyota Way

Mainly because of interest to Agile SW development and Lean thinking, I read The Toyota Way -14 management principles from the world's greatest manufacturer from Jeffrey K. Liker. Like it says, it's a book about Toyota much praised manufacturing system.

Whole idea behind the book is to give an better view what makes Toyota manufacturing system such a good one. It introduces TPS (Toyota Production System), Kanban and lots of other systems they use.Still most importantly it tells about the importance of company culture, continuous learning and true understanding about the thinking behind TPS.

I've always been a big fan of thinking, "understand before you act" and that seems to be one of the key principles in Toyota also. Almost everywhere in this book it comes obvious that thorough understanding is the key to success. Hiding true problems behind quick win fixes is not profitable in the long run.

I really liked the book. It opens quite well the thinking behind TPS and the culture what they have there in Toyota. Of course it's just a tip of iceberg you understand based on one book, but at least I think it's the right ice berg to understand. Just trying to learn Kanban and Lean by how others are doing it, easily misses lot of very important aspects of the whole methodology.

I would recommend this book to all of you interested about Lean or TPS. Also those of you who see it beneficial to understand different kind companies, business models, manufacturing and company culture's.

The only small recommendation I would like to give to Dr Liker is, that maybe in the next edition there could be glossary, since there's so many terms flying around all the time, it's sometimes bit tricky to keep on track of all those.

Written by +Henri Hämäläinen