For years, organizations struggling with Agile adoptions have been lost in a maze of frameworks, methodologies, tools, processes, certifications, and a zillion other things. In our work as Agile consultants, we have witnessed many practices that are implemented and followed incorrectly, at all levels of the Agile transformation journey.
The biggest challenge organizations face while starting an Agile transformation is not the learning, but the unlearning. There is so much information about Agile, Scrum, Kanban, XP, and other practices that individuals and teams end up “cooking their own crystal meth” that is often not up to the Heisenberg (aka Walter White) purity standard. This heady concoction, learned and adopted from all possible sources, creates an unruly puzzle of practices, which end up doing more harm than good.
This is why organizations must conduct an assessment of their existing state of Agile adoptions or process excellence (if Agile is not being practiced). This assessment, followed by context-setting sessions for leadership and teams, is the most important element for bringing structure to an Agile adoption. In this Advisor, we focus on Agile anti-patterns around roles, events, artifacts, and overall cultural mindset. We discuss how to identify anti-patterns and how to solve them. Let’s start by dissecting each of these aspects of Agile/Scrum, along with their harmful anti-patterns, one by one.
Remember, This Is Nothing New
First, we need to understand that Agile is not new. It’s a culmination of various process excellence models going back to iterative and incremental design and development, pioneered by W. Edwards Deming. Lean, Kanban, the spiral model, rapid prototyping, rapid application development, the Rational Unified Process, Scrum, XP, feature-driven development, and other frameworks and methods are part of this continuum, culminating in the Agile Manifesto, published in 2001.
Additionally, Agile is not equal to Scrum or any other framework or tool, or any scaling framework. It’s not tied to a particular framework. Agile is an intent; a cultural shift away from a closed, hierarchical, gated, black-box way of doing things. That is all.
Scrum masters take their role very literally. However, a scrum master is not a master of Scrum. Individuals in this role need to realize that Scrum may not be the answer to all of the team’s problems and that their role goes beyond extolling the virtues of Scrum. They are there to remove impediments, not book meetings, document minutes, or keep a check on time.
Scrum masters are also not there to win arguments, convert teams to their point of view, or manipulate individuals to agree with them. They should not view themselves as the final word on Agile or Scrum. Being neutral and data-driven are underrated traits in scrum masters. If the scrum master is not putting in effort to learn about the project’s impediments and does not have a problem-solving bent, he or she acts as a mere facilitator.
Scrum masters should avoid the blame game. Blaming team members, project offices, leadership, or the waterfall method for project missteps wins them no points. Aggressiveness, anxiety, poor listening skills, and intolerance to a different viewpoint are all poor traits for a good scrum master.
Most importantly, no one should become a scrum master to get into the power corridor. One must have conviction about the role, rather than chasing it as a career jump or path to a better pay package. Misunderstanding this role impacts the entire project and the team’s health.
No one should be made product owner just because he or she has spare time. Possessing an understanding of the role and what it entails should be a filter for selecting product owners. Someone who does not understand the client’s requirements and is not articulate enough to break them down and explain them to the development team is not a good product owner. A good product owner is not just a translator; he or she identifies value in the requirements.
A product owner is expected to get his or her hands dirty, work with the development team to write stories and get the backlog in place. If you are not careful when selecting a product owner, you may face an overconfident know-it-all who does not share requirements or validate stories.
A product owner should not only talk about business value; he or she needs to understand the technical aspect of the project and spend considerable time with the technical or solution architect. A product owner needs to understand the technical challenges that the teams face. Only then will he or she be able to be transparent with the client and give the client visibility into the project.
Additionally, product owners should be approachable, understand product vision, and be conscious of themes, epics, and prioritization in order to have a complete view of the project and avoid micromanagement.
Scrum ceremonies or events are often managed just like any other meeting. This should not be the case. Agile is all about a change in mindset, and these events should reflect that spirit.
Sprint planning should no longer be a work breakdown meeting but more of a scrum team’s collaborative event to create a valuable increment. Daily scrum meetings are more like status update meetings against the assigned work. In the daily meeting, the team members should focus on checking their sprint progress and moving toward achieving the sprint goal.
The sprint review often ends up being audits on planned items versus delivered items, while the focus should be more on collectively deciding if the team has created a meaningful outcome and what should be the next course of action. Teams are tired of playing repetitive sprint retrospective games, especially when the problems are still unsolved at the end of an hour. Sprint reviews should be for the team to talk to each other and figure out better ways to move forward. This will happen when team members begin trusting each other, share their thoughts without fear of judgment or retribution, and collectively identify items to improve upon.
We are Agile and hence need no documentation! Ever heard this? We come across this all the time. Agile does not mean no planning or no documentation. The team still has to do the homework, prepare thoroughly, and accept and embrace change. They cannot change the sprint backlog at will. Another common misconception is that the backlog contains only stories and any work item can go into the backlog. Placing too much emphasis on finishing the stories and tasks may increase velocity, but it will not improve the overall product quality. Instead, teams should focus on creating an evolving and integrated increment.
To succeed, organizations need to realize that they should fix two constraints of the iron triangle, while keeping the third one flexible for the Agile way of working. Generally, time and cost are fixed, and scope is the one constraint that can be negotiated. Fixing all three is a recipe for failure.
A burndown chart is one of the most popular metrics during a sprint. It looks like a walk on flat land until the last day, followed by a steep fall. Teams need to realize that the key word in managing burndown charts is continuous. Work items need to be continuously pulled out from the “to do” list and moved to the “done” list throughout the sprint. There are many reasons why we see burndown charts flat till the last day of sprint and then a sudden fall. A few examples include individual work assignments, pulling bigger work items, giving work to quality assurance only at the end of the sprint, and a lack of quality consciousness.
Measuring velocity is one of the most effective metrics, although admittedly an annoying one. It is effective because it is derived from the stories that are marked “done” and illustrates the team’s maturity toward the quantum of work they can finish in the form of an increment. Usually, the velocity is averaged with the last few sprints and can be used to predict the release completion timeline. However, it becomes annoying when management expects the velocity to increase continuously in every sprint, citing the “learning curve,” and pushes the team to deliver more by questioning their sprint commitments. The team also faces the wrath of leadership when they can’t keep up with the velocity “golden” number. This further leads to a manipulation of numbers. If the story points and velocity are still being confused in your system after a couple of months, it is time for you to let it go.
The Agile transformation journey of an organization is never-ending. It is a continuous process, and there are new challenges thrown in at each stage. As Agile anti-patterns are solved, new ones knock on the door — this is a good thing! Stability is not equal to staleness, evolution is key, and organizations must keep asking, “What is next?”