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