What are the anti-agile patterns

Dangers of agile antipatterns

"Our own Scrum"

by Masud Fazal-Baqaie, Baris Güldali
 

The increasing complexity and dynamics of IT are increasingly forcing IT managers to rethink software development. In particular, the need to react quickly to unforeseen circumstances motivates IT managers to implement development projects in an agile manner. Scrum has established itself as the best-known agile approach in recent years. In practice, however, one often experiences that lived processes deviate in many ways from the Scrum Guide and the underlying agile ideas. In this article we describe how you can adapt Scrum to your own context without falling into the trap of agile antipatterns.

Both in public perception and in practice, lightweight, agile development processes, above all Scrum, have replaced heavyweight process models in many domains [Kuh15]. The reason for this is the promise of agile methods to generate less procedural overhead and deliver results faster. The short learning and feedback cycles make it easier to deal with unstable requirements and little-known technologies or new specialist topics.

In contrast to heavy-weight process models, agile methods describe some basic rules that are easier to follow. At the same time, teams are faced with the challenge of implementing and maintaining effective and efficient processes themselves in terms of agile values ​​and principles.

However, the "agile transformation" is not always that easy for companies. The following can often be observed in practice:

  • Scrum is chosen as an agile process model, but when it is introduced, Scrum roles are abolished immediately or events are not adhered to (e.g. no Scrum Master, no retrospectives, no timeboxing for events). This means that you don't get to know and understand the central ideas behind Scrum and its composition of events, roles and rules.
  • Self-made Scrum is often supplemented by further adjustments that are actually counterproductive in terms of agility (e.g. status meetings for management instead of daily stand-ups, technical acceptance tests at the end of the sprint instead of daily results from automated test runs).

Such deviations from Scrum have coined the term “ScrumBut”. This describes sentences that are often heard in practice such as:

We do Scrum, but ...

  • we have our own customized Scrum.
  • we do a “daily” scrum per week, that's enough.
  • we don't need retrospectives.
  • we have 8 week sprints.
  • we don't have a “definition of done”.

While deviations from Scrum need not be categorically bad, they should be approached carefully and systematically. In this article we describe:

  • how to recognize deviations from rules and poor practice in relation to your own agile development processes,
  • why you shouldn't deviate from the rules too early and why even small deviations can have a big impact,
  • why continuous and targeted adjustments still correspond to the agile idea and are necessary.

Scrum in the wild

As mentioned in the introduction, in practice certain patterns to be avoided can be found again and again when using Scrum. An online search for the terms “antipattern” and “scrum” leads to a wide variety of patterns on websites and blogs (e.g. age-of-product.com/). Often these are ideas that look obvious at first glance, but then cause problems because they conflict with agile values ​​and principles. In the following, we will look at some of these patterns as examples.

Roles not understood: With Scrum, different roles are introduced than are known from classic process models. The product owner is responsible for the user stories and their acceptance criteria, a cross-functional team independently distributes tasks, the scrum master ensures that the team can work undisturbed and that the rules of scrum are adhered to. If the objectives of these roles and in particular their differences from the classic roles are not sufficiently understood, this inevitably leads to problems. For example, the classic project manager becomes a Scrum Master, but struggles more with budget and management issues than concentrating on the team; the customer sees the specialist department as the product owner, but does not feel responsible for the success of the product; and the developer and tester silos are maintained even when they are in the same offices.

Misunderstood agility: In teams without a Scrum Master and with little prior knowledge of agility, this is often equated with spontaneity and a certain lack of plan. Then there is often the fact that the uncoordinated action in ad hoc processes is also perceived as particularly progressive, particularly agile. Short-term plan, responsibility or scope changes have nothing in common with agility, especially not with Scrum. Scrum requires the disciplined adherence to time-limited events. The scope for the sprint is frozen at the beginning and a stable team is generally advocated.

Acute unavailability: The product owner can hardly be reached by the development team during the sprint and cannot answer any queries from the team. This forces the team to run a “mini waterfall process” in the sprint. The team either switches to more detailed advance documentation of the requirements or risks an implementation that does not correspond to the actual wishes of the product owner.

Late, many manual tests: A common antipattern is a lack of test automation combined with manual tests. In combination with an incremental-iterative procedure, manual tests are very time-consuming due to the repeatedly necessary regression tests and the steadily growing number of regression test cases. This means that tests are postponed to the end of the sprint and also take a very long time. This means that the timebox is exceeded and any errors found cannot be remedied in good time by the end of the sprint. Manual acceptance phases often only take place after a series of sprints or at the end of a release. Accordingly, the feedback to the developers takes place much later. Even if tests are automated and integrated into Continuous Integration (CI), they cause the build pipelines to crash if they are poorly implemented.

Management stand-up: The stand-ups as a format for coordination and mutual support within the development team give way to a status stand-up in which the product owner or other stakeholders query the status of tasks or user stories on a daily basis. In the worst case, you go through all user stories in a sprint. The development team is thus forced to communicate on a level that is understandable for the relevant stakeholders, instead of, for example, exchanging technical details. In addition, the daily discussion of user stories or tasks that have not yet started is simply inefficient.

Missing retrospectives: One of the strengths of Scrum is that it follows empirical principles. Scrum combines short development cycles with regular meetings for reflection. The retrospectives are therefore an important success factor, so that a feedback culture and continuous improvement can be established. Only in this way can fast, high-quality software development processes be established with Scrum in the medium and long term.

Why should one strive for Scrum in its purest form?

We are not apologists and religious advocates of one method or another. In our work to date and in daily practice, we emphasize that the development processes must be tailored to the team and its environment. Nevertheless, in our experience, teams often deviate too quickly from the specifications, for example of the Scrum Guide [Scrum]. There are various reasons why it makes sense to stay as close as possible to the original when adapting agile processes and Scrum, which we will explain below.

First there is an argument based on the natural learning process. The adaptation of agility is usually associated with a learning process. In an agile context one likes to quote the principle of "ShuHaRi", which comes from the Japanese martial art and describes the three stages of learning:

  • At the initial “shu” level, it is important to obey in order to acquire the basics.
  • On the following level “ha”, where appropriate, there is a conscious break with traditions and selectively deviating from what is given in order to also understand causal relationships.
  • At the final “ri” level, the specifications no longer play a role, although the fundamentals in principle remain valid. Rather, you are an expert yourself.

Kent Beck, founder of Extreme Programming (XP), differentiates between the three levels of XP maturity:

  • Do everything as written.
  • After having done that, experiment with variations in the rules.
  • Eventually, don't care if you are doing XP or not.

Similarly, Figure 1 shows the iceberg of agile transformation (based on [Bun16]). As shown and already shown, in practice there is often only a simple adaptation of Scrum that even lags behind the Scrum Guide. Even if the Scrum Guide is followed, there is still a lot of potential for the true adaptation of agility in terms of values ​​and principles, which can be exploited through continuous improvement.

In summary, it is advisable not to deviate from the requirements of Scrum until you are sufficiently familiar with software development processes, especially Scrum, agile values ​​and principles, as well as the team and its environment.

The next argument is based on this interaction through the components of Scrum. The Scrum Guide describes a very reduced set of basic rules. The various specifications are coordinated with one another. This means that a single system deviation can already have several undesirable side effects.

Take the estimation accuracy as an example. In Scrum, the estimation accuracy is determined based on experience for a relatively small scope. Various components of Scrum support this approach: A stable team and a fixed sprint duration make it easier to estimate from experience. A fixed, unchangeable sprint scope makes it easier to determine the scope to be estimated. The fixed events “Planning” and “Review” make it necessary to compare the estimate and what has actually been achieved. With the retrospective, findings are to be derived from this for future sprints and thus estimates.

This small example should illustrate that you should only deviate from the Scrum Guide if you can estimate the consequences and side effects with sufficient knowledge and experience.

As a final argument, we would like to cite the famous sentence that also applies to Scrum: It is easy to understand, but difficult to master. The teams often have to struggle with various "pains", especially in the first weeks and months after the introduction. However, these can be a positive sign, as they provide a clear incentive for the team to alleviate the pain-causing circumstances.

Practical examples are that it is difficult to cut stories small enough (-> create technical prerequisites for smaller changes), to adhere to the timeboxes of events (-> to concentrate on the essentials, to prioritize) or to commit oneself to the sprint results ( -> mutual team-internal support, joint responsibility).

When teams weaken or ignore the rules instead of the circumstances that lead to the "pain", they hinder medium and long-term improvements towards agile values ​​and principles.

Why should one continuously improve Scrum?

Scrum describes a management framework in which the roles involved are asked to fill in the gaps in terms of agile values ​​and principles. The reduction of the Scrum Guide to a small set of relatively simple, explicitly defined rules is at the same time the reason that Scrum is easy to understand on the one hand, but can have many specific characteristics on the other.

Each team should actively shape and develop their specific Scrum form instead of leaving it to chance. The main means of achieving this are agreements such as the “Definition of Ready” and “Definition of Done” as well as platforms such as the retrospective. Retrospectives serve to remove context-related obstacles and to establish context-specific improvements. In addition, multi-step, systematic improvement initiatives can also be carried out [FBS17]. The focus should be on how problems that have occurred can be avoided in the future, i.e. on procedural and fundamental improvements regardless of the current situation. Suggestions for this are provided by collections of patterns that go well with Scrum, such as [Scr17].

The consideration of the individual circumstances plays a major role. For example, it is not uncommon for the established corporate culture or social discussion culture to play a major role in the implementation of retrospectives. A lack of a culture of transparency or an indirect culture of criticism can lead to dissatisfaction in retrospectives. The acceptance of this format therefore depends very much on the sensitivity of the Scrum Master. Therefore, the design of retrospectives (and also of other Scrum events) must take into account the circumstances of heterogeneous teams.

For example, an anonymous collection of suggestions for improvement could be introduced for retrospectives if this is culturally necessary. Another example is the circumstances of distributed development. Distributed teams organize the regular appointments differently in terms of time and place than teams that are in the same place or even in the same premises. The distribution of the teams also has an impact on how information is exchanged and how much documentation is required. The final example here is the involvement of dedicated experts (security experts, specialist testers, performance analysts, etc.). This often makes it necessary to agree on dedicated (regular) appointments or additional activities. It should be noted here that this must not lead to a relapse into waterfall-like behavior. In any case, you should be aware of the process debt and try to reduce it in the medium term.

With all presented examples and further adjustments and improvements, it must be taken into account that the changes are in line with the agile values ​​and principles [AgMan]. In addition to the initial assessment, actual practice with the changes should also be questioned. Any violation or non-fulfillment of agile values ​​and principles can indicate an antipattern and must be analyzed, understood and weighed up in relation to its "process debt". This can then be reduced as part of retrospectives and continuous improvement.

Take aways

Understanding the Difference: Doing Agile vs. Being Agile

In order to be really agile, it is not enough to simply follow the explicitly described rules of agile development processes and hope that this alone will ensure success. Rather, it is the task of the team to design the rules in an agile sense and to keep improving. Everyday practice is full of surprises that need to be responded to. Only the internalization of the agile mindset gives the team the ability to react quickly to unexpected events and to find needs-based solutions.

Build the right things, build things right, build things fast

Three well-understood roles contribute to a successful agile team (see Figure 2):

  • A Product Owner who ensures that the product backlog is continuously filled with relevant requirements and prioritized, and who clarifies their value and complexity.
  • A Scrum team consisting of motivated and committed members who meet the sprint goals within the defined time frame to the satisfaction of the product owner.
  • A Scrum Masterthat clears the obstacles out of the way and allows the team to focus on their sprint goals.

To be excellent or not to be excellent: that is the question

Agility and especially the transformation from classic development to agile development requires a lot of persuasion. Participants who hold on to their historically evolved roles and tasks must be convinced of the agile values ​​and principles. Promoting acceptance among those involved and their environment works best with results.The team must convince through a well-rehearsed, continuously improved interaction in all disciplines: the exemplary coordination of technical requirements with stakeholders, the sensible cutting of user stories to match the sprint capacity, modular and easily adaptable architecture for the integration of increments, direct feedback on development activities Well thought-out CI pipelines, avoidance of regressions and control of test efforts through test automation.

Don't be afraid of the retrospective. It makes us better people

The retrospective serves the continuous improvement through reflection, and not only professionally and technically, but above all also interpersonal. In addition to open discussions about obstacles and potential for improvement, praise and confirmation should not be missing. A Scrum team not only works out what it can do better next time, but also helps to build trust and appreciation between the team members.

Literature & Links

[AgMan] Manifesto for Agile Software Development, 2001, see: http://agilemanifesto.org/

[Bun16] R. Bunning, Illuminating the potential of Scrum by comparing LeSS with SAFe, 2017, see: https://www.slideshare.net/rowanb/illuminating-the-full-potential-of-scrum-by-comparing- less-with-safe

[FBS17] Software process improvement in practice. Project management and process models (PVM) 2017, 129–143, GI, 2017, see also: http://pvm-tagung.de/

[Kuh15] M. Kuhrmann, M. D. Fernandez, Systematic Software Development: A State of the Practice Report from Germany, in: IEEE 10th Int. Conf. on Global Software Engineering (ICGSE 2015), 2015, pp. 51–60

[Scr17] Scrum Pattern Community, ScrumPLoP 2917, 2017, see: http://www.scrumplop.org/

[Scrum] J. Sutherland, K. Schwaber, The Scrum Guide, July 2016, see: https://www.scrum.org/resources/scrum-guide


is Managing Consultant of S&N CQM GmbH (http://www.sn-cqm.de). His work focuses on the quality and improvement of development processes. He is the deputy spokesman for the specialist group “Process Models for Business Application Development” and a member of the product management management committee of the Society for Information Technology.
is Managing Consultant of S&N CQM GmbH (http://www.sn-cqm.de). His work focuses on test and quality management. He is a member of the executive committee of the TAV (test, analysis and verification of software) specialist group in the Gesellschaft für Informatik.