Agile Canon
Pattern languages can help us understand complex systems. Read how pattern languages work, and how you can write your own. We are defining agility and its practices using a pattern language called the Agile Canon. Using the first five patterns in the Agile Canon, you can diagnose whether your team is agile, whether it can keep its agility, and whether it expands agility beyond the team’s boundaries.
While agile has zealots, it is not a religion. Agile is a scientific method that converts economic chaos to profit.
To sustain rapid adaptation and innovation, we need good agile managers. But management talent is rare, and agile management talent even rarer.
Danger lurks when executives and managers don’t understand agile. You can tell when managers don’t understand agile: they don’t use it themselves. Agile methods, Scrum particularly, are perfect for managing creative teams, including management teams planning and executing strategy (see Strategy Scrum Teams). [suth2014]
Management teams can use Strategy Scrum to manage themselves and more effectively finish important work. It creates greater resiliency, a more collaborative culture and deeper agile understanding, which helps their Scrum development teams succeed.
Are we agile? The highest performing innovators follow 6 progressive agile base patterns. To assess your agility, ask how well you follow those patterns. To stay agile, follow the agile base patterns indefinitely. Audit your business agility with this guide.
Leaders who publicly demonstrate agile methodologies and promote them top-down drive their organizations to sustain agile practices and succeed. But bottom-up agile transformations lack resiliency and generate cultural strife.
Agile methodologies are now widely recommended for managing software development, but most large companies require transformation from entrenched “waterfall development,” an intuitively appealing strategy that has created massive project disasters (see Why Software Fails). Traditionally, most large agile transformations have been pursued bottom-up. One approach starts with a single team, proves agile works, and then expands further and higher in the organization. Hopefully that agile team’s success inspires others to become agile. Another approach religiously converts all engineering teams to adopt a specific agile methodology, but leaves management teams and hierarchies, dependencies, promotion policies, job titles, roles, recruiting and budgeting in their previous form. The developers adopt agile, but the managers don’t.