I’ve read your book on Workflow modeling.
It’s one of the best books i’ve ever read.
It covers concepts and details.

But I have a question for you ?
Do you know a good book on products engineering.
And how does products engineering fits in workflow modeling.
I know they are interconnected.
Wright ?

I’m envious. Your first post is longer than mine was. Fortunately, you picked a safe topic…

Welcome to the blogosphere. The online conversation just got better.

Great start to the blog. I seem to recall Scott Ambler himself underscoring the practice of matching methodology to the situation. Did that cover tweaking the methodology? I suspect he did.

As for tweaking, it’s important to thoroughly understand what is core vs. dogma. For example, take lean AKA the toyota production system. I recall colleagues who insisted on using pencil and pad to record and catalog. Toyota itself has been testing software driven mapping and parts documentation. A friend was instrumental in the creation of some of the software pieces and database for Toyota.

I should have had you review my post before I published, then I could have done a better job of making my points. I completely agree with your points about methodologies, especially that you have to stand for something, and persevere. (I have to agree, because I’m a “process guy” and a methodology is just that - a process. I think my book is essentially a methodology for taking on a process improvement project.) I just wanted to make two points, using Ivar’s talk as a starting point:
One was that methodologies tend to grow until they don’t stand for anything any more. I was at an excellent seminar by Scott Ambler last week, and he described all the things (practices) that you need to add in a successful, rigorous Agile environment. I pointed out that in the end, he was talking less about Agile than about any solid system development methods, and asked “when does the term Agile cease to be meaningful?” He said that it’s already happening.

The other point was simply that some teams, especially those with less experience, will follow a methodology too dogmatically, even when there are aspects that clearly aren’t working. That’s just about as bad as no methodology.

I like the approach that one of my clients is using. They have a small number of core methodologies, and for any project a team is expected to use one as the basis. Then, the team has to develop an “approach model” to describe how they will adjust the method, if at all, for the specific situation. The core stays the same, and doesn’t expand without end.

Hey, speaking of “perseverance,” you’ll like this. One of my friends is a senior resource in a very sophisticated Agile group at a huge, global firm. A couple of years ago they surveyed all of their Agile developers worldwide, asking what the key lesson had been from their experience with Agile. The overwhelming response - “trust the process.”
Sounds like perseverance and standing for something.

Cheers,
A.

The problem with mehtodologies is not the number of them around but the lack of perseverence people have with implementing any given one.

My take is….pick up and implement it very well.

cheers
Phil