Last year I was lucky enough to watch Ivar Jacobson presenting his current work on software development processes. This work is summarized in the 3-parts article Ivar published in Dr. Dobbs magazine named “Enough of Processes: Let’s Do Practices”. In the first part, Jacobson describes a series of problems with processes and concludes:

What Do These Problems Mean?

Taken together, these problems are making it harder and harder for companies and teams to establish an effective way of working. The processes are becoming a barrier to change rather than an enabler. The solutions being produced don’t really address the needs of development teams. A lot of good ideas are arising in the industry; however, other good ideas are being discarded in a vain attempt to be fashionable and to be seen as keeping up to date.

Each of the problems outlined leads to paradoxes and contradictory behavior. For example, given that people don’t read processes, why do so many people write them? Agile methods have been designed to rely on tacit knowledge instead of explicit knowledge; still, agile experts spend much of their time writing books and processes.

Lots of people are making lots of noise. Every practice that appears is labeled as a “best” practice. Every tool is presented as a solution to all the problems. But are we really moving forward? The industry is not really getting any better at developing software, the problems are just getting moved around. There is no firm foundation of first principles and cracks are starting to appear. The longer you spend in the industry, the more and more the success of each new process looks like another case of the Emperor’s New Clothes—another triumph of spin and marketing over innovation and substance. A lot of excitement and noise is generated, but if you look closely, there is very little new that is actually there.

There needs to be a better way to collect and share knowledge. If it only sits in the head of a few special people, it won’t help us scale up. We need to break out of the patterns of the past and find new ways of capturing and sharing knowledge.

It doesn’t matter if you agree or not with the author –I have my points of divergence as well- it is very clear for me that Ivar’s words apply to the current agile software development community.

Ivar Jacobson is one of the fathers of UML and the Rational Unified Process. Let’s get back to the 90s. Some wise guys decided to pack together a bunch of practices, label it and make profit from consulting & tools -that’s an one-liner for RUP’s history. The process itself wasn’t that bad. It was based on sound principles like iterative development, roles, modeling, and software architecture. It was flexible and provided a lot of good practices and just a few of those were actually required, others should be used when needed. Pretty reasonable for that time.

The company is a success, after some years everyone and their dogs want to be a RUP shop. With the spreading, the process itself became a bit… different. In the beginning the RUP thing was a name for some good practices but suddenly the process became more important than the practices. When technology evolved and some practices like manual model transformation (i.e. specification in UML diagrams) were not that important anymore they would still use them religiously, otherwise it wouldn’t be the process.

As they had IBM/Rational’s blessing (in the form of expensive certificates and training courses), tons of companies said they had RUP but practice a really classical waterfall. No iterations, just phases. No software, just documentation. Do increments, just big bangs. Instead of choosing what were the suitable practices they just grabbed them all.

And then, after all those years, some people like Ivar realized that there’s something wrong with it.

Now get back to the present. Think about how many people use terms like ScrumMaster when they mean project manager (or iteration manager) , product owner when they mean client/business analyst or even sprint when they mean iteration. Think about how many people send an email asking “how Scrum solves this problem” instead of advice on what’s a good solution for that. Think about people charging $1~$2 thousand in two-day introductory courses. Think about teams that are told by management that “they have to use Scrum” even tough they’ve been doing agile practices for ages.

Where are we going? Are we there yet?