25 Nov, 2020
7 Myths About Agile
The Agile revolution has been one of the most important and substantive developments in how we think about work and management for decades. It is likely to become the defining management principle of the digital age.
But it is also becoming a buzzword; the conversation around Agile is strewn with lazy generalisations and mischaracterisations which can make it difficult to fully understand its utility or grasp its benefits. If we want to unlock the full potential of Agile, we’re going to need to cut through the noise and bust some myths about Agile.
Myth 1: Agile Is Only For Software Development
It is true that Agile began life as an approach to software development, and the principle remains strongly associated with the tech sector in the minds of many. But Agile has come a long way, and the values and principles that underpin it are now being applied successfully in many business environments. From marketing teams to organisational transformation, and even senior leadership looking to responsively manage their teams. If you have a project with a high degree of uniqueness and complexity it is well suited to Agile.
Myth 2: Agile Isn’t For Highly Regulated Environments
Thanks perhaps to Agile’s association with the “move fast and break things” culture of Silicon Valley, there is a perception that Agile represents a trade-off: speed to market in exchange for project stability or operational safety. This association has significantly slowed the uptake of Agile processes within organisations that operate in highly regulated environments like oil and gas or pharma.
However, we have found that, when correctly applied, Agile methodologies can help improve operational safety. Chaucer recently worked with one client to implement an Agile methodology on a drilling project within the oil and gas sector. Because the agile methodology we implemented included interdisciplinary teams, rapid reporting and iteration, communication was improved and problems which previously might have developed into safety concerns were identified earlier and resolved or mitigated against before they posted any risk.
A well designed and implemented Agile methodology can improve almost any set of desired outcomes, providing they are well understood and integrated at the outset.
Myth 3: Agile = Scrum
People often use the expression “We are doing agile” when what they really mean is “We are doing Scrum”. Agile and Scrum are not the same thing.
Scrum is a framework and process in which teams can develop and manage work. Agile is much bigger that, representing a mindset with an attendant set of values and principles. While Scrum as a methodology falls under the Agile umbrella, it is one among many. Moreover, simply implementing Scrum does not necessarily mean you are agile. To be truly agile, teams must also adopt the Agile mindset.
Another, related myth I hear is that Agile work needs to be ordered into Sprints. There are plenty of Agile methodologies which do not include Sprints. Kanban, for example, does not require “Sprinting”.
The more general principle here is that the purpose of Agile is to maximise the velocity of the work and the team’s efficiency. The world of Agile is far more varied, and far less dogmatic, than it may appear from the outside.
Myth 4: Agile Can’t Be Scaled
It is true that Agile methodologies tend to work best when implemented in small teams. But this doesn’t mean that it won’t work for larger organisations. It simply means that it is best to start small and then scale the implementation of Agile across the wider organisation.
As we have said before, Agile is a mindset, consisting of a specific set of values and principles. Therefore, implementing Agile at scale is primarily about culture change, and this cannot happen all at once within large organisations. However, if you start from small teams where feedback can be received quickly, monitor engagement and better understand the culture you are trying to change, you can then quickly apply these insights to the next team. By repeating this process with sufficient teams, the organisation can achieve critical momentum where Agile principles and ways of working begin to spread organically and, in time, develop into a truly Agile Organisation.
Myth 5: Agile Has No Governance
Given the typically fast-paced nature of Agile projects, there is a perception that no governance is involved at all. For some organisations coming from Waterfall, the absence of familiar governance structures like stage-gates, committee meetings or forums can feel like a lack of governance full stop.
However, Agile methodologies do have similar governance structures in place, but simply approach them differently. Instead of having committee meetings, Agile teams might get all those involved in those traditional meetings to be involved in the sprint planning and sprint review meetings to highlight what is going to be worked on, and then what was actually delivered. If any decisions or questions need to be raised or points require clarification, then they can be done then and there, without the need for creating additional material or re-work for team members.
Agile typically decentralises some aspects of governance, ensuring decisions are made by those with the best information. But the Agile principle of transparency of information ensures that stakeholders and sponsors can exercise oversight to whatever degree they want, whenever they wish to do so.
Myth 6: There Is No Documentation With Agile
Because Agile methodologies will typically forgo the Red/Amber/Green or Delivery Confidence Assessments that people are used to seeing in Waterfall projects, people can mistakenly believe that “Agile doesn’t do documentation”. This is not true.
Indeed, where RAG statuses are highly dependent on the subjective perception of a single programme or project manager, documentation within Agile is not just more responsive, but more objective. Measures like Sprint Cadence, Sprint Velocity and Sprint Burndown are underpinned by real and tangible data and complemented by value drivers derived directly from end user validation and engagement. Additionally, feedback ensures the team understands whether what they are delivering is adding value, is the right thing or is a worthwhile spend of money and time on. Real-time, in-situ documentation is arguably one of Agiles greatest strengths.
Myth 7: Agile Doesn’t Do Planning
There is a common misconception with Agile that it involves minimal planning. This is fairly unsurprising, the core distinction between Waterfall and Agile methodologies tends to be discussed in terms of their relative approaches to planning and execution. Waterfall is associated with meticulous upfront planning and sequential execution, Agile is associated with continual feedback and adaptation and parallel execution.
But while Agile projects may be somewhat less pre-determined than Waterfall projects, the total amount of time dedicated to planning is similar. The only difference is that planning is done more frequently and focuses on smaller horizons. If using Scrum as a delivery method and operating in sprints, at the beginning of each time boxed period, there is a planning session involving the whole team in order to understand priorities for that upcoming sprint, and ensuring what they want to get delivered, can actually be delivered by the team on the ground.
In addition to this, teams will usually go through backlog refinement or backlog grooming sessions. This is planning in advance of the planning, but it is used to ensure that what is on the backlog or in scope for subsequent sprints is still relevant, makes sense to those involved, and has been prioritised to ensure the items at the top of the backlog are most important to achieve the product vision.
As we hope is clear, every Agile journey is different and Agile methodologies are more flexible and more robust than they are given credit for. At Chaucer, we have helped teams and organisations of all sizes across many different industries implement Agile effectively. If you have any questions about how Agile can help your organisation, we are happy to help. Please contact us at info@chaucer.com
This article was co written by Todd Bennett & Donatela Salaj
Contact us: info@chaucer.com