Fake Agile: 6 Ways to Sniff it Out
We discussed the Agile philosophy and its most popular framework – Scrum previously on our blog. We scoffed at how a radical idea, aimed to free creatives from bureaucratic shackles has become wrapped in jargon, doctrines, and certifications.
Agile frameworks have helped thousands of teams worldwide. According to the Project Management Institute, more than 70% of organizations use Agile methodology and Agile projects are 28% more successful than traditional projects.
But thousands of organizations also misinterpret Agile philosophy. Not realizing that Agile is more of a mindset change, they conveniently handpick a few suggestions from its many frameworks.
Agile frameworks without an Agile mindset do more harm than good.
Therefore, it’s important to know when a team that claims to be Agile isn’t one.
According to the State of Scrum report, 89% of teams that want to be Agile, use Scrum. Scrum is undoubtedly the most popular way for teams to embrace Agile philosophy. To smell fake Agile, you have to know how to smell fake Scrum.
How to do it? Watch out for these red flags:
1. Scrum Master is acting as a team lead
Scrum Master is the glue that holds the Scrum team together. They are the closest thing to a project manager in a Scrum team. They ensure that Scrum principles are upheld, but more importantly, the team feels supported.
When Scrum masters start dictating priorities, it’s the sign of a failed Scrum framework. Scrum teams are meant to be self-organizing. Scrum master neither tells the team what to do nor prepares the sprint backlog. Their job is to empower the team by being a servant leader. This means, ensuring that the team isn’t distracted and feels motivated.
Paulo Soto makes an interesting point in his post on Hexacta – “Since Scrum is not prescriptive, the Scrum Master shouldn’t be either”. Scrum Master shouldn’t enforce anything without the consent of the development team.
Another visible problem in many Scrum teams is that the Scrum Master serves as the only link between the development team and the Product Owner. This again stems from the misconception that Scrum Master is the team’s lead and sole representative.
Stefan Wolpers has come up with an ingenious test to see if your Scrum master is considered your Scrum team’s lead – In Sprint review, retro or planning meeting if your team members seek eye-contact with the Scrum Master before speaking, the Scrum Master has already left the facilitation role in favor of the supervisor mode.
2. Customer is never happy
There can’t be a bigger sign of fake agile. The core tenet of all agile frameworks is customer satisfaction. Everything else is an afterthought, including agility itself.
Many teams that want to be Agile, focus too much on its frameworks and technicalities. They focus on making their sprints more efficient, their team more motivated, their Product Owner happier. In the daily grind of on-ground Agile practices, they occasionally forget to involve the customer as often as they should. That’s why critics of Agile often refer to it as “doing the wrong thing righter.”
As mentioned before, none of the Agile frameworks are prescriptive, you can tweak them according to your customer requirements.
Despite your sincere adoption of Agile frameworks, if your customers aren’t happy, you are not Agile.
3. Sprint backlog never changes
In many Scrum teams, backlog changes during a sprint are frowned upon. This comes from a belief that to hit your sprint goal, you shouldn’t fiddle with its backlog.
This isn’t true. Agile philosophy is all about optimizing your process to accommodate changing requirements. That’s why the backlog items are called user stories and not tasks. These should be updated based on user feedback, a process that must continue during the sprint as well. If the Scrum team realizes that the scope of some user stories is bigger/smaller than the initial estimation, they should make necessary changes in the sprint backlog.
Stakeholders should understand that backlog changes during the sprint are completely normal. In fact, the reverse might be a cause of concern.
This doesn’t mean that a stagnant sprint backlog is harmful. If you’re able to do it occasionally, more power to you. That’s impeccable planning. But if it happens every sprint, there are fundamental issues with your Scrum implementation. It means you aren’t involving the user/customer in the process as much as you should.
4. There is no documentation
The agile manifesto talks about people over processes. It states that the team should value working software over comprehensive documentation. Some teams take it to the extreme – zero documentation.
Notice that the manifesto prioritizes people over processes. It neither hates processes nor approves of eliminating them completely. It seeks to reduce unnecessary documentation that plagues other project management methodologies such as Waterfall.
High performing Scrum teams document the insights from sprint planning, review, and retro meetings in a clear and concise manner. They also maintain technical documentation that’s useful for making internal functions smoother. What they seek to eliminate is documentation that’s of no critical importance.
Collaboration tools are popular with Scrum teams not only because they help with Agile frameworks but also because they make documentation easier and accessible to all.
5. Scrum team is too big
The Scrum Guide suggests having 5 – 11 people in the Scrum team, including the Scrum Master and Product Owner. This is also consistent with Jeff Bezos’ two-pizza rule, i.e. two pizzas should be able to feed the team over lunch. Even the armed forces recognize this. That’s why the smallest unit of an army (squad) has 7 – 14 members led by a sergeant.
You can’t effectively implement the Scrum framework with teams that exceed Scrum Guide’s recommendation. The process isn’t designed for big teams. Can you imagine a 20 person Scrum team in daily standups?
Unfortunately, a lot of organizations that wish to scale Scrum tend to forget this rule. It’s because implementing Scrum sometimes requires painstaking reorganization in teams.
6. “We have become Agile”
Agile is a journey, not a destination. One can’t tick all the boxes and call themselves Agile. It’s always a work in progress.
Reflection and a desire to become better is an important principle of the Agile manifesto. That’s why in Scrum, teams have sprint retrospectives in addition to sprint reviews. While reviews focus on the deliverables of the sprint, retrospectives aim to highlight what can be improved in future sprints. Scrum teams that combine reviews and retros fail to understand why they are so different from each other.
At the end of the day, Agile is an increasingly useful and necessary framework to stay competitive in local or global markets (with how fast everything is changing). If you use our 6 warning signs above to avoid falling into a buzzword echo chamber, you’ll be in a much better position to actually be agile!
Happy project managing! 🙂