The Promise and Danger of Agile Project Methods

The Agile Manifesto (http://agilemanifesto.org) is a “great leap forward” in thinking about how software can best be created. It’s four basic values are simple and sensible statements of where priorities should lie in any software project and can even bee applied to projects outside of software development.

Of the for values, only the last (“Responding to change over following a plan”) would have any serious argument from most Project Management Professionals. At the base of everything a PMP does is the creation of a plan and then following that plan. The plan is constantly reviewed, of course, but it is always there and it is followed. If circumstances demand that the existing plan is no longer valid, then the plan is changed and the new plan followed. But the plan is always followed.

No doubt followers of the Agile methodology would say that they do not reject all planning, just that responding to change is more valuable. My observation, though, is that those seeking to apply Agile methods to projects tend to throw out planning altogether (they often throw out processes, documentation and contracts as well).

In some descriptions of Agile development you will find that the Project Manager has been relegated to an administrative role - making sure that there are enough white boards and scheduling meetings with senior management . They are actually project expeditors and not managers at all.

The fact is that the planning function in any project is so important that it is always being done in any successful project. It is done usually by someone by default who has the leadership potential and the experience to do it. He or she may do a lot of the planning behind the scenes and informally, but the planning does exist and is followed. A plan is pushed ahead through force of will and cajolery, or it is not followed and the project fails.

I have seen some embrace Agile mainly because they cannot plan, document, negotiate or use processes or tools effectively. They see it as their license to jump in and start coding. We have seen this same kind of behavior for many years in the software industry and few seem to have learned the lesson that this just does not work. It does not create workable, stable systems that can be maintained and that bring value to the business over the long term.

The Agile Manifesto itself is very short and sweet. Many other words have been written to expand on those ideas and to create a full-blown methodology. My hope is that we will one day see a methodology that balances both sides of the value equation. There is no doubt that software development processes must change and Agile will be an important part of that. We will probably see a gradual swing to the center where values are more balanced. I certainly hope that is the case.