Lean Software Development – Book and Idea Review

Lean Software Development – an Agile Toolkit. What a great title for a book, combining two of the hottest buzz words of the last five years!

An enjoyable book, with a nice trike on the front page.

And this book delivers what it promises. It is a great book that aligns the Lean philosophy that was developed mainly at Toyota with the Agile/Scrum ideas. It demonstrates the remarkable overlap between these two paradigms and suggests how to translate the insights and experiences from lean product development into the software development domain. The book is easy reading with numerous to-the-point examples from real-world projects, both from hard-product development and software development. Mary and Tom are shooting sharp at some holy cows of project management like detailed up-front value engineering and early requirement freeze. It is entertaining and enlightening!

A couple of years ago I had the fortunate opportunity to visit Toyota in Japan and to spend some time with Toyota product development engineers to discuss how to use Lean outside the factory. Most of their suggestions come back in this book, ranging from iterative design and empowered teams based on reliable management to concurrent engineering. Furthermore, they agree on the point that it is hard work to get it right and to take on the responsibility. The committment is for quality, not for comfort.

One diffuculty that I see is that concepts like “Lean” and “Agile” describe the outcome/result of working in a smart way. In some situations it is used as a synonym for “Good”.  Anything that is good for the product development process or improves customer percieved quality with minimal effort is called “Lean/Agile”. I am worried about this, because it dilutes the methodologies and makes it hard to compare. In my opinion it would be  more helpful to differentiate more clearly and be open about when it is useful to use Lean/Agile concepts and when not.

 

The silence before “I can do that”

One of the hardest things to learn for me as a project manager is to restrain myself from delegating tasks too quickly. In my mind, I often have decided who in the project team would be the most suitable for a certain task that is being discussed. However, I have seen in the past few years that the best way of assigning tasks is to shut up.

Who will take this task?

There is a sea of insecurity in the silence between: “This is important, who could do this?” and “I can do that.”

When I started out as a project manager, I thought it was my job to assign tasks and that people would appreciate my effort to get the right task to the right guy.
Nowadays, working with professionals, the situation is quite different. The self-selected tasks seem to be easier, less ambiguous and more fun than the assigned ones.

Of course there are limits to the shut-up-strategy; one pitfall is that some young, eager guy/gal wants to show off by taking on too much.
Another is that nobody really wants to do an activity.
But whenever it happens, it is a signal that this activity maybe does not lead us in the right direction to our common goal…

Goran Christiansson

The Mythical Man-Month – book and idea review

Anniversary edition from 1995

This is one of the best books on project management I know. Frederick Brooks classic volume on software project management was first published in 1977, and updated/republished in 1995.
The book contains numerous anecdotes and essays on various insights stemming from Brook’s experiences from leading the IBM OS/360 development in the 1960’s.

The most famous statement is alluded to in the title, sometimes called Brooks Law: “adding programmers to a late project will make the project even more late”.
The main reason for this is increased time losses in communication/training for the added “resources”. Brooks goes on to show with clear examples how this works out.

In the summer of 2002 I crashed head on Brooks’ Law at the Saab Automobile factory in Trollhättan, Sweden.

Infotainment system for the SAAB 9-3, with MOST fibre-optic bus. Later than planned...

Instead of using the developer programmers to do the integration testing in the pre-production vehicles, new resources were assigned to this task, and I was asked to coordinate the efforts. It took weeks and weeks to get the new people up to speed. In the learning phase they consumed much of the time of the original developers’s time and they introduced new mistakes and miscommunications. Of course it is impossible to know for sure how it would have been if the original plan had been followed, but afterwards I felt very uncomfortable with the project decision to throw more people at the problem.

Another great insight that is eloquently explained is that it is virtually impossible to specify requirements correctly for a new system. Nobody is so smart that he/she can write down what is needed in a unique and non-contradictory way before the system exists in a prototype form.
Therefore, prototyping is a often necessary to get the requirements during the project.
This has re-surfaced as one of the cornerstones in the “Agile” programming methodology.
It is a strong insight and I see this in more domains, not only software. At the R&D lab where I now work, also mechanical designs and mechatronic solutions profit from iterative development instead of trying to get it all right at the first try.

In the coming weeks I will follow a Black Belt training for “Design for Six Sigma”, which claims to enable projects to get it right the first time. (see e.g. http://en.wikipedia.org/wiki/Design_for_Six_Sigma) I am curious and somewhat sceptical… Maybe there is a “Silver Bullet” after all?

I recommend this book to everybody working with project management, not only software.

Visual Project Control and Motivation

One of my favorite tools of “Lean” is visual control. The idea is that visual information on the wall next to the workplace communicates better than intranet pages or databases.

Projects Wall - Objectives, Status and What to do Next

For each project I run, I have a whiteboard of roughly 1 square meter per project, with the most important information, updated at least weekly. I include: project objectives, deliverables, team members, status, decision log and maybe most important: What are we working on now?

At least half of the project team is located in the same room, so they will invariably see what is going on in the project.

Typically, we have pulse meetings once or twice a week, to get alignment on what we are doing and who is doing what.

For me, this spices up my motivation.
Once in a while there are slow days, when the brain goes on half speed and the weather outside looks alluring. Then it is tempting to log on to [Your Favorite Social Network Site] and just click around. Or read another article about PyUnit, or a long email about a policy document change from HR.
But then I glance at the project wall and I see my name on a task, I am back in focus again.

I think that all tools that remind us about what we should be doing are useful.
And, by aligning weekly with the rest of the team, we can scrap some activities that we actually should not be doing, at least not now.

It is also more fun to finish tasks that have been self-assigned than diffusely delegated!