Busting Agile Myths
Recently our Agile Community of Practice met to tackle some common agile myths together. This topic had come out of previous COP’s and the session proved to be a very enjoyable and engaging discussion, one that I would definitely recommend to other agile shops! So what were the myths that came out of the discussion and how did we tackle them?
There is a lot of information available online about Agile myths, and for our session we sought to pull together the top 8 myths we hear within our own government context. They are as follows:
Myth #1 — Agile is just a new fad
The truth is that Agile is not new, and not a fad. Agile has actually been around for twenty years. It started in the Spring of 2000, when a group of 17 software developers met to discuss how they could speed up development times to bring new software to market faster. A year later, the Agile Manifesto was created including the four values.
Myth #2 — Agile is just for software development
While it’s true that Agile was originally developed for software development, it has continued to be effectively adapted to different fields, including HR, Policy, Communications, Finance, Healthcare and Education. Agile provides a flexible set of values and principles that can guide any team to be more customer focused, iterative and incremental in their approach, and more flexible and adaptive to change.
Myth #3 — Agile is a methodology
We read and hear this a lot, but really, a methodology describes a very prescriptive, strict process that must be followed in order to be successful and in this sense Agile is not a methodology. Agile is truly a mindset, and we advocate for this fact in all of our foundational training. Agile offers a set of guiding values and principles through the Manifesto. And we see different teams and organization adopting very different frameworks (think Kanban, Scrum, Extreme Programming (XP)) and adapting those frameworks to their own ways of working, under the guidance of these agile values and principles. One size definitely does not fit all!
Myth #4- Agile equals Scrum
We see this a lot, that teams equate running Scrum to being agile. But what if Scrum doesn’t suit your team’s way of working, does that mean you can’t be agile? Definitely not! Scrum is just one framework that supports an agile way of working. It is the most popular framework because it offers clear roles, events and artifacts to support teams in demonstrating their agility- by focusing on the power of teams, satisfying the primary customer through early and continuous delivery of value. BUT there are other frameworks available (Kanban, XP, etc.) that may be more suitable to the work of your particular team, and teams can also start to be more agile by simply seeking to apply the values and principles of the manifesto in their work.
Myth #5- Agile will make us faster
The discussion around this myth was very engaged! It’s true that many teams seek to adopt agility to make them tackle more work faster. In our training we use the quote from Forbes that says “Agile is not about doing more work in less time: it’s about generating more [customer] value with less work”. So agile does not make a team deliver a higher volume of work in less time, instead, it allows teams to deliver more value to their customer with less work and in a shorter timeframe. It’s also important to note that one of the major benefits of agile is decreasing risk and eliminating waste, because agility ensures that we can adapt early if we’re heading down the wrong path.
Myth #6 — Agile means no documentation
Myth #6 provided the opportunity for more engaged discussion from our COP members! It was acknowledged that this myth probably comes from the second value of the manifesto “Agile teams value working software over comprehensive documentation”. But agile is not anti-documentation, instead agile discourages teams from creating documentation just for the sake of having it. So while there may be value to a certain amount of documentation, it’s more important to deliver working product to our customers than having lots of detailed documentation upfront.
Myth #7 — You need a fully dedicated Product Owner in Scrum
Myth #7 is no myth at all. One of the greatest risks to the success of a Scrum team is an unavailable or absent Product Owner. This is not a job that should be done on the side of someone’s desk. Successful Scrum teams have a Product Owner who is actively engaging with the customer and stakeholders, as well as with the Scrum team. The reality, especially within government, is that many Product Owners are asked to wear multiple hats and can struggle to give the role of Product Owner the attention it really needs.
Myth #8 — Agile endorses “good enough” which really means “poor quality”
For this myth, we took some time to dissect the quality pyramid created by Gojko Adzic (https://gojko.net/2012/05/08/redefining-software-quality) Agile teams are certainly concerned with quality, and work to ensure that they are investing their time and energy to deliver high quality and ensure successful outcomes. The best agile teams demonstrate quality at all levels- answering in the affirmative all of the questions below:
· Does it work?
· Does it work well?
· Is it useable?
· Is it useful?
· Is it successful?
Ultimately, it’s up to the customer to validate that what has been delivered is high quality. And open communication about what the customer can expect is key, as at times, agile teams may deliver something to test that shouldn’t be considered the final product.
When we understand what the common myths around agility are, we’re better able to tackle them! This was a great session with our own Agile community! Feel free to use some or all of this information to put together a similar session for your own organization!
