Is using SCRUM being Agile? Does nobody want to go to your retrospectives? Is your Product Owner your team leader? These are some of the questions I hear when I accompany teams in the implementation of Agile as a way of working.
It's easy to form bad habits when we're adjusting to new ways of working. With that said, what I'd like share with you is the most common anti-patterns that I've detected throughout my experience as an Agile Coach, and how I recommend counteracting them.
Intro
SCRUM is a set of rules, procedures, events, artifacts and roles that aim to constantly generate value. As Jeff Sutherland says, it's "the rules of the game." These rules are flexible and—for this reason—on some occasions, they can be broken when you don't have adequate experience or understanding under your belt.
.png?width=604&name=Anti-Patrones%20de%20SCRUM%20(2).png)
Scrum is very easy to understand, but very difficult to apply. To understand it better, let's first settle on some definitions...
What's a pattern?
“Each pattern describes a problem that occurs over and over again in our environment and then describes the core of the solution to that problem; in such a way that you can use this solution one million times, without doing it the same way twice.”
- Christopher Alexander, A Pattern Language
As we can see in the previous definition, patterns serve us in providing solutions to recurring problems.
What's an anti-pattern?
Anti-patterns occur when we believe that the solution we are proposing to the problem seems to be the correct one and the easiest to implement, but ends up being a problem or causing more problems than it solves. Anti-patterns are hidden within best practices and appear to be part of the system.
Anti-patterns in SCRUM
From my experience, some of the anti-patterns I constantly see in teams and organisations are:
Believing that by using SCRUM we are being Agile
I constantly find organisations have been practicing SCRUM for several years and, therefore, believe that they are already being Agile (check out more about our own Agile Project Management and Agile Coaching approach here). However, a closer look into their team reveals they're stuck to the same traditional practices.
To make a real transition, it's necessary to reinforce the Agile mindset. Go back to the roots of the topic - the Agile manifesto. Embrace its four values and 12 principles.
It helps to visualise Agility as an umbrella under which we shelter practices and frameworks. If we only do the practices (and there are many) but we don't do them in line with the attached values and principles, we'll find ourselves in "fake Agile" territory.
In planning, the Product Owner assigns work to developers
It is very common that in planning, the product owners tell the developers how to do their work, failing to promote self-organization and commitment. I recommend that an experienced Scrum Master accompany the Product Owner to improve the understanding of the role. This helps empower developers.
The review becomes the event where the Product Owner validates the work of the “development team”
In SCRUM there are three roles: Scrum Master, Product Owner and Developers. These roles are part of a single team, and there are no sub-teams. However, I have on occasion witnessed a lack of Product Owners within SCRUM teams. Some Product Owners only go to the planning and reviews, but are not present during sprints, and sometimes only attend daily events to follow up.
My recommendation in this case is to make sure Product Owners are properly trained in their responsibilities, and who also—crucially—have ample time to fill the role.
The retrospective turns into a half-hour meeting that nobody wants to go to
When the purpose of an event or events is lost, they end up becoming situations that don't generate any value for the team attending. Teams may even feel like these events are robbing them of their time.
It's important in this case to have your Scrum Master look deeply at the purpose of these events. This only comes with experience. You might also support the role with an Agile Coach.
Product Owners take the role as the "head of the team"
Product owners who are the "heads of the team" are very common. This not only means an additional workload, but also promotes unnecessary hierarchy within the team. The group responds to the orders of their "boss", reducing the autonomy of developers.
To nip this in the bud, it's necessary to reinforce the Agile mindset amongst your team. Improve your Product Owners understanding of the role through training and mentoring.
Misunderstanding sprints
When companies are transitioning to Agile ways of working, they typically interpret product planning in sprints as the new Gantt chart, creating a hostile, repressive, and a deadline-at-all-costs environment. SCRUM is not for managing projects, it is for building products in an environment of uncertainty where other ways of working generate less value.
Again, I recommend reinforcing the Agile mindset amongst your team. You might first create product pilots, and learn from these pilots to adjust to the new culture.
Thinking SCRUM allows us to finish projects/products earlier
Do we use SCRUM to finish faster? Many companies assume this is the case. The truth is that SCRUM allows us to fail faster, evaluate faster, change course faster, abandon faster and create value faster. What's more, if this value is not subject to review, testing and scrutiny by our customers, it's not going to serve any purpose.
The SCRUM Master becomes the new Project Manager
The SCRUM Master is a role that we might misunderstand. Many times, teams believe that they do nothing - a free spirit who promotes happiness and wellbeing without taking any real action.
In reality, the purpose of the role is to help the team create value. For that, they must have a series of skills, competencies and knowledge at their disposal. The SCRUM Master must help the Product Owner find the best way to manage the list of needs of the product, teach the team to remove impediments, and cancel activities if they serve no purpose. They must facilitate different Agile rituals and help the organisation change its mindset from the ground up. Importantly, the SCRUM Master is not the one making decisions about the people, the product, the schedule, or the assignment of the pending work.
"We're a little short on time, let's extend the sprints 2 days"
When we are in a command and control environment, SCRUM teams can be forced to stretch the times of their sprints. This means that there is no consistent rhythm in the delivery of value, or in the inspection for the generation of value.
It's necessary to have that rhythm, to carry out inspection, and continuously highlight the different situations that aren't allowing us to finish on time.
"In this sprint we do the frontend, the next one the backend, and in the last one we test"
When we don't properly divide stories, we can end up building "Agile waterfall products." One of the purposes of splitting user stories is to be able to generate small product increments. It's useless to build screens that don't have full functionality, that are not useful for the user to validate flows. This also can happen with blocks built from the technical vision that the user cannot interact with. Long story short, if the user can't give feedback, you can't expect any reasonable improvement.
The best way to ameliorate this is to have complete small functionalities, built and improved in an evolutionary and incremental way. Our most experienced software development and UX/UI design teams wouldn't ever be able to make best use of their talents without the backbone of user feedback.
.png?width=431&name=Anti-Patrones%20de%20SCRUM%20(3).png)
Conclusion
I hope these solutions have offered some food for thought for teams out there that are integrating SCRUM. That said, I'm sure some readers also have their own tips, recommendations and anecdotes about Agile ways of working.
Feel free to drop our team a line about your own experiences. My team and I would love to chat more about good practices in the world of technology, innovation and Agility.
