Using Agile Principles in Project Management

Agile is a methodology used by top software development organizations to increase team productivity and improve product quality. As soon as I found out about Agile, I started reading about it by grabbing any books and articles I could get my hands on to uncover its processes and principles in an attempt to learn what makes it so successful. My goal in this quest was primarily to find out new ways to be a better project manager. In the end, I came to the realization that Agile and Project Management (“PM”) have a lot in common and that some Agile techniques should be part of the Project Manager’s toolkit.

In order to explain further, I will be using Mike Cohn’s “Seven Sins of Project Management”. Mike has a long pedigree with many accomplishments, one of which is as founder of Mountain Goat Software and of the Agile Alliance. If you are a PMI member, you may download a recording of his recent webinar on this topice here.

(1) Gluttony: Doing too much with the resources available. 

Agile: Timeboxed iterations lead to learning of a team’s velocity (how much it can accomplish over a given period of time); thus the ability to set expectations.

PM: Good project managers will break off large projects into phases, maintain a risk log and communicate effectively and continuously to top management and the team about scope, budget and schedule.

(2) Lust– Known in Project Management as “scope creep” or in software development as adding too many features in one release. In other words, treating all features as important (all are “must-have”).

Agile: Features are developed in a priority order in 2 to 4 week sprints.

PM: The Project Scope Statement is used by team members and stakeholders to understand what is to be delivered, by when, how the resulting product will be accepted, what is not part of the scope and what the constraints are. A solid change control process will ensure any change to the scope is approved by stakeholders and that they understand how the change will impact the constraints. Changes are inevitable  as more details are known about the product or service under development. The crucial piece are the processes used to control and communicate changes.

(3) Sloth – Quality is not always maintained at acceptable levels.

Agile: Simple design, automated testing, continuous integration and code refactoring all contribute to quality. Short iterations and sprint review meetings provide a great way to discuss what went well and what needs to be improved to maintain a high quality standard going forward.

PM: Project Quality Management deals with quality standards, quality assurance and quality control.  When quality is planned for, measured and controlled throughout the project, the end result is a quality product or service as required by the customer. The PMI also stresses prevention over inspection and continuous improvement.

(4) Opaqueness – Not knowing or not being upfront about the true state of the project.

Agile: Small iterations, continuous integration and knowing a team’s velocity all contribute to a certain level of comfort with achieving results on time and on budget. As well, the daily stand-in meeting offers a great forum for team members to voice concerns before it is too late.

PM: By and large with PM, the difference between a foggy and a clear project stems from the leadership and communication skills of the PM. Ninety percent (90%) of a PM’s job is to communicate. However, there is no PM process that enforces straight forward, clear, effective and ongoing communication. That is up to the PM and constitutes what makes the difference between a good PM and a poor PM. Interpersonal skills should be key when chosing a PM to lead your project.

(5) Pride – When the team thinks they know everything about the project

Agile – Offers many opportunities for feedback in order to avoid the pitfalls of “we know it all” which leads to a lack of stakeholder involvment and  missed opportunities to learn.

PM – Stakeholders and team members involvment in the planning processes will ensure pride is avoided. However, only a PM with solid persuasive, leadership and communication skills (see #4 above) will be able to obtain everyone’s involvment in these processes. The PMI does not enforce any specific intervals for meetings however, I personally believe that most projects require weekly meetings, even if short, to ensure no surprises (better clear out any issue sooner rather than later when they can be costly to fix).

(6) Wastfulness – Wasting scarce resources.

Agile – The very nature of Agile (meaning all its pricinples) keeps waste in check.

PM – Again, solid planning along with the risk log, issue log and effective communication as well as a good change control system prevent waste.

(7) Myopia – Not seeing the big picture.

Agile – Cross-functional, self-organizing teams ensures everyone is aware of what the others are working on. Even though the team works on a specific sprint, they are aware of the complete product schedule.

PM – All stakeholders must participate in the planning processes and the Project Management Plan must be available for everyone to consult at any time.

Agile’s short iterations and constant opportunities for feedback provide a solid foundation for high-quality predicatble results. Project Managers need to think about cutting large projects into phases and including regular feedback loops in order to benefit from Agile’s proven successes.

One thought on “Using Agile Principles in Project Management

  1. thanks. great article.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title="" rel=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>