Bridging the Gap: Traditional to Agile Project Management

      No Comments on Bridging the Gap: Traditional to Agile Project Management

hdr-agile-scrum-conferenceInternational Institute for Learning organized its first Agile and Scrum Virtual Conference. 5 keynotes and 20 video presentations, Q&A, chat, and networking opportunities in an slick and smoothly working online environment. Not only IT, but many companies in other sections are benefiting from Agile approaches like Scrum. Too much to watch in a single session, with the 1,100+ other concurrent watchers. No problem, since IIL offers to watch sessions on-demand for additional 90 days. After my two-part review (part 1, part 2) of the highlights of the conference, here are lessons from Susan Parente focusing on project management.

Susan Parente shared the Agile Manifesto and Principles, before busting a series of myths around agile, like:

  • Agile is better for all projects. No, it’s suitable for complex product development, where inspect & adapt based on empiricism really can add value.
  • Agile is new and better. No, it’s been around since the 90’s, with much older foundations. Review Jeff Sutherland‘s explanation of Scrum’s foundations for example. And always better? It depends.
  • Agile is faster. It depends.
  • Agile is unstructured. No, it’s structured.
  • Agile doesn’t have documentation. Read the manual.
  • Agile doesn’t need requirements. How to deliver working software without?
  • The agile team gets to do what they want. No, the product owner determines what the team develops. How the team does it, is up to the team…….but within the organization’s standards, safety procedures, legal procedures, etc.
  • Agile is easy. No, lightweight, but difficult to implement.

Agile is not:

  • The solution to all project management problems.
  • A set of tools to be used as needed.
  • The replacement for traditional project management processes.
  • One specific method for projects to use.
  • A reason not to collect requirements and understand customer needs.
  • A way to complete projects without following processes.

Agile principles and practices are used to:

  • Manage change.
  • Improve communication.
  • Reduce costs.
  • Increase efficiency.
  • Provide value to customers and stakeholders.
  • Decrease project risks.

When to consider an Agile approach?

Consider using an Agile approach when one or more of these conditions are applicable:

  • Uncertainty, particularly in requirements and changing conditions.
  • Complexity of content, integration, stakeholder management, solution.
  • Innovation using new technology, content or system.
  • Urgency, a high priority project with a short timeline.

Agile projects characteristics compared to traditional projects

  • Rolling wave planning instead of a detailed planning for a whole project, or at least a stage (PRINCE2) ahead.
  • Iterative and incremental delivery versus delivery of end products only, not being said that traditional projects have big bang implementations only, because that’s nonsense.
  • Rapid and flexible response to change instead of a well-guarded scope and strict change procedures meant to keep out as much of the change to the initial scope and protect the team from changes.
  • Open communication versus a tendency to siloed operations and communications. Transparent, daily reporting by the team itself versus the less frequent reporting by the project manager.
  • Work delivered to customers in small, frequent releases versus less frequent (e.g. quarterly to yearly) larger releases.
  • More power to the teams themselves. Although self-management or self-organization doesn’t happen overnight, Agile projects really relieve the project manager of much of the micro-management he may have been doing in a traditional project management approach.
  • Costs and Time are fixed, while functionality or scope is flexible compared to a fixed scope with either costs or time fixed as well.

Emphasizing frequent meetings, including reviews or retrospectives, or focusing on deliverables instead of documents is not as specific to Agile projects as one states in presentations like these. Techniques such as a Daily stand-up, visualized planning, open spaces, strong interaction with the customers, product based planning and a check on the usefulness of documents and procedures plus a willingness to constantly improve, are good practices not ‘owned’ by Agile or dismissed in traditional projects.

I don’t agree with ‘plan driven’ as characterization of the traditional project process, and ‘value driven’ belonging to Agile or adaptive project processes.

There is no best approach

There is no one method which is best for all projects. Much depends on the culture, environment, and processes of the organization. Agile requires a change to the IT culture.

Related articles