Archive for Software engineering

Continuously mowing better at Toyota

Toyota turned into a lawn mower 

In a fine article on “The Toyota way”, Howard Artrip, a Toyota manager in the assembly area examplifies his habit of constant improvement:

“When I’m mowing the grass, I’m thinking about the best way to do it. I’m trying different turns to see if I can do it faster.”

This constant drive to do things better and smarter is what distinguishes the best workers at the best companies.

Constant improvement is what happens when being on level 5 of CMMI.  Reaching level 5 means you must pass levels 2, 3 and 4. For all of these levels CMMI sets specific goals, and that seems to differ from the Toyota way.

As John Shook (“a widely regarded consultant on how to use Toyota’s ideas at other companies”) states in the article, “… Managers keep trying to make their management objectives. They’re moving forward, they’re improving, and they’re looking for a plateau. As long as you’re looking for that plateau,it seems like a constant struggle. It’s difficult. If you’re looking for a plateau, you’re going to be frustrated. There is no ‘solution.'”

“Once you realize that it’s the process itself–that you’re not seeking a plateau–you can relax. Doing the task and doing the task better become one and the same thing,” Shook says. “This is what it means to come to work.”


Leave a Comment

Early overtime == later project completion

Crossing the desertJohanna Rothman wrote about avoiding the “Crossing the desert syndrome” some years ago.

“A project team focuses on an interim milestone, works like the devil to meet that milestone. They meet the milestone, look up, and realize they’re not at the end of the project–they still have to finish the darn thing. They’re living the Crossing the Desert syndrome”

Recently she gave advice on how to recover from the syndrome.

At Tyner Blain, Scott gives advice on how to prevent from hitting the syndrome: 

  • Improved estimation of tasks
  • Realistic effort allocation
  • Writing verifiable requirements
  • Managing smaller work chunks
  • Feedback into the estimation cycle
  • Better communication of release content

As I read his advice I thought: “yes I agree that’s good advice, but somehow good advice is seldomly followed”.

 BTW: Patrick van Lee, a relative from my wife,  rides the Dakar race on an Aprilia motorbike

Comments (1)

Outsourcing: from assembly line to extended team


Recently I became interested in outsourcing. Partly because we addressed the subject in reaching CMMI level 2, partly because I recently read the book “The World is Flat” in which “Thomas L. Friedman believes the world is flat in the sense that the competitive playing fields between industrial and emerging market countries are leveling. Friedman recounts many examples in which companies in India and China are becoming part of large global complex supply chains that extend across oceans …” (from Wikipedia).

In Managing outsourced teams. Balancing innovation with predictability. two different approaches to create a remote engineering organization:

  • Assembly line (requirements are sent overseas to be built there as specified; prerequisite is that the requirements are really good and stable)
  • Extended team (requirements are sent overseas and interpreted, a design or prototype will be created overseas and approved by the main office, emphasizing on collaboration).

Based on their experience the authors suggest that the best way to go about this problem is to start on the Assembly line “mode” and to transition to the “Extended team” mode as soon as you feel comfortable to do so.

hidden costsI think that’s a sound suggestion! Beware that on both approaches, there are lots of hidden costs when outsourcing.  

Leave a Comment

Visual Studio 2005: See the difference

Microsoft took some effort to promote Visual Studio 2005.

Take a look at the 400+ differences, like:

144 Better ASP.NET Source Code Editing – Edit faster, eat better

195 Bug list – Automated debugging. Keeps code tidy. (one of Erno‘s favourites)

212 Operator overloading – Goodbuy struggle, Hello joy

The even made a game about spotting the differences

Leave a Comment

how – not – to make a process work for you

Anti patternGary Pollice (“I’m the one with the head”) publised an interesting article on anti-patterns for process adoption in the Rational Edge.

At Getronics in the Netherlands we’re in the middle of adopting our process. We first documented our RUP-based “Getronics Development Process” using IBM Rational Method Composer. We documented some additions and our Getronics best practices and were appraised at CMMI level 2 last December. Now we’re rolling out the process and are facing two views on the way to go ahead.

One group wants to keep moving and go for CMMI level 3 right on. An other group wants to first take all our energy to get level 2 rolled out first, before moving on.

Reading the article from Gary, I would say we’re hitting the “Take all the medicine at once” anti-pattern if we try to move on to level 3 right away. In short, the antipattern says process changes take time, so it is better not to do everything all at once, but to do small process improvements at a time. For our situation, that would mean it is wise to roll out level 2 first!

BookMore anti-patterns can be found in Organizational Patterns of Agile Software Development. Gary Pollice did a review of the book, another review is at

Leave a Comment

Some additions to a complete list …

Miguel Carrasco published The Complete List of Software Development Frameworks, Process’s, Methods, or Philosophies.

As with all complete lists, being complete is hard.

Some commonly used alternatives are the Enterprise Unified Process and the Microsoft Solution Framework.

Leave a Comment

RUP related

To catch up with newer posts, here are some subjects that were on my to do list, all having to do with RUP:

Project Management with the IBM Rational Unified Process – Lessons from the Trenches by R. Dennis Gibbs.  Should be especially interesting if you are involved in managing an outsourced project with RUP.

Extending RUP with the Portfolio Management Discipline by Scott W. Ambler, John Nalbone, and Michael Vizdos (the guys from EUP).

Integrating the Rational Unified Process with Managing Successful Programmes, by Russel Norlund.

Leave a Comment

Older Posts »