Agile Antipatterns and what we can do and can’t do about them - Agile Oxford - September 2024

Ever worked on an item that’s in the backlog, or sitting in a queue? Ever underestimated a ticket just to get it into the sprint? Ever had someone get upset because you refactored their code? Ever skipped those tests because you just needed to get it done? Ever had to estimate work in hours or days? Ever spent more time and effort to justify an expense than the cost of the expense itself? Ever been told what to do rather than what the outcome should be? Ever been expected to provide an estimate when there are unknown unknowns?

During my 25 years working on software projects doing product ownership, software engineering, technical leadership, coaching, and mentoring, I’ve experienced all of the above. And frequently. Agile is a practice, something we need to feel deep down, something to champion. But often Agile becomes a box-ticking exercise for process freaks. We go through the motions of the ceremonies, but are we living the spirit of Agile? Do we really know why we do what we do?

In this workshop we will work together to identify some Agile antipatterns we have encountered, discuss why we think they happen, and identify what we can, or maybe can’t, do about them.

1. Mike Harris, Oxford Agile Meetup, Wednesday 18th September 2024
Agile Antipatterns
And what we can, and maybe can’t, do about them

2. What is an antipattern?
?
?
?

3. •An antipattern in software engineering,
project management, and business
processes is a common response to a
recurring problem that is usually
ineffective and risks being highly
counterproductive.
•Coined by Andrew Richard Koenig
•I’m using it here to mean a “practice
that we observe that seems to be being
accepted, but which appears to
contradict the principles of Agile
software development or which
contrives to be Agile, but only in name”
What is an Antipattern?
Credit: Martin Fowler
There are lots of different definitions and perspectives (of course)

4. Examples
From my own experience
•Working on items in the backlog
•Git rage
•An important API
•Demanding letters

5. Group Exercise
Our own experience with Agile antipatterns
•Round of introductions - who we are, what we do, who we do it for, where we live,
something we like to do in our spare time
•Discuss some anti-patterns we’ve encountered in our careers and the impact of
them
•Try to steer clear of why they were happening; we will come back to this
•Pick one to two examples to describe to the wider group
•Choose a person to describe them back to the wider group
•When describing them, describe the observation, not the perceived impact at first;
we’ll let the wider group make suggestions first

6. So why are we doing this?
My examples (and possible causes)
•Working on items in the backlog (getting hung up on the process/procedures
and forgetting the principles, misunderstanding of Agile, following senior
management without calling it out, insecurity and egos)
•Git rage (ego, personal insecurities, personality conflicts)
•API without tests and with errors (Dunning-Kruger effect, prioritising low cost
over quality, recruiting under developed engineers and not developing them,
using junior developers on projects, management ignorance or carelessness)
•Demanding letters (siloed product organisation, blinkered thinking based on
personal/team goals and delivery, inexperience product/systems people, egos,
Dunning-Kruger)

7. Group Exercise
The whys and wherefores
•Back into your groups
•Take your group’s one or two examples, or another more suitable
•Discuss why they were occurring
•Discuss whether there was something that was in the control of the team to
effect change (internal team behaviour), or was it an external influence?
•Feedback to the group

8. Internal vs External
What we think we can change, and what we think we can’t

9. Are we drinking the Agile Cola?
A re-cap on the Agile Values

10. Manifesto for Agile Software Development
We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:
?
?
?
?
That is, while there is value in the items on
the right, we value the items on the left more.
https://agilemanifesto.org
Agile Values

11. Manifesto for Agile Software Development
We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on
the right, we value the items on the left more.
https://agilemanifesto.org
Agile Values

12. Group Exercise
Do we hold the Agile principles?
•In your groups, discuss whether we think:
•The Values are held by our organisations?
•There parts of what we do that are intrinsically negatively affected by the
structure and operation of our organisations?
•There is anything we can do about this?

13. People and
Organisational
Issues
And whether we can do
ought about them

14. People and Organisational Issues
My examples
•Working on items in the backlog (getting hung up on the process/procedures and
forgetting the principles, misunderstanding of Agile, following senior
management without calling it out, insecurity and egos)
•Git rage (ego, personal insecurities, personality conflicts)
•API without tests and with errors (Dunning-Kruger effect, prioritising low cost
over quality, recruiting under developed engineers and not developing them,
using junior developers on projects, management ignorance or carelessness)
•Demanding letters (siloed product organisation, blinkered thinking based on
personal/team goals and delivery, inexperience product/systems people, egos,
Dunning-Kruger)

15. Acceptance
Not in the sense of tests

16. Acceptance
Of the World the way it is, not how we wish it to be
•Often we can get het up in process and practices and getting people to do
them
•As coaches we may keep blaming the organisation and its people for not
getting it, and we keep repeating the same mantras
•This refusal to accept reality can be a lot to do with ourselves
•To effect change we first have to accept things as they are
•This includes ourselves

17. Non-Acceptance
Of the World as it is
•By not accepting things, we’re trying to change reality
•Reality doesn’t respond kindly to this!
•People and organisations tend to resist change
•This can lead us to struggle
•This can lead us to resentment
•This leads us to Hell

18. Group Exercise
Are we accepting of the real world?
•Back into your groups
•Thinking in terms of frustrations you have within your projects or organisation
(or your wider life), are there opportunities for greater acceptance?
•How does this acceptance feel?
•Are there any new options that appear out of this acceptance?
•Discuss with your group and feedback to the wider group

19. Final Group Exercise
Gathering our learnings and effecting change, effectively
•Back into your groups
•Recognising the anti-patterns, the organisational and people related issues
and limitations, our attitude towards them, and bearing the Agile Values in
mind, how might we unblock and move forward?
•What one thing can we do differently tomorrow morning?
•Discuss with your group and feedback to the wider group

20. Thank You
https://xtreamlab.net
https://mbharris.co.uk
Get in touch:
[email protected]
[phone]