I’m a Project Management Professional (PMP)®! Why Do I Need Agile?

I’m a Project Management Professional (PMP)®! Why Do I Need Agile?

By Kellie Morrell   |   Agilist, PMI-ACP & PMP, CSM, CSP, AHF, AFC, ICAgile ICP and ATF
Enterprise Agile Coach and Trainer, Agile Transformation Inc.

That was my question 9 years ago.  I had earned my PMP® certification in 2002 and was proud of it.  I had been somewhat successful in managing my projects; or least the ones where the clients did not change their requirements every other day.  So why would I need to learn something new?

My reason was very simple…my Senior Management asked me to pilot Agile for the organization. My first step was to find out what ‘Agile’ meant since I didn’t have a clue.

Agile Education

I attended a “Real World Agile” course by Agile Transformation, Inc. They also provided me with an Agile Coach. I learned that Agile was just another ‘tool’ in the project management ‘tool box.’  My Trainer and Coach helped me learn the basics of Agile.


The Main Agile Roles

  1. Product Owner – Business Owner that sets the business vision and priorities of the work. They also accept and/or reject the work the Team does.
  2. Team Members – Developers, Analysts, Testers, Subject Matter Experts (SMEs), etc.
  3. ScrumMaster – Agile Project Manager who facilitates the Agile process and meetings. They also are focused on the Team’s health and removing any impediments or roadblocks the Team may have.  This was my new role.

The Main Artifacts

  1. Product Backlog – Requirements log in highest priority.
  2. Sprint or Iteration – A timebox of 2-4 weeks where the team designs, codes, and tests and the Team could potentially move to production.
  3. Sprint Backlog – Requirements log of work to be completed in the 2-4 week Sprint.
  4. Burndown Chart – Daily progress of the team burning down their hours to the end of the sprint. Show roadblocks early.

The Main Meetings/Ceremonies

  1. Sprint Planning – What work the team wants to commit to getting done in the next sprint (2-4 weeks).
  2. Daily Scrum or Stand Up Meetings – A 15-minute meeting where you stand up and answer 3 questions.
    • What work did you get done yesterday?
    • What work are you going to commit to get done today?
    • Do you have any impediments?
  3. Sprint Review/Demo – The Team shows the work they have completed to Stakeholders and get their feedback. Time to celebrate as well.
  4. Sprint Retrospective – We called these ‘Lessons Learned’ meetings in Traditional project management and took place at the end of the project. These are completed each sprint and answer these 2 questions.
    • What did we do well this sprint?
    • What could we improve upon for next sprint?
  5. Agile embraces continuous improvement. The team would select 1-2 items from the Retro list that they want to get better at next sprint.

Want to expand your agile & scrum knowledge? Check out our 3rd annual Agile & Scrum Conference here.

How I Made the Transition from PMP to Agile

Agile is not all that different than Traditional project management. The big change is the focus on People and Value Delivered versus the project management process. In Traditional project management, I always had an Initiation Phase and a Planning Phase. So does Agile. At the end of my Traditional projects, I always had a Release into Production. So does Agile. The big difference is the iterative planning and the iterative development. Agile project teams have a Closing Phase for the project work but continue on the next highest priority project. Their closing phase is really a few stories and, of course, a celebration.

The big difference in Traditional and Agile is the iterative planning and development. This took me about 3 months to really learn how to break down the large work efforts (epics) into smaller chunks so we could deliver during our 2-week sprints.  I finally learned that the smaller the chunk of work, the better we can understand it, design it, code it, test it, and deliver something valuable that we could get quick feedback on.


Hardest Lessons Learned

  1. I was surprised to learn that Agile aligns with A Guide to the Project Management Body of Knowledge (PMBOK® Guide)—Fifth Edition (2013)
  2. I was also surprised at how many other PMPs were doing Agile.
  3. I learned the pros of Traditional Project Management:
    • Structured management
    • Budget and schedule predictability
    • Easy to scale
    • Skills Specialization
    • Documentation = knowledge transferability
    • Familiarity – often part of organizational culture
    • Structural support from other departments
  4. I also learned the pros of Agile:
    • Early and continuous delivery
    • More flexibility
    • More certain to deliver what the customer wants
    • Less defects in the final product
    • Higher visibility with frequent validation and transparent reporting
    • Increased estimating accuracy
    • More customer interaction
    • Improved team morale


Advice for Us “PMPers” Making the Transition to Agile

  1. “You can use all Agile some of the time and some Agile all of the time.” So try it.
  2. Allow yourself time to adjust to the new terminology, roles, process, and iterative development. It took me about 3 months before I began to feel comfortable with the framework and ceremonies.


Just like a good carpenter, you must know what tool will work the best depending on the job you need to do. Sometimes you will need a hammer; other times it will be an electric drill. The key is to know how both work, so you can select the best project management practices for your Project/Program and your Culture. In the end, what is really important is your organization’s Enterprise Business Agility. The method or framework you select will depend on the project.

Whether a PMP or Agile Certified Practitioner (PMI-ACP)®, our job is to facilitate the projects/programs, drive innovation in our organization, and keep up with the market and competition. Having both Agile and Traditional project management knowledge and experience will make you a better project manager. And you will have a few extra “tools in your PM tool box.”

Want to improve your Agile skills? We can help. Learn more about IIL’s Agile and Scrum courses.

PMP, PMBOK and PMI-ACP are marks of the Project Management Institute, Inc.

Comments (5)

  • Demosthenes

    Very interesting, but if you think about it, we’ve been doing what they now call Agile for many years. It’s not new. Its not revolutionary. Someone just put a capitol letter in front of a buzzword and marketed it. At one stage of the evolution or IT Project Management we called this prototyping. It was exceptionally successful when a customer had an idea of what they needed (needs) but weren’t sure what they wanted (wants and wishes). A good PM leads the customer to a reasonable solution that meets their needs but didn’t break the bank.

  • steve reynolds

    Excellent overview of scrum, but remember that it’s only one agile methodology and there are several. Kanban, XP, and AUP are a few other methodologies and there are more. For software dev, scrum seems to me to be most popular these days. For operational and infrastructure teams, I’d recommend checking out Kanban instead as it may prove difficult to get a hardware vendor to adhere to a scrum sprint. For larger organizations, Scaled Agile Frameworks (SAFe) is very interesting. We’re adapting a version at the company I work for.

  • gmartin

    Thanks – I found this article interesting and enlightening. I am still on my journey of trying to determine how to apply Agile methodology to Product Development Projects (not software). Anyone have idea of how long sprints can or should be for a typical 3-5 year total development cycle? With the final deliverable being a fairly complex consumer product. Two weeks is not enough to make meaningful progress, so is 6 to 8 weeks sound reasonable? Or longer based on typical lead-times to make parts (in-house or purchased). So, a potential iteration would look like this: Design, Review, Release, Procure, Build, Test, Lessons Learned, repeat.

    • Jeff Totten

      I am working on the same thing – integrating agile into our current stage gate system for non-software related products (something we design, tool, then manufacture). I am also completing my PhD work with a dissertation on agile in non-software related industries. It is an interesting blend.

  • Jeff Totten

    Great article. As I mentioned in my comment to gmartin, we are building agile methods into our current stage gate process. It works well for some phases (like design), but not so much for others (like tooling). So, your comment about using the best from both is valid. I will be sending-out a survey very soon to collect information on how non-software related companies are integrating agile into their processes.

Leave Comment