Buu Nguyen's Blog

I’ve come across the latest paper from Ivar Jacobson (yes, one of the “Three Amigos” who invented the RUP and UML) about development processes (Enough of Processes: Let’s Do Practices Part I and Part II) and so much as I admire Mr. Jacobson and his contribution to the software industry, I just do not find anything he wrote in this latest essay new or provoking, especially to those who have been working with agile processes like XP, or Scrum.

In Part I, Jacobson enumerated some problems of development processes, such as the Problem of Denied Commonality (e.g. people fail to recognize commonalities in different processes and pick out which can really work), the Problem of Completeness (processes tend to get bigger and bigger and people need to “deselect” things which are not necessary for their projects), the Problem of Out-of-sync Process (the actual process carried out by the team is different from what documented in the organization process), the Problem of Acquiring Knowledge (the possible steep learning curve when learning about new processes), the Problem of Stupid Processes (people have to find out how to execute the process instead of having it “actively” helps people make decisions and/or carry it out).

First, all the problems described about are not as much processes’ problems as they are people’s problems. For example, if an organization keeps relying on a separate process team to dictate the process to be carried out by any project team, then the problem of out-of-sync or the problem of completeness will certainly occur. In Jacobson’s arguments, he seems to over-criticize the current processes as though they spoil the people who use them (possibly to give a proper context to promote his new process) while failing to emphasizing that processes are just tools and the people are the ones who spoil themselves by choosing the wrong tools or using the right tools incorrectly. In fact, you would not find many of the above problems in a decent XP or even RUP team. The point is while a “smarter” process is necessary (greater tools are always welcome), it is much more necessary to have smarter people use it since I don’t see how a process can be smart enough to replace smart people (No Silver Bullet, everyone?)

Second, all the problems described here are nothing new to the software community. We already know iterative development is good and promoted by all today’s development processes, that it’s the team who should grow out a process, instead of strictly adopting a pre-defined process created by some people who have no idea about what is going on in the project, that we should mix and match practices from different processes as long as they work, and so on. And you know what, someone even created XP.

In Part II, Jacobson basically proposes that processes should be defined as a collection of reusable, measurable, and loosely-coupled practices. The benefits of this, according to Jacobson, are

Instead of learning or adopting an entire process, practitioners learn about individual practices and adopt these practices incrementally to improve their way-of-working. First, they select the most appropriate practices to address their needs and help them cope with the challenges of their current situation. Then, they adopt these practices in whatever combination and at whatever speed suits them. Most importantly, they add new practices to their existing way-of-working without changing everything or throwing away the practices they already know.

If they want to, teams can start afresh with a new way-of-working, but experience has shown that it is more effective to transform the way-of-working one practice at a time. When it comes to process improvement, a big-bang approach doesn’t work. Trying to change everything, all at once, is a high-risk strategy. Even if you want to move to a totally new way-of-working, it is easiest and safest to do it one or two practices at a time. This minimizes the disruption caused by changing working practices, and provides a focus to the coaching needed to embed the new practices in the team. It also allows you to directly address your problem areas without having to change the practices that are already working well.

In the future, you will combine practices from many sources to create the way-of-working you need. Rather than talk about the process you follow, you will talk about the practices you use. If someone tells you about a new practice, you will be able to try it without affecting the practices that you are already using. You will even be able create and develop your own practices, then blend these with standard practices to create truly new and innovative ways-of-working. You will not be tied to any one process camp or ideology; you will be able to mix-and-match practices from any source to continuously improve and tune your way-of-working.

These are well articulated and I totally agree with the points, but again, they are not new and are things that people like Kent Beck, and Ken Schwaber having been preaching for years.

Having said all this, I do not deny the potential value of Ivar Jacobson’s essay. In fact, it is very useful if his ideas are disseminated more widely among the development community, especially to the high level executives or managers who do not have a chance to bite agile yet. And Ivar Jacobson, as a huge figure in the software industry, is among the few people who can possibly do this. So, watch out for the Essential Unified Process, a new version of RUP, created by Jacobson based on the same line of thought he expressed in this essay.