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, 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?
Team building has always been a challenge, not just since the advent of agile frameworks and the resulting emphasis on self-organization, engagement, and achieving a valuable objective. This post covers four team building mental models — or concepts — that have proven useful in understanding the context of creating agile teams: from Taylorism to Tuckman to Lencioni to Dan Pink.
“Accelerate” [advertising] is a must-read book for anyone involved in building agile organizations and teams. It lays out a path to success based on a statistical analysis of data. It also puts an end to the popular narrative that ’becoming agile’ is somehow a fuzzy process. The data shows that there are patterns at all levels that successful agile organizations share.
Master autonomy purpose — in this article, I present a slightly different way of viewing agile maturity, through Dan Pink’s lens of Mastery, Autonomy, and Purpose; as a simple and useful way of fostering conversations and ensuring all relevant perspectives are considered.
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 you 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. This 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.
This website uses cookies so that we can provide you with the best user experience possible. Cookie information is stored in your browser and performs functions such as recognising you when you return to our website and helping our team to understand which sections of the website you find most interesting and useful.
Strictly Necessary Cookies
Strictly Necessary Cookie should be enabled at all times so that we can save your preferences for cookie settings.
3rd Party Cookies
This website uses Google Analytics to collect anonymous information such as the number of visitors to the site, and the most popular pages.
Keeping this cookie enabled helps us to improve our website.
Please enable Strictly Necessary Cookies first so that we can save your preferences!
