January | 2007 | How I jump to my conclusions

Archive for January, 2007

Continuously mowing better at Toyota

January 14, 2007 at 11:57 pm · Filed under CMMI, Project management

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.”

Permalink Leave a Comment

Hugging a Lion …

January 13, 2007 at 12:52 am · Filed under Fun

Lion Hug

Amazing,

A nice video of a great big Lion hugging a woman .

Julia Torres, who runs the Villa Lorena animal shelter in Cali, fed and nursed Jupiter the African lion back to health years ago after it was found abused and emaciated in a traveling circus.

Permalink Leave a Comment

Blog-tagged – truth or dare for bloggers

January 13, 2007 at 12:39 am · Filed under Requirements

There is a game of Blog-tagging going on, which works like a kind of chain-letter.

The idea is that the person (owning a blog) that gets tagged, shares five little-known facts about him or herself and tagges five other persons (owners of blogs).

I got tagged by former collegues Raimond Brookman, who shared five secrets of which I new three (he’s tall, plays squash and loves meat) and Jeroen Leenarts (of which I knew about the Apple, but was surprised about the alcohol).

So here are my five little known facts:

1. At the age of 18, I was homeless for two months in Utrecht, Netherlands. In that period I slept in a shopping centre and in the weekends worked in a bar that opened at 01:00 and close at 06:00.

2. One of the jobs I had before entering Computer Science was wedding photographer.

3. I ordered a new car, a Ford S-Max.

4. I’m married with Betty, have three daughters (Lieke 16,Ellen 14, Manon 12) and a dog (Sieta)

5. Harry is my usual name, but my original name is Harm, and I’m having my aniversary on Christmas Day.

I would like to blog-tag the following bloggers:

1. Scott Sehlhorst

2. Marcus Ting-A-Kee

3. Micahel Hunter (The Braidy Tester)

4. Stephan Okhuijsen

5. Dilbert

Permalink Comments (1)

Security in Use Cases

January 9, 2007 at 11:32 pm · Filed under Requirements

Many efforts are being made to integrate security into software and software development. I lately read several interesting posts about the subject, two of them from Gunnar Peterson

Gunnar Peterson

In Top Ten Information Security Considerations in Use Case Modeling he discusses ten ways that Use Case models can be developed in a more security-focused way.

In an IEEE Security & Privacy Journal he co-wrote an article on Misuse Cases with John Steven on Defining Misuse in the Development Process.

Here’s in short what is the core idea:

Use Cases vs Misuse Cases

I remembered having seen the idea before, as Richard Claassens, a former collegue and Architect at InfoSupport showed some examples that came from the original ideas behind Misuse Cases came from Guttorm Sindre and Andreas Opdahl.

Here’s a nice example:

Misuse Case diagram

Permalink Leave a Comment

Early overtime == later project completion

January 5, 2007 at 10:28 pm · Filed under Estimating, Project management, Requirements, Software engineering

Johanna 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

Permalink Comments (1)

Outsourcing: from assembly line to extended team

January 4, 2007 at 12:03 am · Filed under Project management, Software engineering

Outsourcing

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.

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

Permalink Leave a Comment

Visual Studio 2005: See the difference

January 3, 2007 at 11:12 pm · Filed under Analysis & Design, Software engineering

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 …

Permalink Leave a Comment

Use Cases to make a better www.microsoft.com

January 3, 2007 at 10:52 pm · Filed under Requirements, Use cases

www.microsoft.com has recently been changed. Microsoft did a lot of research to make it easier to find what you look for at microsoft.com.

On the about page, some questions about the changes are answered.

One of the reasons the new page is assumed to be better is that “We based our design on data of the most common tasks, products, and services that people come to our site for, and then we validated and improved the design during months of customer testing.”

To me, as seasoned requirements specifier, this seems to be an obvious way to do your analysis and design, but when teaching classes and when coaching collegues, I often find they don’t take the time to find out the most common “Use Cases” for the system they are building. Nice to see that Use Cases seem to be working at Microsoft.

Permalink Leave a Comment

how – not – to make a process work for you

January 3, 2007 at 9:14 pm · Filed under CMMI, Requirements, RUP, Software engineering

Anti pattern Gary 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!

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