Agile for project management explained

18 March

Let’s start by acknowledging that the foundations of agile as a management model were established from an amalgam of techniques dating as far back as the 1960s. They were singularly focused on one specific goal: developing software. Take a quick read of the 20+ year old Agile Manifesto and you’ll see the number one principle is “working code over extensive documentation”. Why is this important?

Developing software is a unique process. There is no management analog in the physical world that matches the characteristics found in the virtual world. Specifically, the ability to create and destroy and recreate virtual tools and artifacts with virtually no material cost is unlike any other business activity. For the project manager, especially those working on software or data related initiatives, this dynamic lends itself to one of agile’s universally espoused techniques: short duration work iterations or timeboxes.

From a practical perspective, a timeboxed iterative approach allows incremental progress to be made without necessarily committing to a “final” design or goal before work begins. In theory (and to some degree in practice) this technique is also touted as “change friendly”, meaning that late arriving requirements based on insights from the previously delivered work can be accommodated without extensive re-work.

That said, projects can still miss the mark if the seminal concept was flawed or any number of bad decisions are made throughout the arc of the project. A lot of the same problems that exist for any project do not go away because you’ve adopted an agile approach; even if you are developing software. But they do sometimes happen faster which, while avoiding the problem in the first place would be preferable, an Agile approach surfacing inherent flaws sooner is a good runner-up.

So, how can project managers, especially those who are not managing virtual projects, best use Agile methods (there are about 30) and principles (there are about 5)?

First, take a look a look at the projects you are looking to apply Agile techniques. Think long and hard about using Agile full-stop if your projects:

  1. Require regulatory audit readiness/scrutiny,
  2. Are typically billed under labor-based Earned Value Analysis,
  3. Are comprised of well-understood processes,
  4. Exist in an environment that is risk averse and where failure has potential health or financial consequences,
  5. Revolve around delivery of non-digital products.

If any of the above situations is true, agile may not be the best choice. But if your projects:

  1. Are about developing software,
  2. Have a flexible delivery windows,
  3. Are comprised of work that without precedents,
  4. Exist in an environment that encourages experimentation and can tolerate failures,
  5. Revolve around delivery of digital products.

Then some flavor of agile may yield outstanding results.

Keep this in mind as you embark on an Agile journey: no method is superior to the others. And no implementation of Agile exists in a “pure” form; all implementations are hybrids. It is context and the constellation of resources and constraints that will ultimately determine your success.

Thank you!

Your details have been submitted and we will be in touch.