4 Common Agile-Scrum Mistakes and Ways to Avoid Them

The hype surrounding the Agile Manifesto has compelled companies to take on their respective Agile journeys. But despite its simplicity, the Yellow Brick Road to Agile is a challenging one to travel on. Here we round up four of the most common Agile-Scrum mistakes that organizations encounter during the transition and ways to avoid them!

1. Transforming into Agile-Scrum Too Soon and Haphazardly

While it’s easy to cull your requirements into epics and user stories, reorganize meetings into daily stand-ups, and partition milestones in 2-3 week time boxes to conveniently call them sprints, the truth is it takes more than willingness to be able to completely and healthily transform your organization’s culture into Agile.

In my own experience, I worked for a now-defunct digital marketing agency which attempted to transition from no established dev methodology to Agile. At the get-go, it was easier to convert us to the Church of Agile-Scrum: we were all in one location, we juggled roles, and we were only a team of less than 20. All factors pointed in favor of a pure Agile orientation. Though this was true, I could still remember the trial-and-error affairs and the struggles as we moved the organization towards the Agile direction: the Product Owner maneuvers the project when uncertainty arises, the Scrum Master owned tasks, we forwent daily stand-ups, and many others. In a span of a year, we were able to complete 15 Agile-Scrum projects, but not without loads of hiccups.

What companies should bear in mind is that transforming to an Agile-Scrum culture is not a walk in the park. It will be chaotic at first. The problems that keep you from achieving an Agile environment are the same problems that fester in an organization even without an Agile Culture Transformation initiative – poor collaboration, bureaucracy, absence of quality management systems, inefficient communication channels, and lack of trust among team members.

There are many frameworks by which you can assess the readiness of your organization for an Agile environment. Any cultural change will be met by a powerful resisting force coming in all fronts. You have to accept these roadblocks as part of the territory. Treat the conversion as a project. Give it time and plan well!

2. An Uncommitted or Uninvolved Product Owner

Managers who will perform a Product Owner role must shed off their Project Manager skins and come down from their places in their ivory towers. Since an Agile work environment is highly collaborative, we put a premium on commitment and involvement across roles – from the development team members to the Product Owner. The ideal Product Owner is one who, like the Scrum Master, knows the day-to-day activity of the project team; someone who is present from sprint plannings to daily stand-ups to retrospective meetings.

3. Mistaking the Role of a Scrum Master with a Project Manager

Especially for teams who are used to the Waterfall environment, and slowly facilitating their way to Agile, it’s easy to delegate the Scrum Master role to the erstwhile Project Manager. For organizations with flat hierarchy, this is often the case: anyone from the top management becomes the Product Owner; Project Manager becomes the Scrum Master; and the rest will be part of the Development Team.

There’s no airtight rule that says this setup is wrong. In transitioning to an Agile work environment, a lot of onus is placed on the would-be Scrum Master’s shoulders. The Agile framework doesn’t support a “controlling” management style, and an authoritarian Project Manager defeats the purpose of a “self-organizing” Agile team. The Scrum Master is a servant leader, and a protector of team from obstacles that may arise while developing a software or any product. He serves as a coach, not a boss.

In the same way, a Scrum Master tends to become so supportive that he takes on tasks for himself. This is acceptable, only to the point when the Scrum Master isn’t sidetracked by concerns about his own job that he totally forgets the Development Team and the issues the members face iterations after iterations.

To learn more about the perfunctory roles of a Scrum Master delivered in a funny way, see this video: The Power of Scrum.

4. Murky Concept of “Done”

Agile-Scrum adoption entails championing a stickler-level standards for quality. Quality control mechanisms are not discrete from the process; it has to be embedded in every step. A Scrum developer is also a Quality Tester, of his own work! While certain standards – technical or otherwise – can be part of the list of the quality acceptance criteria, there should be a mutual agreement between stakeholders and project team members about the “definition of done” of product backlog items. Generally, one cannot say something is done if it hasn’t been tested yet.

Another usual pitfall that Scrum teams get lured into is sending prototypes instead of a fraction of working software in the first sprint. A prototype code is an unnecessary way to delay writing a production code. Even at the very first iteration, a Scrum Team should aspire to deliver a potentially shippable piece of software to the client.