Fact or fiction: 7 Agile myths busted
It seems like nowadays, every organisation is Agile, with exec teams and senior leadership citing Agile transformations and ‘working in an Agile’ way as their top priorities. But what does it mean for a team or company to actually be Agile? What are the common Agile myths and what does true Agile look like?
In this post, we separate fact from fiction and bust some of the most prevalent myths that plague the Agile process.
Myth #1: Agile is a methodology
Let’s start with probably the biggest myth of all. Agile is not a process or methodology. You can’t “Agile” a build. Rather, Agile is a mindset, a set of values and guiding principles that enable teams to deliver digital projects more effectively and quickly.
Just because you have a development team, stand-ups, or a visual board, doesn’t mean you are Agile. Agile is the mindset and attitude the team adopts to run their project development.
Myth #2: Agile = no documentation
False. While Waterfall project delivery (the process of finishing a phase of a project before progressing to the next) requires specific documentation such as a business case and risk profile upfront before the commencement of a project, it’s a misconception that Agile requires no documentation at all.
In Agile, the importance of having the right documentation is vital. Here, documentation is required at the end of each sprint or phase to ensure that:
- Customers’ needs are met
- Stakeholders’ needs are met
- Feedback is captured for later improvements
- Project performance and status can be reported to the necessary stakeholders and parties
So while having documentation is not as stringent as in other project delivery formats, it is still an important part of managing Agile teams.
Myth #3: There is no planning in Agile
Despite the iterative approach to Agile, this myth is also false.
Planning is a vital part of Agile’s success. However, as opposed to having all the planning done upfront, the planning in Agile takes place at each delivery phrase or sprint. High-level planning is completed at the beginning of a project or sprint and adjusts as new information is uncovered, when feedback or adjustments from customers or stakeholders filter through.
Examples of changes that could occur during the planning phase include adjustments in the priority of tasks, resolving project issues and risks, or being faced with a lack of resources.
Myth #4: User stories have one ‘right’ size
In Agile, it’s easy to think that every unit of work, also referred to as a user story, has a specific value associated with its delivery. This belief is false.
Each team and the team’s capability is different, therefore the estimated effort of a user story will vary from team to team. Two factors should be considered when estimating a story:
- That the effort of the story will take a reasonable amount of time to deliver (i.e. 2 or 3 weeks, not 12 months).
- That the user story delivers value, generally in dollar terms to the business.
Myth #5: Agile is a silver bullet
Simply because your team is Agile doesn’t necessarily mean your project will be successful. Are you delivering value to your customers? Are your stakeholders, business and tech teams onboard? With any project, a level of risk exists whether it’s your competitors, stakeholders, or changes in technology.
To avoid this, companies need to manage each project team member’s work-in-progress. Set clear expectations for what work can be accomplished in a given period to not over or under allocate resources. This requires the team to prioritise its work and accomplish the most critical tasks first.
Myth #6: Agile and Scrum are the same things
The Scrum iterative work method is very prescriptive. It has highly defined processes, roles, ceremonies and artefacts. Scrum teams work through an iterative process, towards a common goal within a defined timeframe, known as a sprint.
Scrum is the process in which teams can develop and manage work, whereas Agile is the mindset and value that projects can adopt. Agile does not need to follow any methodology. Scrum falls under the umbrella or Agile’s values and principles. Other forms of Agile include Lean Kanban, Extreme Programming (XP), and Future-Driven Development.
Myth #7: Agile is easy
Understanding and implementing any change is hard. Transitioning a team’s mindset and values is not something that happens overnight. To reap the full benefits of Agile, project teams must learn the principles of Agile and adopt its values through best practices.
Important aspects for teams to consider include governance structures, roles and responsibilities, timeframes, and measures of success. For teams with little to no experience, a good way to begin implementing Agile is through running a small project, before moving towards something larger.
Learn how you can adopt the Agile mindset and values to elevate your team’s effectiveness with our Agile course.