Agile Anti-Patterns: A Systems Thinking Approach

As Agile practices are adopted more widely across a variety of businesses and projects, Agile anti-patterns disguise themselves more subtly and effectively and take on the appearance of "solutions" and "workarounds" that are no longer framework-based, but appear as valid contributors to the Agile ecosystem of the organisations in which they exist. In this article, we discuss the importance of recognising and indeed classifying this new generation of anti-pattern by adopting a systems thinking approach and how to create and promote the idea that a shared language using value streams is an effective means of creating a systems thinking culture amongst agile teams and the wider business.

What are agile antipatterns?

Agile anti-patterns typically manifest themselves as commonly applied solutions to identifiable and widely recognised problems. A solution becomes an anti-pattern when it ceases to provide an effective fix, or when the cumulative effect of repeatedly applying that fix has an ongoing negative impact. The pernicious nature of the anti-pattern is bound up in the fact that negative impacts may take time to reveal themselves, that problems may appear in unexpected places and that whilst this is occurring, the initial issue may seem to have been addressed or resolved to some extent.

The consensus-led nature of their adoption serves reinforce the adoption and continuation of anti-patterns; after all, a time constrained team of ten may take little convincing that daily stand-ups yield far less benefit than an extra 12.5 development hours would during the course of a week.

Common agile antipatterns

Framework-based anti-patterns have traditionally involved the removal of key framework components (stand-ups; retrospectives; reviews) or the addition of stage gates that typically satisfy a governance requirement. These framework-based antipatterns are easy to adopt and embed and thankfully, are, for the same reasons, relatively easy to rectify in terms of adding and removing ceremonies and practices. An increase in development time at the expense of daily stand-ups will in, most cases, yield more lines of code. Predictably, this scenario will also yield a greater number of bugs, required fixes and failure demand effort (as well as less cohesion and cooperation and effective communication within the team).

Time, inspection, adaption and experience teaches teams that the impact of such framework-based changes can be harmful and often this hard-won experience can contribute to the evolution of a self-organising, high-performing team as they learn to identify, deal with and eradicate these antipatterns together. Less obvious (and therefore more pernicious) are the anti-patterns which cannot be easily be removed, like a Jenga block from the composition, practices and activities of the team. Often, these antipatterns are difficult to remove because they are difficult to identify, and they are often difficult to identify because they emanate from a place outside of the Agile team and meet a requirement of the wider system.

Ironically, Agile frameworks can serve as a breeding ground for anti-patterns, as the empiricism which they generate compels us to continually surface and to address issues, thus creating the possibility of an internal failure demand system within the team. In turn, this can create a culture of focusing upon and attempting to solve even the most peripheral of issues. Recognising both the origin point of these issues and the wider impact of our responses is one of the keys to avoiding this scenario and a systems thinking approach can greatly assist.

Perhaps the most common organisational or managerial anti-pattern is that embodied by Brook’s "law" which states that "adding personnel to a late project makes it later". Development teams often complain (often justifiably) that they are under-resourced and welcome the extra hands to the pump, little realising volume and quality are not the same thing and that creating extra volume means that you have to carry the compositional weight of it (both good and bad) towards the product’s finish line. The truth of the matter is that the solutions which anti-patterns appear to offer can be extremely seductive; after all, it takes an extremely high-performing and highly evolved team to turn down extra personnel (I have tried and was outvoted!).

From a team’s perspective, some powerful anti-patterns are not necessarily that seductive, but are no less powerful as they are organisationally led and as such, are mandated to serve a particular organisational or wider business purpose which the team can broadly recognise and empathise with. Unfortunately, many of these are founded upon notions of fixed cost, scope and time and at the team level, solutions are enacted to accommodate these imperatives, and the flow of value created by the team is diluted. Even the most comprehensively detailed value stream map may not meaningfully depict the interaction points between component parts of the system nor the vocabulary used to drive these interactions.

Perhaps the most widespread and (widely felt) anti-pattern of all is the decision to parachute a number of Scrum teams into an organisation in the hope that the Scrum teams will thrive, and in doing so, will act as the engine for organisational transformation. This rarely succeeds where the inter-relationship between the team and the organisation is not clearly understood or articulated.

In many cases, these anti-patterns can be avoided, or at least recognised and more effectively dealt with by adopting a systems thinking approach to the role of our Agile teams within the organisation, and the effects of the organisational forces being brought to bear upon them.

Adapting agile within boundaries, or bending the rules to meet organizational requirements?

One of the most commonly overlooked benefits of Agile frameworks in general is that they work well as diagnostic tools and often surface (in the initial stages of deployment) a wide range of issues that can have a negative impact upon the delivery of value, team and organisational culture and dynamics and the move toward continuous improvement. The real danger with adaptations to established practices is that we end up diagnosing (and indeed measuring) the effect of the changes made, rather than delivery of value. This can be especially counterproductive when, for example, we place emphasis upon the increased velocity of a team that has jettisoned stand-ups in the pursuit of more development time. A velocity increase in this case demonstrates that this adaptation is "working". Moreover, if these "tweaks" are made (and they often are) without reference to and understanding of the wider system (both at the team and organisational level) and therefore neither the cause nor the resulting effect are fully understood, then the problems perpetuate by adding further changes to accommodate or offset the original ones.

Agile certifications are neither good nor bad (efficacy depends on the agilist holding the certification), however, they do at least delineate the boundaries, rules and more practically, the do’s and don’ts of the framework in question, most typically ensuring that the correct elements of the framework are in place, deployed in the right way and in the correct order. Having stand-ups and sprints does not make it Scrum, and mandating only these things does not make you a Scrum Master, but certification undoubtedly helps to define the boundaries. Unfortunately, we too often subvert, dilute or ignore these agreed boundaries and rules in order to accommodate the norms, rules and boundaries of the organisation and, worse still, we characterise these compromises as necessary adaptations or innovations (especially harmful if these ‘innovations’ create scope for creating even more valueless solutions as above).

There are a number of environmental factors which foster this anti-pattern, chief amongst which is the readiness of the agilist to demonstrate the flexibility of the framework to adapt to organisational and wider systemic requirements. Ironically, this is often seen within agile transformation programmes where any real transformation is localised at the team level and is not successfully transmitted to the wider organisation as the nodes of connectivity between the team and the system within which they reside force interactions to take place in the context of cost, scope and time. In this way, the transformation at the team level takes place in order to accommodate a lack of transformation within the wider system.

How systems thinking and agile go together

Systems thinking is nothing more complex than the process of understanding how things influence one another within a whole (system) and of attempting to understand how these inter-relationships impact upon the common objectives of that whole. Additionally, systems thinking is an approach which seeks to use this understanding to determine the points of highest leverage, the places in the system where small changes can yield significant results. High performing agile teams utilise the concept of systems thinking very effectively, as they continually inspect and adapt in order to improve what they do and how they do it. A system characteristic is the ability to maintain stability through feedback.

Whatever your thoughts, feelings and indeed experiences of scaling frameworks, it must be acknowledged that one of the more effective aspects of SAFe is the emphasis it places upon a systems thinking approach to deliver value and which is embodied in the notion that "the solution is a system". Despite common objectives (solutions) being at the heart of organisational systems, it is often the case that the individual components of the system become inward looking, less aware of the system of which they are apart and as such, operate as "selfish, competitive, independent profit centres, and thus destroy the system". This can serve to isolate the team from the wider business and from the systemic influences (both good and bad) which are brought to bear upon it, as the team is almost entirely focused upon internal (to the team) issues and solutions.

The way to combat this is to blur the boundaries between the wider system and its components (Agile teams) by placing a greater emphasis upon the recognition and understanding of the influences of the wider system upon the Agile team. This can be achieved by classifying both team and system-level anti-patterns, and by encouraging teams to determine the points of highest leverage in respect of the solutions they develop.

Using systems thinking to deal with agile antipatterns

For many businesses, organisational complexity translates to organisational problems which in turn dilute the efficacy of the solutions that the organisation and its agile teams can create and deploy. This issue is exacerbated by virtue of the fact that often, agile change advocates create impact at the team level and have limited scope to effect change within the wider organisation (communities of practice notwithstanding). A systems thinking approach should be seen as a means to blur the boundaries and reduce the rigidity of the barriers between agile teams and the wider organisation. A key tenet of systems thinking is that we recognise that the performance of the system is not the sum of its parts; rather it is the result of the interactions between these parts. The anti-patterns that emerge and persist are often the result of the ineffective interactions between agile teams and the wider organisational system within which they operate.

By embracing systems thinking in this way, we can begin to recognise the patterns that characterise these sub-optimal interactions and in doing so, can effect changes which deal with causes rather than symptoms.

Agile certifications

Although much maligned as money making exercise in some circles, certifications continue to provide an effective baseline in terms of skills and knowledge and the exchange of information, which takes place during training sessions based upon a wide variety of backgrounds, and experiences remains valuable. Increasingly, I think that we will see more bespoke certifications that are embedded within specific organisations and organisational scenarios (agile solutions within the context of a logistics project can differ markedly from those inherent within software development), especially as businesses seek to develop and promote agile expertise from within their existing ranks and as more traditional, delivery focused roles evolve. This in turn would address the frequently expressed concern that it is possible to accrue a raft of Agile certifications without gaining the relevant experience. In-house "Agile Academies" may well become the norm as businesses recruit from within to meet their own, very specific needs.

How teams can self-check for anti-patterns and act to prevent them impacting their results

The old adage that "today’s problems are yesterday’s solutions" encapsulates the problematic nature of anti-patterns, but also hints at the evolutionary nature of the problem-solving landscape. It is important to establish whether or not the team or organisation has a history of anti-pattern adoption, and recognise that more often than not, antipatterns are the result of ineffective interactions between agile teams and the systems in which they operate.

It is worthwhile categorising the issues raised, and the solutions proposed at the team level so that these issues can be dealt with in a timely (cause and effect are not always closely linked in place and time) and strategically targeted way and so we can more successfully identify where the issue emanates from, and whether the action taken will be felt in the same space.

High performing Agile teams are adept at creating transparency within the team, but using a systems thinking approach can more effectively create transparency in terms of how the Agile team interacts with the system. In this way, it becomes easier to highlight where these interactions are ineffective or damaging, and how these poor interactions manifest themselves as anti-patterns.

Agile teams should seek to classify problems and solutions along the following lines:

• An analysis of the system conditions and depiction of those which affect the Agile team and its work.
• A retrospective of retrospective actions to determine which solutions are still being enacted, whether or not they are still needed, if they have evolved into an anti-pattern and why.
• Does the problem emanate from the team or from the wider system?
• Where is the highest point of leverage in terms of the solution?
• What internal experiments can the team conduct where the ongoing effects may be felt outside the team and within the wider system?
• Can /do we address the systemic cause, rather than the symptom felt by the team?
• Which problems that we are now surfacing started as solutions?
• Will this solution be felt elsewhere within the team?
• What /where are the feedback loops between the Agile team and the wider system and can they be improved?

All of the above take place within an organisational culture that recognises and facilitates the active role of the Agile team in system change and improvement.

A significant challenge is posed by the fact that we now exist in a product development landscape where continuous development, integration, realised value and flow are seen as key in terms of business competitiveness, but the attainment of these goals is reliant upon the creation of a balanced and finely tuned agile ecosystem which recognises and addresses the anti-patterns which threaten this balance.

As agile frameworks are integrated into more diverse business environments and delivery models, anti-patterns continue to be not only a product and reflection of the environments in which they occur, but moreover, are often the result of a failure to undertake a systems thinking approach which recognises and is able to leverage the disruptive effect of Agile approaches within the wider system.

About the Author

David Johnston has spent over 15 years in higher education, teaching (among other things) software quality assurance, soft systems methodology and Agile frameworks, and has worked as a Scrum master and Agile coach in a variety of software development settings including media, retail, logistics and engineering.