July 19, 2015

Scrum: 8 signs that you’re doing it wrong (part 1 of 2)



Holding a 15-minute meeting every day is not enough to make your team agile! Throughout my career, I’ve seen many Scrum anti-patterns applied, ultimately leading to rendering Scrum less effective or even counter-productive. In this blog post, I’d like to share some of the most dramatic anti-Scrum “smells” I’ve encountered so far. If any of these resemble your project situation, you should quickly take counter-action as these situations will not lead you to agility, but to what I like to call “ugility”.


After all, the Scrum Guide consists of just 16 pages. That is Scrum, and anything else is not. Is it actually that difficult to follow this recipe? Yes, because “Scrum is easy to learn, but difficult to master.”

By promoting transparency, collaboration and fast feedback loops, Scrum is a perfect match for development processes with high risks and high uncertainties. This typically applies to any custom software development process. Still, Scrum doesn’t fit every situation. For e.g. a pure “bug fixing project”, other, well-defined process models may actually be more appropriate. Here’s the catch: Failing to apply Scrum or any agile process on a project which is unmanageable by traditional process frameworks may break the project, but improperly applying Scrum by lack of understanding its principles may make the situation even worse.

Here I’ve congregated eight easily identifiable Scrum anti-patterns as I have observed them in real-world projects. I’ll try to explain what is wrong about them, why it is wrong and what you can do about it.

The Daily Scrum is conducted by the boss

Intriguingly, I have found that whenever a team introduces Scrum, the Daily Scrum is typically always held, however incomplete Scrum’s overall application is. Nevertheless, the way the Daily Scrum is held also reveals much about how well Scrum and its underlying principles are understood.

The most wide-spread misapplication of the Daily Scrum is to have it conducted by a “boss”. A boss may here refer to one or multiple persons, which may be the “Scrum Master”, a management team member or have any other role. Typical symptoms of the Daily Scrum being conducted by a boss are:
  • the Daily Scrum is held by the boss’s discretion or at his explicit invitation of the other team members;
  • the Daily Scrum is not held or significantly shorter if the boss is not present;
  • the Team Members do not communicate with each other, but report to the boss.
This is not what the Daily Scrum is all about. The Daily Scrum provides an opportunity to transparently discuss the current status of each Team Member’s work with the rest of the team and to synchronize the Team’s knowledge. Abusing the Daily Scrum as a pure reporting platform to the boss defeats its purpose and is a certain time-waster. This kind of one-way reporting can easily be replaced by a daily status e-mail to the boss.

Teams that misinterpret the purpose of the Daily Scrum typically lack understanding of two of the most fundamental objectives of Scrum:
  • Reporting to a boss implies that there is a single instance in control and in charge which violates Scrum’s philosophy: Scrum’s strength really comes from the entire Team being in charge and working together as a self-organizing unit. Having a dedicated person in charge for anything impairs the team’s self-organization and thus its ability to perform work.
  • Reporting to a boss rather than communicating with the entire team also implies that the team’s internal communication is impaired and information is held by a single instance rather than by the team in its entirety. Having the team cut off from some kind of information prevents it from taking responsibility and performing its work and introduces a huge risk to the project.
In the worst case, the boss will even use the Daily Scrum to delegate tasks to team members rather than having them collaborate in a self-organizing manner. This clearly totally defeats the purpose of Scrum.

What I’m trying to show here is that in any of these situations, the fact of rendering the Daily Scrum less effective is far less problematic than the potential underlying misconceptions of the Scrum process. This situation needs immediate action in terms of a root cause analysis: Find out why your team needs a single person in charge, and why information doesn’t flow freely within the team. If you’re bold enough, suggest that the boss doesn’t participate in the Daily Scrum anymore, or that it is conducted by another person to mitigate the boss’s influence. Observe how these changes affect execution of the Daily Scrum and overall team collaboration.

If either of the two underlying misconceptions of Scrum mentioned above apply to your project, this is indeed a very dangerous situation, and trying to resolve it, or rather to fight it, may break your team if it turns out that the “boss” or management is actually unwilling or unable to accept a transparent, team-centered project workflow.

There’s no dedicated Product Owner

The Product Owner is one of three Team member roles established by Scrum; yet in my experience many teams seem to have trouble filling this position adequately or they really just view the role as somewhat “optional”. Well, it is not.

A similar situation is that a Product Owner is actually set but the person this role is assigned to is unwilling or unable to fulfill it or just doesn’t have enough time. Another common anti-pattern, and probably the most dangerous one, is that the Product Owner is the Team’s “boss” or the Scrum Master.

Indications that the Product Owner’s position is fills inadequately include:
  • the Product Owner does not take part of every event where its participation is required (e.g. the Sprint Planning);
  • the Product Owner is unable to make a final commitment when giving input, e.g. it’s common that his decisions get revised at a later point.
As his name suggests, the Product Owner is in charge of specifying the product which is the outcome of the Scrum project, by making decisions on the Product Backlog. It is vitally important that he has both the ability and authority to do so and to not be conflicted with other charges.

Scrum is all about collaboration, and the most important form of collaboration in a software project happens between the developers and the client which in Scrum is established by the collaboration between Development Team and Product Owner. The Product Owner cannot make technical decisions nor can he make sensible business decisions without the Development Team’s input on the technical aspects. On the other hand, the Development Team cannot make business decisions nor can it make sensible technical decisions without the Product Owner’s input on business aspects.

Finding a Product Owner which fulfills above criteria is not simple and it’s one of the most important aspects of initially setting up a Scrum project. Not having an able Product Owner dooms the project. Typically, improper Product Owners include:
  • People who do not have the required business knowledge of the product’s application domain. This typically applies to any person which is not part of the department or even the company which will use or business-support the product.
  • People who do not have absolute authority over the product.
  • People who have conflicting interests within the development process. This typically includes any person which is part of the Development Team or even the company which develops the product.
If the Product Owner is recruited from within the development company (e.g. a business analyst), because the actual client company reputedly cannot provide a Product Owner, all these points typically apply.

In the extreme case of the Product Owner being the Development’s team’s boss (he may claim himself Scrum Master although in this position, he clearly isn’t) the conflict of interest is obvious. Taking both these roles, he has absolute control over what is done, and how it is done, leaving developers no choice but to obey his will. This of course is the complete opposite of a self-organizing team.

The quest to find an appropriate Product Owner must have succeeded before the project even begins. The most important criteria typically is the Product Owner’s authority. If he has to ask his boss for whatever business decision, this is a strong indication that actually, his boss should be the Product Owner. In fact, multiple persons can internally make business decisions, but for the Scrum process it’s important that there is only one single definite “voice” giving input to the Development Team. The customer may literally send anyone as the “Mouth of Sauron”.

If the quest to find an appropriate Product Owner does not succeed, the project is doomed, at least as far as Scrum’s applicability is concerned. Yes, Scrum is not applicable for any conceivable situation. Actually, it does define some fundamental constraints to its applicability, and having the central role of the Product Owner filled is one of them. You can then only resort to going for a non-agile approach or to teach the customer that without a Product Owner, you’re not able to do your job. That’s professionalism in action.

Developers aren’t in direct contact with the Product Owner

This is a special case of the Product Owner not fulfilling its role or being impaired (e.g. by management) to do so. In this case, the Product Owner is not or scarcely in direct contact with the Development Team. Most typically, in this situation, there’s a “middle man”, e.g. the Development Team’s “boss”, the Scrum Master, a business analyst or a key account manager which acts as a proxy between the Development Team and the Product Owner.

This is a very clear Scrum anti-pattern. Having a “proxy” between Development Team and Product Owner doesn’t add any value, but instead, weakens communication, mutual understanding and collaboration efficiency, and is overall harmful to the Scrum process. Management may introduce this anti-pattern by lack of understanding of Scrum’s principles or by lack of confidence in having the developers communicate directly with the customer, or because it would force adaptations in the team structure, e.g. re-evaluation of the role of a business analyst.

In Scrum, having direct contact between the Development Team and Product Owner is recognized as being essential to build mutual trust and understanding. If a developer doesn’t know the customer, how is he supposed to understand his requirements? Scrum promotes and facilitates Dev-PO-communication by providing recurrent formal events for meetups.

If your team has any of above situations in place, i.e. a “proxy” of any kind between developers and customer, the team must take immediate action to change that. If the situation is caused by management’s restraint to have direct developer-customer communication, this will be tricky to solve. However, if Scrum events are held, you can use these as an opportunity to introduce the Product Owner more informally in the development process. Having these events not conducted by a “boss”, but executed in a self-organizational manner, may help the Product Owner understand that he would profit most if he was able to freely communicate directly with the people who actually build his stuff.

Development Team members have any role other than Developer

A Developer is a Developer is a Developer. No other roles or titles are recognized for any member of the Development Team. There is no “boss”, no “architect”, no “business analyst”, and no “senior programmer”. This is very different to how “traditional” development teams are organized, that is hierarchical and very ill-suited for software development.

Having team members with distinct functions centralizes knowledge, authority and responsibility which seriously diminishes the team’s ability to form a self-organizing, interdisciplinary unit which is absolutely essential to Scrum. If for instance, there was a single “software architect” in the team which is in charge of making “fundamental technology decisions”, e.g. which database to use, why should any other team member feel responsible for that decision? In this very moment, the team as a unit died.

The Scrum Guide explicitly prohibits any Developer role except Developer. This forces a Scrum Team to share knowledge and responsibility. There’s no single point of failure, and there are no silos. Everyone is kept accountable for the work of the entire team. It’s important to realize that Scrum still recognizes people’s individual strengths. Through the self-organizing nature of a Scrum Team, each individual will bring in its own strength, resulting in diversified task assignments. Or, as it is put in this stackoverflow answer, “a "lead" developer will continue "leading," but as a natural consequence of their (sic!) experience and not as a mandated function of their title“.

Breaking a traditional hierarchy is one of the most difficult things when introducing Scrum. I’ve seen it succeed in some teams which worked together disregarding any existing hierarchies, and fail in others who were unable to adapt to the new thinking. Also from above stackoverflow answer: “That's in an ideal world where people can put their egos aside. Good luck!” The most sensible advise I could give here is to educate people on how true collaboration will increase productivity and efficiency. Having people in the team which are unable or unwilling to collaborate will harm the team’s overall performance and may introduce technical debt which is well worse than not having their manpower in the team at all.

Pages: 1 2