For example, if you are trying to create a web site to satisfy the needs of an organization, attempting to document all the requirements fully before beginning the development is often not an effective approach. If an IT process is followed so that requirements documents must be completed in great detail and accepted, and every change thereafter must go through a formal change control process, there is high probability that the client will be frustrated as will the project team. Why would anyone follow such a process? Because they are codified and institutionalized; they are the rules.

Agility in this case would enable developers to work directly with clients who can make decisions about functionality and format as the site is being built. Functionality would evolve as the site is delivered and put to use.

Process is Necessary

Agility without a well-defined and effective process is chaos. It risks shortsightedness — creating a product that is not easily enhanced, for example.

In the case of the website, one aspect of process is the decision-making as to whether the project should be undertaken and how it should be managed; whether to use an Agile approach, how to capture performance data (e.g., the number of hours worked on components) and report on progress, and what kind of documentation is needed.

Other aspects are the way requirements and changes are to be handled, how design constraints and reviews are to be done, who will do testing and how they will do it.

Further, a process for product planning is needed to provide, in broad brush strokes, a road map of where the development is headed.

Maintaining the Right Balance

The notion that Agile approaches are without process is just plain wrong. If you analyze a methodology like Scrum, you can clearly see that there are role definitions, prescribed techniques, tool utilization and more. These add up to a defined process.

The Right Balance

The trick is to be able to strike the right balance. The process needs to include a clear understanding of where, when and how to change the process.

If change can take place on the fly, decided by the performers themselves at the team level, then the process is highly flexible. But for this to work in an organization, there must be standards and policies to guide and constrain the change. There must be well-trained and relatively clever performers who take responsibility for their actions and recognize the need to address both short-term and long-term objectives.

Not every team or individual has the wisdom to do the right thing. Some are so focused on the needs of the moment that they make decisions that restrict future growth and sub-optimize the overall process or program that the project is part of.

It’s like the old Zen parable about keeping horses. Give them unconstrained space and they'll wander away. Put them in too tight a pen and they'll kick their way out or get so still that their muscles will become weak and they won't be of much use. Put them in a large enough controlled space and they'll be happy and healthy. When they get to the fence, they'll turn in another direction because there is no need to jump the fence.

The point is that we need constraints and defined processes but they must add value to both the project and the broader context of which the project is a part of. We need an effective, flexible process that gives people the ability to adapt to the needs of the current situation while adhering to best practices and coordinating within the bigger picture.

Don't forget to leave your comments below.