Category: process

People over Process: a Universal Law

August 12, 2008 by JurgenAppelo

Despite the progress we made in software engineering in the last two decades, some people still believe that processes can be more important than people. Sure, they have a more "balanced" view these days, claiming that people and processes are both important, and that you have to consider the business domain to see which one "trumps" the other. But they refuse to believe that People over Process is a universal principle.

Well, they are wrong.

Consider the Law of Requisite Variety:

"Only variety in a system itself can successfully counter a variety of disturbances in the environment." or "Any effective control system must be as complex as the system it controls."

Not Repeatable Results but Repeatable Success

April 24, 2008 by JurgenAppelo

I don't believe in repeatable results. I only believe in repeatable success.

Repeatable Results vs. Repeatable Processes
In his recent Agile Newsletter, using the results of the latest Dr. Dobb's survey, Scott Ambler showed his readers that most developers, project managers and IT managers prefer repeatable results over repeatable processes. Not surprisingly, according to his survey results, people in the agile community lean more towards repeatable results than those working in traditional organizations. Most respondents of Scott's survey also reported that their personal preference for repeatable results is bigger than that of their organization. Everything considered, it seems that there is a global shift towards a growing importance of repeatable results vs. repeatable processes.

Finding the Right Process

December 31, 2007 by jeremy

Agile teams are often faced with a dilemma: how much process is the right amount of process for us? There's no right answer, of course, and the closest thing to a right answer can change as often as you change your socks, which, for the sake of your teammates, I hope is pretty often.

The amount of process your team needs to succeed is influenced by a variety of factors, such as team size, team skill, honesty and trust, management style, your product domain, your team's understanding of the product domain, access to your customers, and much more. There are too many factors and variables to even consider coming up with a formula, so experiment -- try doing some new things, try not doing some old things, and see what happens.