Processes, Practices, and Priorities

Ivar Jacobson is currently speaking out against the focus on process over practice in development methodologies. I saw Ivar make similar statements at the Architect Insight conference earlier this year. Considering that Ivar Jacobson is one of the parents of UML and the father of the Rational Unified Process, that’s quite a heavywieght opinion. Ivar notes that
"it doesn’t matter which process you adopt as long as it is adaptable, extensible, and capable of absorbing good ideas, even if they arise from other processes.
To achieve this kind of flexibility, things need to change. The focus needs to shift from the definition of complete processes to the capture of reusable practices. Teams should be able to mix-and-match practices and ideas from many different sources to create effective ways of working."
The problems with existing process for Ivar can be summarized as:
    • Processes accrete new elements as they strive to become more complete, and never indicate that portions can be dropped making the whole expensive and unwieldy. Yet at the same time processes are sold as an ‘all-or-nothing’ proposition.
    • Teams will always tend to modify the process to fit their scenarion and practices. This means that while the organzation believes it is following the process most of its teams are not. This increases cost as unecessary work is done, or resources are spent on auditing the process to ensure conformance. That cost does not contribute towards delivery of the project.
    • Learning the process is often costly and does not in itself help the team deliver, just conform to the process. What the team wants is practical advice on specific issues.
    • Process is a set of guidelines to be followed not a set of tools to help you.

Ivar suggests that instead we need to focus on sharing practices, the difficulty for Ivar is how we collate that practice and share it, without it becoming process.

Personally I have always liked Alistair Cockburn‘s approach to Agile development in his Crystal methodologies. Alistair focuses on priorities for software development and his various flavours of the Crystal methodology describe practices for different team sizes that can be used to achieve those priorities. Alistair observed teams working on software development projects and observed the following properties of successful projects:


    • Seat people close together, communicating frequently and with goodwill.
    • Get most of the bureaucracy out of their way and let them design.
    • Get a real user directly involved.
    • Have a good automated regression test suite available
    • Produce shippable functionality early and often.

And observed that if you can provide those properites "most of the process details will take care of themselves". These properties are the cornerstone of agile development methodologies from SCRUM to XP, not just Crystal and Alistair’s point is that it is less imporant how you achieve them, but that you have the properties.

Within Crystal the properites of successful projects are achieved by meeting priorities.

A lot of organizations struggle with XP because it requires high maturity. It is not extreme programming for nothing. The problem is that teams who do not have sufficent maturity drop some of the practices, and with no guidance on how to compensate for the practices they have dropped, fail. XP practitioners often recite the mantra to ‘follow all of the practices’. The issue is that for some teams, while they may be willing, the bar is out of reach. The teams lose confidence in agile methodologies, because XP does not deliver results for them. By dropping some of the practices they fail to meet some of the priorities of successful teams. Now experienced practioners of XP have probably internalized the priorities over time, which enables them to successfully coach XP teams to success. But XP is not explicit about its priorities in a way that allows a team figure out how to compensate for the practices they cannot achieve with alternative practices. 

By idenitfying priorities as Crystal does it becomes possible for teams to change practices that don’t work for them, and provided that they still have some means to meet the priorities, succeed. In addition, it becomes possible to review practices, so that we fit the practice to the scenario, rather than assuming a one-size-fits-all approach. At that point the practice begins to work for us, rather than us working for the practice.

Cockburn’s approach in prioritizing properties of a project over processes, seems to be the best way to meet Ivar’s goal of switching the focus to practices without getting bogged down in process. Crystal identifies seven priorities:

    • Frequent Delivery
    • Reflective Improvement
    • Osmotic Communication
    • Personal Safety
    • Focus
    • Easy Access to Expert Users
    • Technical Environment with Automated Tests, Configuration Management, and Frequent Integration

While XP satisfies these properties, so do other combinations of practices. Working to priorities allows your team to evaluate practices to determine how well thet meet with these goals. It also allows you to review your project to see which items you are weak on and need improvement.





This entry was posted in Computers and Internet. Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s