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 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)

There is, however, an opportunity to see each dysfunction simply as an impediment for the team to improve upon.

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.

The extent to which each dysfunction is addressed will come down to many factors, one being the underlying business structure and its ability to respond to change.

Competitive market pressures and a constant demand to keep ahead will promote continuous improvement, but seeing agile as a fixed delivery process will not.

If you are unhappy with your development team, they may need more detailed guidance.

Better software requirements can help with this.