Father of the Unified Process says "Enough of Processes"

Posted by Geoffrey Wiseman on Apr 03, 2007 11:13 AM

Community

Agile

Topics

Methodologies

Tags

UP

Ivar Jacobson has a long and storied history in the development of the tools and processes that are used by companies the world over to develop software, from UML to the Rational Unified Process, while at Ericsson, Objectory and Rational. So, when someone with this background says “Enough of Processes, let's do practices”, we’re bound to wonder why.

Ivar Jacobson argues that "processes" try to address the entire software-development cycle, rather than encouraging teams mix and match elements of processes together. This reduces flexibility and hides the commonality between many processes. Further, processes and their adopters strive for completeness:

The desire to provide a complete process also makes the process heavier as more and more information is added to cover all of the disciplines involved. As the process evolves, no one ever takes anything out because someone somewhere might need it some day.

The essay points out that teams rarely adopt processes fully anyway, selecting those elements that work for them and modifying those that don't, or importing elements of other processes that fit well with their team, technology and business.  This leads to a 'project-process gap' which has harmful side effects. 

The process should be a description of what the team actually does, rather than a fictional description of what people think the team ought to be doing.

As a solution, Ivar Jacobson argues that we should be communicating about practices, rather than processes, the building blocks from which a team's own process can be assembled.  These practices can be described individually and these descriptions shared from one process to another, such that the commonalities and differences between one team's process and another's is much more visible.  This approach of describing process through practices is not without precedent; one could argue that it is a part of the way in which many processes are described today.  However, creating a consistent and shared vocabulary of practices and how they relate to published and team processes is clearly still a work in progress.

Part II of the article, yet to be published, will describe the proposed solution in more depth, likely talking about EssUP, the Essential Unified Process, and EssWork, the approach, infrastructure and tooling to support a practice-oriented approach in Microsoft and Java environments.  The MSDN network has previously published a presentation on these subjects.  Reading either one may help a team to understand how EssUP and EssWork would fit with their own approach.  Even when a team chooses not to use EssWork and EssUp, Ivar Jacobson's stature in software development processes implies that a new movement in how we talk about the way we build software has begun.

To read more about EssWork, EssUp or Ivar Jacobson, stay tuned to InfoQ's coverage of Agile and the Unified Process

RelatedVendorContent

Agile Tool Evaluation Guide

The Agile Business Analyst: Skills and Techniques needed for Agile

Scaling Agile on large teams & Being Agile every day Tracks @ QCon SF Nov 19-21

Related Sponsor

VersionOne is recognized by Agile practitioners as the leader in Agile project management tools. Companies such as Adobe, BBC, CNN, Dow, HP, IBM, Sony and 3M have turned to VersionOne to help deliver greater value to their customers.

1. Back to top

   Why?

   Apr 3, 2007 5:42 PM by Brendan Lawlor

   So, when someone with this background says “Enough of Processes, let's do practices”, we’re bound to wonder why.

   Let me see if I have this straight. One of the Three Amigos that saddled us with RUP, and then missed the boat completely on the return to common sense that was the agile movement, is trying to sell us the idea that re-badging Process as Practice is the next revolution in software development. If this essay were written by anyone else, it would be merely banal. That it is written by Ivar Jacobson adds an element of brazenness (or at least it does for anyone who has ever had to write software under the suffocating influence of an army of overpaid, overblown RUP consultants). To me the "why" of this article is clear. Ivar Jacobson is trying to make himself relevant. I have no problem with that. Everyone is free to try to make a living. But I suggest this article provides an excellent opportunity for the software development community to demonstrate that it has learned something over the last 10 years and stop looking for the Next Big Thing. We already have the tools we need to write good software. We already know that to write good software one needs good engineers, good project managers and an infrastructure that supports both without getting in the way. We don't need to hear any new buzzwords, any newly coined expressions, any more attempts to extract the profound from the patently obvious. Can we get back to work now?

   Reply

2. Back to top

   Re: Why?

   Apr 3, 2007 5:59 PM by Dean Schulze

   Let me see if I have this straight. One of the Three Amigos that saddled us with RUP, and then missed the boat completely on the return to common sense that was the agile movement, is trying to sell us the idea that re-badging Process as Practice is the next revolution in software development.

   What was the original era of common sense that agile returned us to? I must have missed that. I also doubt that the software industry will ever stop looking for the Next Big Thing. Anyway, Part 1 of Jacobsen's article is Deja-Vu all over again. He articulates some things well, but I've heard them all before in one way or another. I'm eager to see what he has in Part 2. I've been skeptical of the current agile fad that says that you have to have a custom designed process / set of practices for each software project. That seems like it's just a way to sell agile coaching services to me. If Jacobsen has something that is more than just common sense that will help you identify which practices will work well on any particular project then that will be useful. I'll believe it when I see it though.

   Reply

3. Back to top

   Re: Why?

   Apr 3, 2007 10:48 PM by Michael Neale

   Well said ! I can't think of a better way of putting it.

   Reply

4. Back to top

   Re: Why?

   Apr 4, 2007 8:12 AM by Andre Sobotovych

   > I'll believe it when I see it though. The sad part is that anyone can end up being a guinea pig so others could learn.

   Reply

5. Back to top

   Re: Why?

   Apr 6, 2007 4:42 AM by Brendan Lawlor

   A slightly more comprehensive reaction to the Dr. Dobbs article.

   Reply

6. Back to top

   Better late than never

   Apr 8, 2007 5:37 AM by Paul Oldfield

   Although the Agile community was often not very much in favour of mix and match approaches early on, this view changed several years ago. it's good to see Ivar catching up at last. Here are some useful references from that era - a lookup table to help mix and match here (from the Appropriate Process site). Slightly more esoteric, here is an article reproduced from Agile Times helping to promote mix and match.

   Reply

7. Back to top

   Re: Why?

   Apr 15, 2007 7:35 PM by Geoffrey Wiseman

   I don't know -- if nothing else, there are a lot of software managers who still believe in Big-M Methodologies like RUP, and this could be the ammo that some teams need to convince their managers that a heavy document-centric process is not the right approach. In any case -- I think his voice still carries some weight, and I'm glad to see that weight moving in this direction, because heavy processes have been hurting development teams for years.

   Reply

8. Back to top

   Practice doesn't cut it for contract-driven companies

   Apr 19, 2007 11:13 AM by Chris Andrews

   Although I wholeheartedly agree with the concept that it's easier to implement practices during development rather than impose process on a whole effort, the reality is that in the project-driven space, practices aren't good enough. Typically my clients want their vendors to sign a contract with fixed scope and time lines, and to them the only way that we can appear to deliver is by bringing them a set process. I agree that it's typically artificial, but it's still reality.

   Reply

• Older >