Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage News Organisational-Level Agile Anti-Patterns - Why They Exist and What to Do about Them

Organisational-Level Agile Anti-Patterns - Why They Exist and What to Do about Them

This item in japanese

Agile anti-patterns can affect organisations, morale, and quality if left untreated. The critical first step is acknowledging the existence of the pain point. Effective root cause analysis helps to understand what causes the anti-patterns to arise in organisations, where actions can be taken to address those causes.

Patrick Martin, a Scrum Master, spoke about addressing agile anti-patterns at Agile Tour London 2020.

Agile is widely misunderstood as being a methodology that delivers solutions faster and cheaper. Ultimately it can be, but not necessarily at first and perhaps not for quite some time, Martin argued.

Agile brings anti-patterns into the wide-open, Martin said. It can take time and effort to resolve them and indeed, some of them may not be resolved due to organisational intransigence or unreadiness to start the process of culture-metamorphosis.

Martin said that many firms put too much emphasis on technical ability and not on the soft skills that act as lubricant. Examples of these skills are the ability to work with others, empathy, listening, not rushing to judgement, willingness/openness to try out new ideas and being humble and accepting when one may be wrong.

InfoQ interviewed Patrick Martin about addressing agile anti-patterns in organisations.

InfoQ: How would you define agile anti-patterns?

Patrick Martin: An anti-pattern is an activity or behavior that stops, prevents, slows-down, or compromises the:

  • Production of a product
  • Delivery of a product
  • Quality of a product

In short, it’s anything that gets in the way of the efficient planning and delivery of a quality product into the hands of the customer/end-user.

InfoQ: What kinds of agile anti-patterns do you see?

Martin: It would be easier to ask the question that elicits the shorter answer! :-) I’m sure everyone who reads this can think of a whole bundle of anti-patterns, but an anti-patterns are found through their negative effects, some of which are:

  • Lack of line of sight to value stream
  • Sense of slow velocity
  • Extraordinary high number of Acceptance Test failures during PO testing
  • Little/no continuous improvement
  • Waterfall mindset/practices still being applied where it’s not appropriate to do so
  • Poor team work
  • Lack of interdisciplinary collaboration when creating artifacts
  • Lack of cross functionality within teams
  • Lack of team autonomy
  • Poor morale
  • Lack of vision
  • Fuzzy Sprint Goals

If we sense any of the above, then an anti-pattern or several are at play and then we start the work of finding out what they are exactly.

It’s important to note that anti-patterns, in my mind, are not just transgressions of ceremony best practice. If all that’s wrong with a team and what it does is that its standups last a minute or two more than 15 minutes, then I don’t see that as an anti-pattern.

InfoQ: What causes anti-patterns to arise?

Martin: Poor agile transformation. Perhaps agile transformation attempts were not allowed to be fully or effectively enacted. Many orgs believe agile transformation is a bottom-up affair, something that only development teams do.

That’s a massive misconception. Transformation is a culture shift from top to toe of any organisation including its non-operational departments such as finance and HR functions who make decisions and policies that shape how the rest of the org behave and do things and plan.

Other reasons are fear of losing real or perceived rewards/status/security. These fears are natural and worthy of empathy but if they’re not addressed, it indicates a lack of effective, credible cultural change agents within organisations themselves.

InfoQ: How can teams deal with these causes?

Martin: Attuned radars to things not seeming as good as they should be … followed by effective root cause analysis. Once root causes are identified, then appropriate action should be taken. There are so many root causes and even the same root cause in different teams may need different approaches/remedies because the dynamics, people, and circumstances are not identical.

New teams should be set up with adequate coaching to help oversee the fledgling team and to spot and address concerns when they arise.

An example is an anti-pattern that unfortunately I was not able to resolve, where two highly interdependent but physically separate teams were formed based on the front end and service layer. The dependency landscape was wholly avoidable and it was highly problematic, but the reasons were political and way above my pay grade to protest too much.

I’ve experienced interpersonal disputes, suspicion of a developer’s motives based on certain individuals’ past experiences, blame culture, and lack of trust. 1-2-1 conservations with all parties went a long way to help. Some individuals unfortunately were not ready to be helped and they decided to pursue other opportunities that they flourished in and that’s ok too. Agile is not for everyone, and it’s important that everyone finds a place where they can do well.

Agile is good at bringing problems to the surface very starkly. This forces everyone’s hand to do something about it one way or another. IT doesn’t mean we can fix everything; sometimes the solution is for the individual to walk away. For others, it’s to stay and try to change things. I respect both pathways.

InfoQ: What can organizations do to prevent anti-patterns?

Martin: If an organisation is truly earnest about agile transformation, here’s some things they need to do:

  • Have an open mind and view IT as a core conduit for business/revenue, not just another cost-centre
  • Appoint agile coaches to engage with all strata of the organisation and to find out how things work and don’t work
  • Identify the business’s value streams and restructure the organisation so that each new team/department is aligned to one value stream to which everyone has line of sight.
  • Do not appoint people to product owner or scrum master roles just to find a spot for someone to fill.. If they are a good fit, then fine, but if not, don’t do it!
  • Introduce diagonal-line line management so that everyone has someone they can turn to outside the team for non-delivery matters
  • Appoint agile coaches as mentors to every tier of the organisation ensuring all parties meet on a regular basis for help, coaching, mentoring, training and even venting! It’s natural!
  • Regular agile-adoption surveys and feedback loops within teams and to C-Suite

Firms need not carry out a "big bang" approach. Just identify one small, low risk value stream and reorganise the teams that align to it and see what happens. Such an approach would be the least risky and if something goes wrong, as it will, little or no harm will be done.

Rate this Article