TL;DR: Agile Failure Patterns — Why Agile is Simple and Complex at the Same Time
Agile failure seems to be increasingly more prominent nowadays despite all the efforts undertaken by numerous organization embarking on their journeys to become agile.
The funny thing is: Who would disagree that the four core principles of the Agile Manifesto —
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
— are derived from applying common sense to a challenging problem? Moreover, that the application of those principles might be suited to fix numerous organizational dysfunctions and reduce an error-prone and complex social setting to maybe just a complicated one?
Are you—as a scrum master or agile coach—experiencing more communication kerfuffles with “your” team? Is its speed of improvement stalling? Are you under the impression that the team is slipping back into old habits and patterns? Maybe, it is time to run a reverse retrospective where your share your observations with the team.
Learn how to run a reverse retrospective to realign with your scrum team.
Supposedly, becoming agile is a journey, not a destination. Which is a convenient narrative if the viability of your consultancy depends on selling men and materiel. The fuzzier the objective of an agile transition the less likely there will be an agile audit addressing the return on investment question the customer might have.
Moreover, a fuzzy objective such as ‘we want to become an agile organization’ is probably the reason for applying the same methodologies indiscriminately to every organization—a one size fits all approach for agile transitions.
However, what if not every organization embarking on a transition to agile practices is meant to become a teal organization or a holacracy? What if being late to the agile transition party is instead a deliberate choice than a manifestation of hubris, ignorance or leadership failure?
Read more on why feedback loops in the form of an agile audit are beneficial for organizations and teams alike.
TL;DR: Use Burn-Down Charts to Discover Scrum Anti-Patterns
A burn-down chart tracks the progress of a team toward a goal by visualizing the remaining work in comparison to the available time. So far, so good. More interesting than reporting a status, however, is the fact that burn-down charts also visualize scrum anti-patterns of a team or its organization.
Learn more about discovering these anti-patterns that can range from systemic issues like queues outside a team’s sphere of influence and other organizational debt to a team’s fluency in agile practices.
TL;DR: How to Measure Agility of Organizations and Teams
Is every organization suited to become ‘agile?’ If so: How to measure agility? And if not: Wouldn’t it be great figuring that out before embarking on a futile and expensive journey?
On February 3rd, 2018, 20-plus people will join a hackathon to build an agility assessment framework based on this taxonomy. The goal of the workshop is to provide the first version of a tool that empowers agile practitioners to measure agility, be it an organization’s suitability for agile practices or a team’s progress on its path to becoming agile.
After rebuilding an existing application on a new tech stack within time and under budget our team had an overall retrospective with stakeholders this week to identify systemic issues. We found more than 20 problems in total and derived eight detailed recommendation the organization will need to address when moving forward to the next level of agile product creation.
Read on and learn how we achieved this result in under two hours with an overall retrospective attended by 16 people.
