Category: lean
No matter who you are, where you live and what your job is you have to make decisions. Some decisions are easier, some more difficult (e.g. which way do you want to go on the crossroad with traffic lights from the picture?). But why making decisions is hard? When you make a decision, how do you know it is the right one? What information (if any) you have to posses to make the right decision?
This problem can be referred as "Defer Commitment" principle. Very briefly it tells you to make the decision in the last possible moment when you have enough information to be sure you are going in the right direction. It doesn't tell to you to procrastinate - NOT AT ALL! It's a wrong thinking. It only tells you that you have to wait and collect the data and as soon as you have enough information, make the decision.
In this post I will try to explain "Defer Commitment" principle from "Implementing Lean Software Development - from Concept to Cash" book.
Bookmark/Search this post with:
Some people would like to believe that building complex software
is like going to the grocery store: pick a candy bar off of the
shelf, ask what it costs and decide to buy it. You get no risk and
quick gratification. But building custom software is more like
building a race car. A special one-off product to meet exactly the
needs of its sponsor: win races.
As a customer, what are you really buying when you contract for
software development? You may think you are getting a solution. But
what you are really getting is an implementation team. And risk is
always part of the bargain. So what you really want is a team you can
trust to build your product and to minimize the risk of that choice.
In this article, I present a lightweight, lean approach to
selecting a software development partner which should dramatically
reduce the risk and cost to all parties.
Bookmark/Search this post with:
Lance Armstrong won seven consecutive Tour de France races between years 1999 and 2005. Every year there were 21 individual stages and Lance Armstrong won "only" 4 individual stages in 1999, 1 stage in 2000, 4 stages in 2001, 4 stages in 2002, 2 stages in 2003, 6 stages in 2004 and 2 stages in 2005.
As you can see Lance Armstrong was not focused on winning each stage (quite the opposite). He was focused on winning the whole Tour de France - yet he had to keep close to the head of the race. And when you take a look at time differences between him and the second cyclist in the final classification you will be amazed - they were close to couple of minutes (out of 90 hours of total time!) It means that he was focused on winning the whole race - not to be the best and outstanding cyclist (he was not - I know because I watched many of the stages these years).
Speaking with the lean language Lance Armstrong was Optimizing the Whole - and he succeeded seven times winning the most difficult and exhausting cycling race in the World.
In this post I will try to explain "Optimize the Whole" principle from "Implementing Lean Software Development - from Concept to Cash" book.
Bookmark/Search this post with:
Work in small batches
I've always thought that delivering small pieces of software is easier than delivering the BIG BANG product at once. Small software package is easier to manage than the big one, you can expect smaller amount of defects there, it is much easier to integrate it with existing software. Isn't that obvious?
On the other hand working on the new version for, let's say, six months without regular integration in the production environment (if integrated at all) will bring you much more problems. Defects will accumulate and just before the release someone will discover them. No surprisingly developers would have to work overtime to fix them.
Bookmark/Search this post with:
Software organizations have surprisingly more problems managing people than managing soulless machines. People are also surprised when they ask me what my job is all about and I tell them that I work with people most of the time. "But you are a software engineer - isn't your job about working with computers?". "You're partially right because I work in a team and program a computer using programming language to do what you want to do is much easier than >>program<< my colleagues to work with me to reach our team's goals" - I tell them.
Working in a team means not only solving technical problems, designing stuff and make decisions together. One of the most important factor that makes teams successful is Respect.
In this post I will try to explain "Respect People" principle from "Implementing Lean Software Development - from Concept to Cash" book.
Bookmark/Search this post with:
A Japanese company ( Toyota ) and an American company (Ford Motors) decided to have a canoe race on the Missouri River . Both teams practiced long and hard to reach their peak performance before the race. On the big day, the Japanese won by a mile.
Bookmark/Search this post with:
In a lot of large software projects there are some very critical requirements that require very critical choices be made early. For example, when building large web-application that has to sustain millions of requests per minute, a choice of the database, database schema and scalability options can play a critical role, yet it might be impossible to decide upfront which option suits your needs better. Typical agile-style decision would be to run a couple of architecture spikes to stress-test the potential solutions. Unfortunately sometimes such trials can take as much time as a half of the whole project.
Bookmark/Search this post with:
The goal of any project is to produce the best possible results at the minimal possible costs, while releasing early enough. Agile processes strive towards both maximizing the value produced and minimizing the amount of wasted effort.
Typical agile process ways of minimizing the wasted effort
- Do exactly what is most important to the customer now and nothing else. Requirements and the project requirement change. It is the fact proven million of times. Therefore too detailed requirements engineering and heavy upfront design are in the best case a big pack of wasted customer money. In the worst case they can result in a product perfectly conforming to the original specification, but useless at the moment of the release.
Bookmark/Search this post with:
RSS feed