Exploding 12 Myths of Agile
Most days I will hear a myth of Agile. Fortunately it is becoming less so, but it is useful to have the following ready as an answer to those that insist that one, or more, of the following are true.
This article is part of a series. Go to the Contents page.
1. Agile is new
The Agile Manifesto was published in 2001. This was based on previous work, over previous decades, with examples back to, for example, 1968 NATO conference on software engineering where once debate was closed with:
“Through successive repetitions of this process of interlaced testing and design the model ultimately becomes the software system itself. I think that it is the key of the approach that has been suggested, that there is no such question as testing things after the fact”
How about some statistics? Whilst there are many sources, the following is a good reflection.
- 93% of agile companies reported better customer satisfaction than the non-agile competition. (McKinsey 2020)
- 76% of agile companies reported better employee engagement than the non-agile competition. (McKinsey 2020)
- 93% of agile companies reported better operational performance than the non-agile competition. (McKinsey 2020)
- Agile Projects are 3X more likely to succeed than waterfall projects. And Waterfall projects are 2X more likely to fail. (Vitality Chicago 2020)
Agile is not new. The boat has sailed. If you’re not on-board, you are lagging behind.
2. Agile means having no documentation
Let’s be clear. You can have as much documentation as you like in Agile. The difference is that all documentation should bring value. If a customer is willing to pay for documentation, it has perceived value.
So it’s like anything else you deliver. Based on its value, its priority and the risk of not producing it, you schedule it in accordingly.
In reality, Agile probably means less documentation.
But documentation should not block progress. It should be created if needed, when it is needed. It should be enough to provide the value it warrants.
People can hide behind documentation — a conversation and collaboration is vital. This should never be forgotten.
3. Agile means “no design”
To “be Agile”, design is more of a constant activity. Probably producing more thought for design than traditional approaches.
When producing, for example, design documentation for an infrastructure build, consider what documentation you need and when. Do you need the complete document? Can you produce what you need so build can commence, and further detail added as you need it?
Because if that’s true, the customer will see actual value (built infrastructure) early, and in a repeatable manner. Or can you document as you build, spending more time on testing to create the final environment which you then document to the level required and expected?
So Agile encourages you to avoid the big up-front design, that as soon as deployment or coding commences is probably no longer accurate.
Embrace emergent design as design is omnipresent in Agile, and not just a long and tedious step at the start of the project.
4. Agile means no planning
“Oh, you do Agile, so I guess you don’t plan then.” Heard far too often. Agile actually involves probably more planning. Every iteration, arguably every day. Spread throughout the team.
Similar to design, which is where the myth comes from no doubt, is that there is no big design process at the start of the process — instead, it is continuous.
Traditional plans are hostages to fortune as they become quickly dated and require updating. We become slaves to the plan. Customers, sponsors, and other stakeholders hold plans against teams.
Take a plan that requires X to be delivered on a particular date. Any deviation from this plan may be seen by stakeholders, governance committees, and project management officers as a failure on the part the team, often against baselines.
But it is a failure of the plan itself, not the team.
And yes, we long term plan with Agile. Scaling Agile with Program Increment planning, or release plans. And strategic enterprise level planning at even longer intervals.
As focus gets closer to deliver, planning sessions are held more often with, for example, Sprint Planning in Scrum every iteration. As focus gets closer, a more fine grained level of planning occurs with more detail and a higher level of commitment.
So do we plan? Yes! All the time!
5. There is a right size for a user story
No. Every team is different — accept it.
The two basic rules I tend to use when sizing a user story are:
- A user story should be small enough to deliver quickly.
- It has value in its own right.
How large that user story is will depending on skills, knowledge and experience of the team. This will vary based on the individuals involved, and how they work as a team.
Whilst they might, please do not expect two different teams to size user stories the same.
You might argue that a user story should be delivered in one iteration. This is true with strict Scrum and would be rule 3 above in typical Agile Scrum projects, or indeed, replacing rule #1. If not viable in one iteration, it should be broken down.
My argument is that rule #1 would nearly always cover this guide from the framework. It is for the team to discuss, and exceptionally, the team may accept that a user story may take more than one iteration to complete, where breaking it down further generates more work then keeping it as it’s own single story.
6. You do what you like
Erm, no.
The Product backlog in Scrum for example, is a prioritised list of work. The Sprint backlog in Scrum, is a prioritised list of work for that iteration.
So the team will work from that list. In Scrum, the Product Owner will own and manage the Product Backlog, and every Sprint, the team along with the Product Owner and facilitated by the Scrum Master, will agree the achievable Sprint backlog.
Senior management can sometimes feel like people are doing what they want, but that is typically because they don’t understand Agile. It is a chance to educate them.
7. Agile doesn’t work for fixed deadlines
Quite the opposite — Agile works best with fixed deadlines. The deadlines harness focus, prioritising the work to achieve the most valuable outcome.
Indeed, Agile works best with fixed deadlines and fixed budget, with the scope being flexible, and work always being re-prioritised to welcome changes, continuously delivering value to the customer. Fixed cost is welcomed, because projects are often costed as wages multiplied by time.
This is the opposite of traditional projects, where the scope is fixed, and the plan is produced to show the cost and timeline. Literally up-side down.
An oft-used diagram to show the above is the “Inverted Agile Iron Triangle”:
Traditionally, scope is fixed, a plan is produced to show resources and duration, at the point in time the plan is produced. You become a slave to the plan. Any change is questioned. Change is bad.
With Agile, the preference is to timebox the project, with fixed resources and adapt — and welcome — change.
8. There is no governance in Agile
This myth is generated from a lack of understanding.
A project charter is typically drawn up to give the team guardrails within which to work. Why, What, When, Who, Where and How are typical headlines.
And then, if using Scrum for example, governance is part of the process at the start of the iteration (planning), every-single-day in stand-ups, and at the end of the iteration (review and retrospective).
Perhaps the difference is command-and-control of traditional project management, versus the empowerment of the team in Agile. The team is much more self-governing in Agile.
So is there governance in Agile? Hell yes! All the time. And in my experience, with peers governing each other, a lot more effective than traditional projects.
9. Agile has no discipline
Anyone who has been involved with Agile projects will testify that there is a lot of discipline. Team members need to be disciplined. Agile is collaborative and iterative, and all team members must be ready and willing to help each other achieve their goals.
The constant drive to produce valuable products within short time frames requires discipline, trust and rapid decisions. A lack of discipline would clearly lead to failure.
10. Agile and Scrum are the same
Argh! If I had a dollar, for every time I’ve had to politely educate people on this one!
Agility is the ability to respond quickly to change, as a result of an Agile mindset, developed as a result of knowledge and experience, and not just attending a course. This is “being Agile”.
It has 4 values. It has 12 principles. That is it.
Scrum is a framework created with the above in mind. It is a framework for developing a product and managing the work. It is “doing Agile” to enable you to “be Agile”.
11. Implement Agile is easy
This is a serious one. Many organisations will hear about Agile, picked on someone, perhaps sent them on a course, and then ask that poor soul to implement Agile.
Please don’t do this.
People are used to the command-and-control type of project management. They are used to being told what to do, and when, and probably how. Team members, in Agile, need to become more autonomous, and empowered to make decisions. They lean on each other, and make decisions as a team. There is not project manager to defer every decision to.
This can be scary!
It takes practice, commitment, facilitation and governance.
The organisation needs to truly understand what Agile means, both “being” and “doing”. An Agile coach is a highly recommended appointment.
Don’t convert the whole organisation in one big bang. Prove it works, and let the good news spread. Trust me, people will come to you asking to know more, and they will embrace the evidence. It’s a lot easier than trying to “sell” Agile to a skeptical audience!
12. Agile is only for software
Look, I get it. You’ve only got to browse agilemanifesto.org and see the word software.
So yes, it is true, that this is where it began. But its values and principles are now being used to deliver projects ranging from building bridges to marketing campaigns, from jet fighters to designing designer clothes.
When you read software, think solution.
Wrapping Up
There are many myths around Agile. I hope that this at least gives you some ammunition to use when you hear the above!
