Common dysfunctional patterns of Agile I’ve seen in digital transformation programmes that I’ve worked in are:
- ‘we don’t need documentation or process’
- Big room planning too big and communication poor
- Agile framework is just used as an enterprise planning process
- Consultancy being paid to big bucks to “embed” said frameworks
- Scrum master is micromanaging through daily task tracking
- Velocity is not tracked properly and team members feel overloaded
- Management attend standups for progress updates
- Standups are run without board and / or stories aren’t opened nor referenced in the daily updates
- Lack of automated test and CI tools makes it manually intensive and problematic and ‘fragile’ (common industry pun)
- Poorly refined stories or not at all
- Lack of a dedicated PO to provide leadership
- Trying to make big architectural changes within sprints
- Vendor procurement decisions executed in an agile fashion
- Using Agile to manage non-software (or non-artefact producing) processes
- Business or other management don’t respect the Agile / Scrum process and commonly “break” sprints with ‘urgent items’
- “collaboration” – whatever that means
- JFDI (people management command of the last resort)
Seeing dysfunction as opportunity
It’s worth pointing out that for each dysfunctional pattern or behaviour above, there is an equal opportunity to see them as just impediments and (as a team) work to fix them and improve the maturity of the Agile process. Tailoring and embedding, retrospectives, root cause analysis and continuous improvement practices will come in handy here.
Keep in mind that some of the dysfunctions will emerge because of the underlying business structure and operations the team are working within rather than Agile itself. It’s not right to simply point the finger at Agile or the agile team as the cause (or responsible parties) for the dysfunctions in this case.
The extent to which you can (or need) to remediate the above dysfunctions or alternatively just accept them will come down to many factors, one of which is the maturity of the business and its ability to respond to change. Competitive market pressures and a constant demand to keep ahead might help the cause. Seeing Agile as a standardised, rigid delivery process will not.
I think it’s the belief and experience that things cannot be improved that is dangerous to teams and/or individuals. However, if you are actually trying to improve on the current situation then you are making progress, albeit sometimes very slowly.
The above list is from a problem-focused view and can be used as topics to drill down into further if required. However, an alternative approach to improvement in agile teams is starting top-down with desirable behaviours, something like the unoffical Scrum checklist by Henrik Kniberg
Good luck walking the path to the Agile holy land. It’s a difficult journey but one worth taking.
Frank Ray & Associates is a software engineering consultancy that builds high quality software for businesses.