Patterns of enterprise agile dysfunction

The most common dysfunctional patterns and behaviours I’ve seen in agile transformation programmes are:

• Chaotic
• ‘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
• Consultancies being paid to “embed” said frameworks
• Scrum master is micromanaging through daily task tracking
• Velocity is incorrectly tracked 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, problematic and ‘fragile’ (common industry pun)
• Poorly refined stories or not at all
• Lack of a dedicated PO to provide leadership
• Trying to make significant 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)

Dysfunction as opportunity

For each dysfunctional pattern or behaviour above, there is an opportunity to see it as an impediment for the team to improve.

Consistently doing this will improve the overall maturity of the agile process. Tailoring and embedding, retrospectives, root cause analysis, and continuous improvement practices will be helpful here.

The extent to which you can address each dysfunction will come down to many factors, one of which is the maturity of the business and its ability to respond to change.

Some dysfunctions arise from the underlying business structure and environment the team is working in. In this case, it’s incorrect to simply point the finger at the agile development team doing the work.

Competitive market pressures and a constant demand to keep ahead will promote continuous improvement. Seeing Agile as a standardised, rigid delivery process will not.

Making progress

The belief and experience that things cannot be changed is dangerous to teams and individuals.

However, if you are trying to improve on the current situation, then you are making progress, albeit sometimes very slowly.

The above list of dysfunctional patterns originates from a problem-focused view and can be helpful to drill down further into, if required.

An alternative approach to improving agile development is starting top-down and embedding desirable behaviours; something like the unoffical Scrum checklist by Henrik Kniberg will be useful.