Book Review: Sustainable Energy without the Hot Air

Professor David MacKay, University of Cambridge, wrote a brilliant book last year about Sustainable Energy to get more numbers and less adjectives into the public discourse.
It is the best book I have read in a decade.

The contents are described in exquisite detail on the book’s website www.withouthotair.com. (Indeed, the whole book is available for free as a .pdf download!) However, it is worth mentioning the elegant buildup of the book: MacKay shows how much energy we use today, broken down into the ten major categories. This is compared with the possible power output of the possible sustainable energy sources like wind, solar, wave, tide, biomass,…

The buildup is very pedagogical and it is at once easy to understand the relative importance of various energy sources and sinks.

The book is written from a UK perspective, but the same calculations can be done for a country of your choice. MacKay has even setup a public wiki where people already started to do this for countries over the world.

I got inspired by the visualization techniques and the tools to get all numbers into a comparable format. It is not trivial how to compare a laptop computer with a bicycle commute, but MacKay has chosen a device that works all the way, see the columns to the right.
Since I read the book I have monitored our home energy consumption (gas and electricity) to better understand the energy impact of our family (kWh/day):

The book is written from a UK perspective, but the same calculations can be done for a country of your choice. MacKay has even setup a public wiki where people already started to do this for countries over the world.
Advertisements

Visual Control – Cash flow at home

I love graphing and plotting data. A visual comparison makes it much easier to understand the relative importance of different things. I wrote a small Python script (using matplotlib) to visualize home (ex)spenditure based on transactions on our bank account. By bundling all transactions by keywords, I could get Albert Heijn, Boni and Hoogvliet under one name “Supermarket”. This way, it is easy to see where the large chunks go and the relative importance of holidays vs home improvement vs car vs insurances over time. (a.k.a. Pareto analysis )

Expenses 2009 (click on image to see all of it)

This way, we can select smarter where to economize and in which domains of our family life we can afford some slack.  (For privacy reasons, I removed all numbers from these plots, but you can imagine or try out on your own transaction data!)

How to use the script: (leave a note here, and I can send you the .py file)

1. Download .csv of the transactions for the period of interest. At least from our on-line bank (Rabobank.nl – a cooperative and still well-run bank in Holland).

2. Adjust the script to categorize in your favourite way – and type in your exclusions. For us, transactions to and from our savings account do not constitute cash flow, so those were filtered out.

3. Generate graphs of your incomes and expenses!

Now you can use visual control for your own cash flow. If you want, you can even make run-charts!

Design for Six Sigma – right the first time?

Yet another book on DfSS

This week I follow the first half of a “Black Belt” training for Design for Six Sigma at the R&D Center where I work. A few days of statistics exercises and quite a lot of administrative tools to track requirements. In the coming months I will run some activities according to the DfSS methodology to evaluate for which problem this is the right tool. To prepare for the course I read amongst others the book (shown right), Design for Six Sigma – Innovation for Enhanced Competitiveness by Gregory Watson.

It is a very American book with a strong focus on measurability and quantifiability of value in all business/development processes. Watson claims to transform every requirement to a dollar value upfront, so that it can be taken into account in the design process in the most profitable way.

I wonder which projects he has been running in his days. So far, I have yet to encounter a technology development project where anyone can define the requirements unambiguously upfront. Let alone have a customer choose specifically the absolute or relative value of each feature. My experience is that the true value of a new technology is only visible after the product has hit the market and the customers are learning how to get value out of the new tools. Based on this information, the next generation of the product can be adjusted and improved. Fast feedback loops is often better than a very clever feedforward controller.

I think that the credo “right the first time” is an illusion. I believe in “better next time”.

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.

 

Today and Tomorrow – book and idea review

A book full of surprises. The core of the Lean Production philosophy is outlined in this 80 years old volume: Flow of material, reduction of buffers, continuous training of  personnel to move from doing to supervising and improving the process… All of it is described in this visionary work by Henry Ford. The reason I got this book to read was that it was referenced heavily by Taiichi Ohno in his book on the Toyota Production System.

today and tomorrow
Latest edition of the classic book.

The questions that pop to my head when reading this  is: Why was this forgotten? Why is it not more widespread? Why did I not experience this when working with Ford people at VoloCars? Why did it work for Ford in the 20’s but not in the 90’s?

My hypothesis is that it is hard to run companies this way. It puts very high requirements on managers to be able to give latitude and freedom to the workforce, to build trust and honesty. It is hard to pursue the ideals of lean, to sceptically look at yourself and admit that also you need to improve the way you work.

It is easy to point a finger at someone else and know better how they should improve their processes, but very, very hard to look at yourself. Especially in the office environment, we are surrounded with artefacts that identify our personality with the job, so any attack on the latter is felt as an attack on the ego.

Being a project manager, I understand fully why I sometimes order things late, but I have very little understanding or compassion with the purchasing department who is consistently slow in their processing of the order. I guess you recognize this from your organization’s favourite complaint department?

But the challenge I see is to be humble and open towards all the stakeholders and listen carefully to what they say. After all, the most effective starting  point to drive an improvement is the center of your circle of influence – yourself.

Even though I could/should start resoutely Today,  I conclude with allowing myself to think that Tomorrow is also good enough…

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.