13 Myths About Agile Project Management

Although I have used the word myth in the title of this post, it is not quite the correct term to be using. Why? Because the word myth implies a supernatural element and AgilePM is not a supernatural concept.  So, I am going to use the word misconception throughout rather than myth and there are 13 of these misconceptions about AgilePM that need to be addressed.

 

Myth 1: Agile practices are new

The agile way of working has been around since the 1930’s (if not before) when physicist Walter Shewhart began using iterative cycles to improve products and processes. In 1957 Agile was developed as a software development methodology (See post:  What is Agile Project Management?).  In 2000, software developers met in Oregon to talk about how they could improve development times to bring software to the market faster.  As a result of this meeting, The Manifesto for Agile Software Development was published in 2001.  In 2010, AgilePM was introduced and increasingly is being used in many development projects, not just software development.  So, in terms of Agile being new as a project managing mindset, yes, you could say it is new.  As a mindset, however, the agile way of learning by experience (empiricism) has been around for centuries.

Myth 2: Agile PM requires no planning

Although less visible perhaps, than planning in a waterfall project, there is a great deal of planning in an Agile project.  It is not all carried out at the beginning as with waterfall methods.  Agile plans are made iteratively; developed and adjusted at various stages throughout the project life cycle. On-going planning of this nature allows for flexibility as adjustments can be made and changes allowed for as the project progresses. 

High level planning takes place at the beginning of an Agile project and is elaborated on throughout.  You must “plan to sensible horizons” (Tony Perks 2021), so, AgilePM plans iteratively, as the project progresses, rather than the whole project being planned at the very start.  Below is a general list of plans that are made before and during an Agile project.

1. Pre-Project: Sponsor plans feasibility of the project.
2. Start delivery plan and foundations
3. Delivery Planning split into potentially deployable releases called increments
4. Evolutionary Development is the area where timeboxes are planned
5. Plans are made initially for one timebox at a time, rather than the project as a whole.
6. Solution Development team/s plan their own work and update those plans in daily stand ups
7. Deployment plan activities are added to delivery plan

In some ways it could be said that once an Agile project is successfully completed then AgilePM becomes a forward-planning mindset rather than requiring no planning at all.  Once completed the project is not forgotten, but rather a retrospective takes place to discuss what worked and what didn’t and what lessons can be learned for the next project; a fact that leads nicely on to the next misconception: there is no documentation with Agile.

Myth 3: No Documentation with Agile

In some ways, the idea that there is no documentation in Agile project management suggests a supernatural element and may loosely be referred to as myth.  Who or what is it that keeps track of progress? Budget? Scale? Communication, etc., if nothing is documented?  A spirit perhaps that somehow miraculously makes visible the necessary documentation as and when required?  No; documentation is needed in an Agile project, but again it is only produced as and when necessary. The creation of documentation records and supports the progress and development of the product and is needed for communications between all who have a vested interest in it.

I might use the word misinterpretation here. It is possible that this ‘myth’ may have been derived from the misinterpretation of two of the values found in the Agile Manifesto: AgilePM values “working software over comprehensive documentation” and “prefers face-to-face communication”.  Whilst this sentence is true, there is still a need for documentation.

Myth 4: No Governance 

Another misconception is that there is no governance in AgilePM. Without governance though, how could the team know what the customer requires?  If they don’t know what the requirements are, how can they successfully fulfil them?  A team needs parameters to work within.  It is true that each member of the Agile team enjoys autonomy over decisions that are to be made concerning how the requirements of the user will be met, but governance dictates those requirements. 

As well as setting parameters for the team to work within, there also needs to be a clearly defined and efficient governance process for decision-making that occurs outside of the team environment.  The idea being that the team concentrate solely on the development of the product whilst others who have a vested interest in the project take care of all the rest of the decision-making.  So, contrary to the misconception mentioned, the success of an Agile project relies on a clearly defined and speedy project governance process.

Myth 5: Agile is Undisciplined

This is a very unfair misconception.  There needs to be a high degree of discipline within an Agile team.  Constant developing and testing of the product build at every stage requires coordination, skill and collaborative abilities.  The consistent delivery of quality product increments (potentially deployable features) highlighting the functionality of the product within short time frames allows the provision of value to the organisation and customer alike.  The team are disciplined and therefore trusted to make rapid decisions and alterations to the product.  If they were undisciplined it goes without saying that the project would be unsuccessful. 

Myth 6: Employees get to do whatever they like

Again, this comes down to discipline.  As I just explained, Agile team members need to be disciplined and by no means do they get to do whatever they like.  AgilePM is a collaborative and iterative process.  Adaptations to the product are made based on communications between the team and any stakeholders, so they are ready to help each other achieve specific tasks and are always looking to gain new knowledge that increases the speed and quality of work achieved.  So, no employees cannot do whatever they like.

Myth 7: Agile and Scrum are the same

Agility is the ability to respond quickly to change and is the result of an agile mindset.  A mindset in turn, is the result of knowledge and experience; not just knowing the facts but being able to understand the logic behind them and being able to put them into practice.  So, AgilePM and Scrum are definitely not the same because Scrum is a framework that sits within the Agile mindset.  This mindset adheres to a set of values and principles that Scrum and other frameworks have adopted.  Scrum, like Agile, is also iterative and adaptive but it is a framework for developing the product and managing the work rather than the mindset that led to that way of agile managing.  To say that Agile PM and Scrum are the same, therefore, is truly a misconception.

Myth 8: Implementing Agile is easy

Hmmm, no it isn’t!  Teams new to Agile are probably used to the command-and-control type of project management.  They are used to being told what, when and how to do things.  To adopt the Agile way of working, however, means that team members need to become autonomous in development decision-making and to be more collaborative with each other, rather than running to their manager each time they encounter an issue.  It takes practice, commitment and governance.

For an organisation to try to adopt Agile without understanding what it means to work in an agile way would be to invite failure.  An Agile Coach would be necessary to support all concerned with the implementation, which won’t necessarily be easy.  Such a change is challenging and there will be many issues encountered during the transition, but with understanding, time and clear communication to employees it can be done successfully. 

Myth 9: Pure Agile is the answer

“Horses for courses” are the words that spring to mind when contemplating this misconception.  AgilePM will fit most projects but not all.  It can easily be employed alongside a more traditional waterfall approach, but as a stand-alone project management tool, it may not meet the needs of the organisation.  Introducing a new way of working to any organisation brings with it an element of risk.  So, Agile should be introduced only after careful consideration and informed decision-making with regards to business environment, development and deployment strategy. 

Myth 10: Agile is a methodology

A methodology Agile is not!  Methodology describes a step-by-step process that is strictly followed, such as a waterfall approach.  Methodology implies rigidity, but Agile, by its very nature is the opposite to rigid.  It is a mindset, as I explained earlier; a way of thinking acquired from understanding, knowledge and experience.  This mindset influences an agile way of working that may change and adapt through the project lifecycle.  If Agile were a methodology, then team members would complete each task rigidly according to the steps set out in the methodology.

Myth 11: Agile doesn’t work for projects with deadlines

Every project has a deadline to be met, so to say that Agile won’t work to a deadline is again a misconception. Customers will need to know when the whole project will be completed whether it be agile or waterfall in nature.  What the customer doesn’t need to know is the deadlines for the completion of each specific task, so an agile environment allows for minor deadlines to be altered. 

AgilePM employs the flexibility of MSCW (often known as MoSCoW). 

• Must complete within the timebox
• Should ideally complete within the timebox
• Could complete within the timebox
• Will complete but not during this timebox.

Agile does work for projects with deadlines, but its own deadlines, as I’ve said, can be altered and adapted accordingly.  Whilst the team should complete a specific task within a certain time, if it means reducing quality then it may not be completed until the next timebox.  So, Agile allows for flexibility but will meet the final deadline.

Myth 12: Agile only works for small companies/small projects

Another misconception!  It is true that Agile works best when implemented in small teams, but that doesn’t mean that it is only suitable for small companies or projects.  An Agile team is one that consists of small groups, each working on separate tasks relevant to the project.  They are cross-functional and collaborative; and in constant communication with each other as the product develops. 

Whilst one Agile team may not be adequate for larger companies or larger projects, that is not to say that several teams cannot be implemented and organised to work on it.  Each team would focus on a specific component of product functionality and build.  Collaboration and continuous daily communication between all teams then allows for consistent integration of each component.  So, contrary to the misconception that Agile only works for small companies and projects, in fact, a larger organisation working on larger projects may well find that they achieve better results with AgilePM.

Myth 13: AgilePM is for software development

It is true that originally, Agile was developed for the software industry.  Also, admittedly the Agile Manifesto is set in the same software context.  However, AgilePM is increasingly being used outside of the software industry; its values and principles being applicable to most if not all business environments.  So, no, AgilePM is no longer software development specific, but quite the opposite.

To sum up

We have looked at 13 AgilePM myths, misconceptions or misinterpretations, whichever you choose to think of them as and I have explained why they simply are not true.  That Agile is accused of needing no plans, governance, documentation or discipline is unrealistic if not unfair.  Agile or otherwise, every project needs all these things if it is to be successful and deadlines are to be kept. 

The agility of Agile allows it to be used for many forms of projects both small and large and across all industries, but to say that it is a perfect fit for all is not quite accurate.  Careful consideration of factors such as business environment and nature of the project need to be discussed in depth before deciding to implement Agile.  Implementation will not be an easy process and will require time for the organisation to learn and gain experience in the agile way of working. 

Finally, AgilePM is not the same as Scrum.  Scrum is a framework that fits within the agile mindset of values and principles.  They are two very different beasts although both operate iteratively, retrospectively and therefore empirically.