Bindings, Platforms, and Innovation
This presentation focuses on the Internet and separating myth from fact, history from the future, and the mundane from the imaginative. Bob Frankston presents a vision of what could and should be.
News
Father of the Unified Process says "Enough of Processes"
Posted by Geoffrey Wiseman on Apr 03, 2007 11:13 AM
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 Development: A Manager's Roadmap for Success
Give-away eBook – Confessions of an IT Manager
Ensuring Code Quality in Multi-threaded Applications
The Agile Business Analyst: Skills and Techniques needed for Agile
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.
Why?
by
Brendan Lawlor
Posted
Apr 3, 2007 5:42 PM
Re: Why?
by
Dean Schulze
Posted
Apr 3, 2007 5:59 PM
Re: Why?
by
Andre Sobotovych
Posted
Apr 4, 2007 8:12 AM
Re: Why?
by
Brendan Lawlor
Posted
Apr 6, 2007 4:42 AM
Re: Why?
by
Michael Neale
Posted
Apr 3, 2007 10:48 PM
Re: Why?
by
Geoffrey Wiseman
Posted
Apr 15, 2007 7:35 PM
Better late than never
by
Paul Oldfield
Posted
Apr 8, 2007 5:37 AM
Practice doesn't cut it for contract-driven companies
by
Chris Andrews
Posted
Apr 19, 2007 11:13 AM
-
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? -
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. -
Well said ! I can't think of a better way of putting it.
-
> 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.
-
A slightly more comprehensive reaction to the Dr. Dobbs article.
-
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.
-
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.
-
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.
8 comments
Watch Thread Reply