2 Quick Agile Myths- Busted?

Agile Projects don’t use Project Managers

It is true Scrum doesn’t discuss Project Managers – it focuses on the Product Owner, Scrum Master, and the Development Team. Scrum is only one implementation of the agile principles (albeit probably the most well-known). Even though Scrum doesn’t call out the role of Project Management in its literature, it never states that you can’t have one.

Project Managers typically have different responsibilities, such as budgeting, reporting, and portfolio management. These are all extremely important, especially in larger organizations, and experience project managers excel at these tasks. Project Managers are also a vital link in the communication and collaboration goals set forth in the agile values and principles. These project management tasks still need to be completed, and individuals who are trained and experienced in performing these activities best handle these tasks. In projects using Scrum, these tasks are often split up between the product owner and scrum master. Often in these projects, professionally trained project managers will take the scrum master role and then train the product owners on how to perform the appropriate activities.

Agile Projects are out of control

There is a common misconception that agile teams are free to do what they want, when they want, how they want. This can’t be farther from the truth. Successful Agile teams are self-managed, which is not the same as un-managed. They are in constant communication with the other team members, as well as those outside the team, and therefore completely transparent. Daily communication (such as daily standups), pair programming, and other team practices bring teams together into a cohesive unit. Couple with reviews of each sprint with stakeholders and the business makes the development team accountable for their actions.

Additionally, when teams are told what needs to be done (as opposed to what and how), successful agile teams will more often than not discover the best way to get done what needs to be done, finding efficiencies and optimizing resources.

Finally, Agile methodologies introduce cadences to the development routine to ensure that projects stay in-control. Every day, teams are verbally giving a state of the union in the standup, as well as updating the burndown charts and/or Kanban boards. Each iteration is capped off with a review where the team demonstrates the current state of the project to interested parties. As software is prepared for release, all of the variables that traditionally cause software projects to fail or be perceived to be a failure (such as developers that went dark, unrealistic expectations, poor communication, and many others) have been met head on long before the software gets deployed. There is an incredible level of control, since every step of the project has been communicated at a steady cadence to all interested parties.

Contrast that with traditional waterfall, where individual developers and teams can go weeks or even months without having to show any results. It’s these situations that can cause end of project surprises that can destroy a team’s reputation or even kill a project.

Want to find out all there is to Agile? 

In the 11 years since the Agile Manifesto was created, the adoption of agile concepts has continued to grow. This growth has been so significant that Gartner has declared that “agile is now mainstream”.

Along with this growth in adoption and exploration of agile, the number of agile myths has grown as well.

Find out the truth behind the top:

• Project Management/Process Myths
• Agile Software Engineering Myths
• Agile Startup Myths

Download the Top 30 Agile Myths- BUSTED ebook for free.