Geeks With Blogs
Ulterior Motive Lounge UML Comics and more from Martin L. Shoemaker (The UML Guy),
Offering UML Instruction and Consulting for your projects and teams.

In our last Episode, we wrapped up Activity Diagrams (for now) by showing how Swimlanes let us specifiy who or what is responsible for each Activity or Branch. After the Lounge has dried out, we get some process instruction from Process Cop. (Click the picture for a larger image.)

Episode 17

Too often, I find that teams embark on "process improvement initiatives" without first understanding what their process currently is. This is like asking an architect to redesign your house without him ever seeing your house. The most he can do is design a whole new house. That will be way outside your budget, it won't fit your property, and it won't succeed!

Yet that's almost exactly how "process improvement" is implemented most of the time: "Here's the right process, so start following it. No, we don't know what process you were following, but this is better. This is right."

Bull. The right process varies by the team, by the project, by the schedule, and by the budget. Oh, you can have a meta-process that helps you define processes; or you can have a process family, and choose the best family member for a given project; but there is no one right process. And finding the best process starts with assessing your current process.

Some teams like the idea of Agile processes because more Orchestrated processes are getting in their way; but some teams like the idea of Agile processes because they really don't want a process at all, and Agile processes seem easy to subvert. If you have a team of Gnats arguing "We have to be more Agile," you may really have a team of anti-Process zealots. Their arguments for Agile are a sham. On the other hand, if you really want to improve your processes, Agile may be as far as you can move them. Gnats may become Cattle, but they can't become Circus Horses overnight. Look for more Orchestration only if you really need it.

On the other hand, if you have a team of Lemmings and you're trying to improve your processes to cut down on failures, yet more Orchestration will probably make matters worse. Lemming processes are the problem, not the solution.

And if you are embarking on a process improvement initiative, the first improvement I recommend is wider adoption and use of UML for communications throughout the process. I hope I've given you a few ideas here.

The fundamental goal of Process Cop is to ensure that process, team, tools, and requirements are all compatible. This is complicated, because team is “whoever we could hire”, tools are “whatever we’ve bought or built or downloaded”, and requirements are “whatever customers ask for”. The idea that a single process designed in isolation from these can be the missing link that somehow binds them all together is naïve, and will cause The Team to lose respect for Process Cop. Team, tools, requirements, and process all have to adjust in different ways if there’s to be any hope of success.

Now UML can help Process Cop to guide these adjustments. Remember: UML is about modeling systems, not just software, where:

System = Structure + Behavior + Goals

By this definition, a team and a development project make up a System; and indeed, UML can be used very successfully to define and revise the processes for that system. Maybe later, Process Cop will show you some examples.

For the record: lemmings don't actually march off cliffs in mass suicides. But it's such a powerful metaphor, it will never die.

P.S. Actually, I’ve never really liked this film series much. But it seemed like a good film reference for this Episode, since the subject is a little bit academic.

Posted on Saturday, November 15, 2008 5:05 PM Ulterior Motive Lounge | Back to top

Comments on this post: Ulterior Motive Lounge Episode 17: Process Cop Academy

No comments posted yet.
Your comment:
 (will show your gravatar)

Copyright © Martin L. Shoemaker | Powered by: