July 19, 2015

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

Pages: 1 2

The Sprint is not fixed

This is a very obvious violation of one of Scrum’s most basic rules and the most easy one to detect: The Sprint length, considered to be fixed by the Scrum Guide, is shortened or, more often, prolonged at the discretion of a dedicated team member, a “boss”, management or any other person with the authority to do so. This typically happens in a situation where Sprint planning drastically underestimated development efforts and time is running out to complete the Sprint’s objectives. By lack of understanding of how Scrum works, it is then assumed that extending the Sprint will fix the problem. Of course, it will not, but instead, it will make things much worse.

Defining a single development cycle (the Sprint) as a time-boxed unit of fixed length cleverly enables both transparency and control of the development cycle: With the time length fixed, development effort can be adjusted by changing the scope or the quality (with the scope clearly being preferred) to achieve the Sprint goal. Naturally, we can easily manage changes to the scope whereas adjustments to the time frame are really only possible in one way. Most importantly, a constant, fixed time-box for a Sprint gives us a means of comparing one Sprint’s performance with another’s. This enables us to judge or make predictions on the current Sprint’s performance or the overall project progress, and with each additional Sprint, collecting more empirical performance data, our predictions will become even more accurate over time.

As soon as we begin to change the length of a Sprint, we lose this tape measure. Also, prolonging a Sprint breaks the Product Owner’s expectations and disturbs the processes associated with Product Increment delivery which would then be postponed.

Prolonging the Sprint is just no option! Instead, what you should do in a situation where you realize that you can’t implement all the predicted functionality until the end of the Sprint is to finish the Sprint in time and then use the Sprint Review and Sprint Retrospective to inspect why you weren’t able to meet your Sprint planning estimates. Yes, in this situation, Scrum will force you to re-assess your planning, your development workflow and your overall performance rather than just hiding what went wrong by tweaking Sprint planning. This is the only way good teams will get even better over time!

The most extreme violation to the fixed Spring length rule of course is to not have any well-defined Sprints at all which basically makes the project become a waterfall or a death march. This clearly is not Scrum nor agile at all and because this process lacks any feedback loop, it is clearly unmanageable and very ill-suited for custom software development. Because there is no way to inspect or adapt team performance, project management really becomes superfluous is such a scenario. I assert that if in this situation, project management is laid off, eventually a self-organizing team with a (customer) feedback-controlled development process will emerge.

There’s no well-defined Product Increment

This one is closely related to not having fixed-length Sprints, as explained in the previous section. In Scrum, every Sprint has a goal, and the goal is create a fully-functional, shippable product of actual business value, the so-called Increment, built by further evolving the Increment created in the previous Sprint. If your Sprint Goal is not defined like this, you’re not doing Scrum.

Typical deviations of a Sprint Goal’s definition are:
  • there is no well-defined goal or outcome at all;
  • there is an initial goal, but it is only loosely defined or it gets changed arbitrarily throughout the Sprint;
  • there is a well-defined outcome, but it is not built upon the outcome the previous Sprint.
Not having a fixed Product Increment introduces the same lack of manageability as not having a fixed Sprint length, as explained in the previous section. Note that Scrum does allow to re-negotiate a Sprint’s scope during the Sprint; however, massively altering the outcome would certainly invalidate Sprint planning and thus diminish Sprint manageability.

It is absolutely essential to have the Sprint Goal and every single task (a Sprint Backlog item) well defined and to make sure this definition is well understood by every team member. This really is the precondition to Scrum’s transparency. More precisely, every single Sprint Backlog item needs a “definition of done” which allows you to “tick” finished tasks off as the Sprint progresses. Ambiguity about task acceptance criteria leads to lengthy discussions and conflicts.

Lastly, having the outcome not built upon the outcome out the previous Sprint actually violates the idea of building an “increment” as this doesn’t match its definition. By building something “completely different” than in the previous Sprint, you deprive yourself of the possibility to learn from past experience which is the big advantage agile processes introduce.

To sum this section up, it is vitally important to make sure that the Sprint Goal and the tasks required to reach it are well defined and understood. Tasks with an incomplete or ambiguous “definition of done” must not be deemed completed. During Sprint Review / Retrospective, it must be discussed why the “definition of done” was inaccurate in order to introduce changes to the next Sprint Planning.

Planning and reporting is either not transparent or not updated daily

This is arguably the most vague anti-pattern presented here as it comes in many different shapes. Typical signs of its application include:
  • there is no Sprint Backlog or it is either not visible for the whole team at all time, it is unclear or it is not updated daily with the input of the entire team;
  • there is no Product Backlog or it is either not visible for the whole team at all time, it is unclear or it is not updated after a Product Backlog Refinement Meeting;
  • information about the current Sprint progress is not presented on the Sprint Backlog, but distributed or hidden in external resouces such as bug tracking systems;
  • the Daily Scrum is not held daily (Ha!).
Obscuring information about team performance and project progress diminishes the Team’s ability or work in a self-organizing manner and for each individual to work efficiently. With information locked away, knowledge gets centralized, introducing dependency on single individuals which keep the knowledge and thus become information bottlenecks. There’s the enemy of a self-organizing team again.

In a Scrum team, it is for any Team member vitally important to have this information updated on a daily basis:
  • what tasks any other Team member is working on and how long these tasks will keep him occupied;
  • what the current status of every single Sprint Backlog item is, and how long it will take for each one to get finished;
  • what the current status of every single Product Backlog item is, and how long it will take for each one to get finished.
He does need to have this information in order to make sensible decisions about how the tasks he is currently working on do interfere with tasks others are currently working on; what are the dependencies of the tasks he is currently working on; what problems others are facing which may concern him as well or which he may help solve; what task he should start next; and other decisions he must make as a member of a self-organizing team.

This is yet another issue which typically concerns organizations that are not used to agile processes, and it may either hint that agile thinking is not clearly understood or that it’s actually undermined. Scientia potentia est – knowledge means power, and one way to stay in power is keeping knowledge locked. Needless to say that this violates any agile thinking. Scrum cleverly forces us to break this kind of thinking by introducing these transparent artifacts. Your Scrum team must use them, or you’re not doing Scrum.

It’s usually most efficient to keep them as simple as possible, e.g. use a whiteboard and sticky notes as the Sprint Backlog. If your team doesn’t use them but you really want to have them, volunteer to keep them updated. Your team will quickly have to acknowledge that the time effort is negligible and the profit is remarkable. Impress them by drawing a Burndown Chart. If you lack any information to properly keep the backlog updated, ask for it. That way, you will make more and more information transparent over time.

There’s no Sprint Retrospective

Of all of Scrum’s events and artifacts, the Sprint Retrospective meeting gets most typically neglected in my experience; this is especially true for organizations with scarcely any prior agile experience.

However, the Sprint Retrospective is an essential part of Scrum, and without it, you’re not doing Scrum. The Sprint Retrospective is an opportunity to inspect the development processes and to identify impediments and improvements for the next Sprint. These ideas are kept track off, and at the end of the next Sprint, the Team investigates how well they have been realized. Thus, the Sprint Retrospective really is the key opportunity for Scrum’s central process of inspection & adaptation.

Hence, the Sprint Retrospective is arguably the most inconvenient event introduced by Scrum as it forces the Team to identify and discuss development process impediments, thus admitting that the processes are not working perfectly yet and to challenge itself to address and resolve problems.

The Sprint Retrospective’s effectiveness is diminished if one of the following applies:
  • the Sprint Retrospective is not held at all or not held at the end of each Sprint;
  • not all Development Team members participate in the Sprint Retrospective;
  • people are not free to talk about any aspect of the development process or input of certain people gets judged higher than the input of others;
  • the Team fails to decide concrete, measurable improvements for identified problems or their realization is not tracked and inspected in the next Sprint.
I think it’s also important to realize that as with all human interactions within a Scrum process, Scrum is organized democratically with respect to the individual, not to the majority. Every single individual’s opinion must be respected and may lead to adaptations. This is important for as soon as someone’s opinion gets ignored, he will not be able to take responsibility for what others decide which impairs the all-important self-organization of the Team. It’s of course difficult to find solutions which please everyone, but a Team which works as a unit will eventually find compromises on which every single Team member can agree. If your Team fails to do so, well, you’re actually in trouble, and Scrum reveals this.

Again, these aspects are typically neglected in non-agile teams, leading to poor collaboration within the team and diminished motivation of individuals.

What if your team fails to find common agreements for aspects of the development process? In a Scrum-driven process, this must not be ignored. Eventually, you will have to come to a decision. The team must work as a unit, otherwise, Scrum is no more applicable. You must take actions accordingly.


Being an intrusive framework, Scrum’s aim is not to provide concrete solutions to problems in your processes, but to show what is going wrong. Scrum does that by promoting and facilitating communication (both team-internally and with the customer) and transparency. But in order for Scrum to succeed, your team and organization must be ready to open up for Scrum’s processes and to embrace evolution and adaptation.

Scrum is an inconvenient framework in that it just doesn’t allow you to hide away any problems in your organization; if you try to do so, you will break Scrum’s processes, rendering it useless or even harmful.

In my opinion, organizations who fail to or are straight unwilling to properly apply Scrum where its application would be appropriate are typically suspicious. It oftentimes turns out that they try to modify the framework in order to hide what they think should stay unrevealed.

However, this of course is the worst thing you can do. Scrum is an industry-proven framework which works as a whole. Changing parts of it without knowing its details is really like introducing your own process framework without actually knowing what it does. You must either introduce Scrum as a whole or otherwise recognize that it doesn’t fit your organization and head for a better-suited process framework. Unfortunately, if Scrum’s inapplicability is caused by underlying problems concerning team hierarchy or communication you will most likely not find any “magic” framework which fixes these problems for you; at most, you will find one which hides them away in the short run.

Applying Scrum just because it’s fancy to do so or because it does seemingly involve less overhead than traditional process management methodologies without understanding its purpose or ignoring the changes it is introducing will leave you with an ill-suited, dysfunctional and poorly defined process with will harm the team’s efficiency and the quality of the product outcome. When you thus make things worse rather than improving them, agility becomes “ugility”.

Do you agree with these Scrum anti-patterns? Have you experienced others? Let me know in the comments section below – I’m highly interested in your experience.

Pages: 1 2

No comments:

Post a Comment