• Project Success
    Permalink Gallery

    A Pragmatic approach to Software Process: UP + Critical Chain; Applied to a Retro-Engineering fixed-price project

A Pragmatic approach to Software Process: UP + Critical Chain; Applied to a Retro-Engineering fixed-price project

Software Process is great topic for endless conversations (and battles) among IT professionals. Every now and then, a new process is arriving on the market that is introduced as the new marvel of the world, the new silver bullet, thanks to which every software project is going to be a never seen before success. We can name a few:

Waterfall
V-Model
Prince 2 (although this one is not really an IT project process)
Unified Process
Agile family

eXtreme Programing
Scrum
Cristal
DSDM (Dynamic systems development method)
Kanban
Lean
Etc.
Etc.

During our decades of projects experiences, we have encountered many of these processes, used on various projects and in various circumstances. Today, I would like to talk about a project during which we have used a combination of a “proper” (in the sense of created with this purpose) software development process and a more generic project management approach. The two processes are:

The Unified Process (also known as Rational Unified Process, before IBM bought Rational) created initially by Ivar Jacobson, Grady Booch and James Rumbaugh.
Critical Chain, created by Eliyahu Goldratt

 
The Unified Process
The Unified process is not only a process but more generally it is a framework that has been created for being tailored for each project. It is the first iterative and incremental framework that has been applied widely in the industry.

It is composed globally of four Phases, each Phase being composed of Activities.

One of the most interesting elements is the Phases as they describe periods of the project during which the objectives are different. The first phase, the Inception is about scoping the project, identifying a possible architecture and listing the risks to come. Then comes the Elaboration phase, mostly about validating an architecture, [...]

Open Space and Mates’ Mere Presence

Who in the software industry has not worked in one of these huge open-spaces readily available in many workplaces? Those who have not can probably consider themselves as the exception. Those who have, probably wonder where on earth this idea of putting dozens and dozens of people in the same room to produce software, come from. I’d love to meet that guy who suggested that first, just to be able to put a face on it. I doubt there is only one source. Anyway… my point is not to find the culprit but to think about the consequences of such choice.
The question came to me first when I was asked to work in such place, then when I read Peopleware (Tom DeMarco) and then when I read about the Zajonc experience. All in all it deserves to think about it.

Let’s start with the Zajonc experiment. Robert B. Zajonc (pronounced Zy-unce – like Science with a Z; born 1923) is a Polish-born American social psychologist who is known for his decades of work on a wide range of social and cognitive processes. In 1969, this fellow and his team have conducted a strange experiment with cockroaches. He found out that cockroaches ran faster down a runway to escape a light source if the runway was lined with an “audience” of onlooking fellow cockroaches (each in its own plexiglass cubicle). This work led to the theory that the mere presence of species mates elevates drive/arousal of the performer. Since then, plenty of other research teams have lead other experiments. In the end, a meta-analytic review has been conducted by Bond and Titus in 1983 of both published and unpublished works involving over 20,000 participants. I [...]