Principles of an Agile PM Method


I have enough space this month to describe the Principles that form the basis of an Agile PM method. These principles are applied to IT projects, but other project domains may be appropriate.


Assume Simplicity – as the project evolves it is assumed that the simplest solution is best. Overbuilding the system or any artifact of the project must be avoided. The project manager should have the courage to not perform a task or produce an artifact that is not needed for the immediate benefit of the stakeholders. In many instances “the simplest solution” may be hard to find. It’s the intention of finding the simplest solution that is of value here.
Embrace Change – since requirements evolve over time, stakeholder’s understanding of these requirements evolve as well. Project stakeholders themselves may change as the project makes progress. Project stakeholders may change their point of view, which in turn may change the goals and success criteria of the project. These changes are a natural part of a project that makes use of technology in some way. If we’re repaving the road in front of the office, the level of change may be low. But beyond simple concrete and steel, projects have a nasty habit of changing their requirements.
Enabling The Next Effort – a project can still be considered a failure even when the team delivers a working system to the users. Part of fulfilling the needs of the stakeholders is to ensure the system is robust enough to be extended over time. Using an Alistair Cockburn concept, “when you are playing the software development game your secondary goal is to setup to play the next game”. The next phase may be the development of a major release of the system or it may simply be the operation and support of the current system. One advantage of agility is the constant redefinition of what features and functions are to be contained in the current release of the system. I can hear the cries of the traditionalist now – “you’ve got to control the scope.” The scope control problem must be a shared experience. The stakeholder must be given the ability to change their mind, while at the same time the PM must acknowledge that changes will and must occur in any project that deals with technology and emerging business needs.
Incremental Change – the pressure to get it right the first time can overwhelm the project. Instead of futilely trying to develop an all–encompassing project develop a small portion of the system, or a high–level model of a larger portion of the system. Evolve this portion over time, and discard portions that are no longer needed in an incremental manner. Managing these incremental changes requires discipline and resources. Without discipline and resources chaos will occur.
Maximize Stakeholder Value – the project stakeholders are investing resources — time, money, facilities, and etc. — to create a system to meet their needs. Stakeholders expect their investment will be applied in the best way. It is the incremental delivery of stakeholder value that is the core principle of any agile project. This means that the stakeholders get to say what is of value in the next release. The PM’s role is then to deliver that value.
Manage With A Purpose – by creating artifacts that have stakeholder value. Identify who needs the artifact. Identify a purpose for creating the artifact. This seems an obvious principle, but it is often violated by the creation of paperwork that has no value to the project. Asking the simple question – “what is the bookable value to this project for the document, work process, activity you are asking me to produce or engage in?” If the answer is “I don’t know,” then the PM shod question the task.
Multiple Project Views – considering the complexity of any modern information technology system construction or acquisition process, there is need for a wide range of presentation formats in order to effectively communicate with the stakeholders, participants, and service providers. These multiple view go beyond PERT and GANTT charts. The “big picture” chart, multiple architecture pictures, sketches, white board drawings, even hand waving in the hallway re all part of the communication process. Making these views visible to all participants is the most important. Having the view locked up in three–ring binders is the least productive.
Rapid Feedback – the time between an action and the feedback on that action must be minimized in order to be agile. Work closely with the stakeholders, to understand the requirements, to analyze those requirements, and develop an actionable plan, which provides numerous opportunities for feedback. A good rule of thumb is to provide feedback that can be assessed by the stakeholders on a periodic basis. Not on a calendar event basis.
Working Software Is The Primary Goal – not the production of extraneous documentation, software, or management artifacts. Any activity that does not directly contribute to the goal of producing working software should be examined to determine its value.
Travel Light – since every artifact must be maintained over its life cycle. The effort needed to maintain these artifacts must be balanced with their value.