BUSTSING AGILE MYTHS

In my experience supporting organizations with learning and implementing the Agile practices of project management, I have seen many Agile myths stated as facts. The purpose of this blog is to bust the myths of why and how to implement Agile project management practices for your organization or your project.

In today’s world of fast-paced technology and continually changing requirements and project scope, the need for Agile Project Management has greatly increased. Responding to this demand, the PMI® (Project Management Institute) launched a new certification, the PMI Agile Certified Practitioner (PMI-ACP) ®. The result of this fastest growing PMI certification is the creation of a new space where Project Management and Agile Practices meet. This calls us to ask how we transition from traditional project management to Agile project management.

Is Agile a method to manage projects, a software coding method, or a set of process like traditional project management has, but new and improved…?

Agile is actually a set of principles! There are many Agile methods which use an Agile approach. Agile Principles and practices guide teams and product development (or other project work). Agile is a culture shift. It is a great solution for some types of projects. Agile supports open communication between teams, stakeholders and customers.

The following is the Top 10 List of Agile Myths and the reason why each is a myth:

10: Agile has NO Planning…

Wait… there is planning in Agile! In Agile we focus on ‘Inspection and Adaptation’. With this, there is lots of planning, but it is incremental. Agile planning may include the following: Product Planning Meeting, Sprint (or iteration) Planning Meeting, ad-hoc meeting, Daily Stand Up meeting, End of iteration Meeting, Product review/ demonstration Meeting, or Retrospective.

9: Agile has NO Documentation…

There is documentation in Agile? The documentation artifacts of Agile may include: The Product Backlog, The Sprint Backlog, Burn Charts, and/ or Task Board.

Here is an example of a Task Board which may be used for an Agile project.

8: There is No End to Development…

The myth is that when using Agile for development, you are never really done. In Agile done is often more explicitly defined, for example by using the Definition of Done (DoD). This is agreed upon by the team and customer to ensure that customer needs are met. There may be a number of Definitions of Done for a project, include:

  • DoD for a feature (story or product backlog item)
  • DoD for a Sprint (collection of features developed within a sprint)
  • DoD for a release (potentially shippable state)

7: There is NO Long-Term Planning…

The myth is that we don’t need to have a long-term plan, as we are doing Agile… right?

Actually we have long-term planning in Agile. It is called Release Planning. Please see below for an example of a release plan for a project. It summarizes the iterations and how they relate to major themes or topics for the project, or Epics (which are large user stories).

*Reference: Armstrong, J. (8/22/2016) Business Documents UK Retrieved from https://business-docs.co.uk/downloads/powerpoint-agile-release-plan-template/

 

6: Daily Standup & Solutions

Another myth is that the daily standup meeting is used for problem solving. If this meeting is used for problem solving, it will not likely be completed within the 15 minute time-box (hard stop), as designed. In this meeting each participant (team member) answers the following questions:

    • What have I completed that supports the iteration goal?
    • What I plan to do that supports the iteration goal?
    • What barriers are in my way of the work that I plan to do?

This meeting is Not for solving problems. If problems do come out of this meeting, they may be resolved in post standup meetings or other breakout meetings.

 

5: There are No Requirements Needed…

The myth is that we don’t need requirements when we are using Agile, as that is what Agile is about, right? That is NOT agility. All projects and products need requirements. How else will we know what works needs to be done to meet the customer requirements?

User Stories provide requirements in Agile project. Requirement in a user story are in the language of the user. They describe the need or function the customer would like. Stories are sized (or estimated). The following is an example format for a user story:

As a <type of user>,

I want to <do something>,

so that <some value is created>.

 

4: There is No Focus on Quality

The myth is that with Agile you get what you get (denoting there is not focus on quality/ customer satisfaction). This is the opposite, as with Agile we are focused on providing value to the customer and meeting their highest priority requirements.

To support quality and continuous improvement of how the team works and the processes they use. We use iteration retrospectives. These allow the Team to continuously ‘Inspect and adapt’ the work they have done and how they have done it. Process improvement is the focus of the retrospective. The goal is to identify no more than 1-2 strategic changes for the next iteration.

 

3: Agile is Faster

The myth is that we don’t have time to do traditional project management, so we will use Agile project management, because it is faster.

This is NOT Agility. Agile is time-boxed in iterations. Each iteration includes: Initiating, Planning, Executing, Monitoring & Controlling, and Closing. These are encompassed in the following: Iteration Plan-> Daily Work & Daily Scrum-> Iteration Review-> Iteration Retrospective

If a project has a clear, unchanging set of requirements it may actually take longer to complete it using an Agile approach, as opposed to a traditional approach.

 

2: Agile is Better!

One of my Agile project management course students actually stated this. They said, “Traditional project management is no longer needed, now that we have Agile! Why would we ever use traditional project management, now that we have Agile project management, which is clearly better.”

This is definitely a myth!  Agile is NOT the ‘Silver Bullet’. Agile does NOT solve every project problem you have. On the contrary, implementing Agile generally shows all the ways your project (or your organization) is not agile. Communication is a bigger problem with Agile and poor communication has a larger impact when using Agile project management. Lastly, Agile isn’t the best approach for all projects. It is best to use when a project has one or more of the following conditions:

  • Uncertainty
    • particularly in requirements and changing conditions
  • Complexity
    • content, integration, stakeholder mgmt., solution
  • Innovation
    • new technology, content or system
  • Urgent
    • high priority, short timeline

 

1: Agile Has No Structure

This is definitely a myth as Scrum (one of the most common Agile methods) has a very clearly defined structure.

The following picture describes Agile Scrum via its structure depicted in this image.

In conclusion, we see that these top 10 Agile myths are not the reality of Agile project management and we now see the value of Agile and where the Agile approach is the best fit. If you would like to learn more about Agile, please consider attending my class on Agile and Scrum Fundamentals or my free webinar on the PMI-ACP (Agile Certified Practitioner) Certification.   – Susan Parente, PMP, PMI-RMP, PMI-ACP, PSM I, CSM, CSPO, CISSP, CRISC, RESILIA, ITIL, MS Eng. Mgmt.