Agile CanonThis is Heidi Helfand, Director of Agile Coaching at AppFolio. Senex Rex offered its blog to let folks know about a conference called Agile Open Southern California, on September 10 and 11, 2015 at UC Irvine, and I’m grabbing it!
Creative people with limited resources, such as product managers, developers, CEOs, investors and artists, must choose which items to assess, staff or fund. They compare value, cost, flexibility and risk to make a decision.
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.
Context: Plenty of data informs us. We can forecast when things will happen. Our progress metrics are aligned with long term goals. But externalities impede our progress: competitors emerge, delays harm us. We are passive victims of outside circumstance.
We suspect unknown dangers, economic loss, and growing ineffectiveness. Our friends reassure us, choosing their words carefully. Existing data is eerily stable. We aren’t learning anything new.
Dustin Mattison interviewed me on how one could apply agile principles to supply chain management. The interview shows how to map Agile Base Patterns to a non-software field.
You can listen to the podcast here: The Five Characteristics of Sustainable Agile Methods, from the Future of Supply Chains blog.
As we speak, agile leaders are killing their children. Dave Thomas proclaims that Agile is now for “people who don’t do things”. Giles Bowkett argues that “Scrum should basically just die in a fire.” Alistair Cockburn stood in front of Agile 2009 to proclaim “I come to bury Agile, not to praise it.” Like spoiled children whose oversights were exposed, the shock jocks among us are happy to pound their chests in defiance, yet simultaneously cry over their own spilled milk.
Context: It takes us time to decide to fix problems, and we let some problems fester because we don’t want to get anywhere near them. When we are on a team, we can blame someone or something else for a problem, and often do. We might blame our own permanent flaws for a problem, feeling guilty. None of this blaming seems to fix anything, but we stick to our comfort zone. Pitching in to fix problems can associate us with the problem and put us in danger. It might be a tar baby.
We are responsible for an outcome if our action or inaction affected it. People assert we are “responsible for a failure,” if we could have prevented it. We assert we were “not responsible for a failure,” if we were not authorized or equipped to prevent the problem that caused the failure. People characterize us as “a responsible person” if we act to prevent or recover from failures.
Creative organizations, teams and leaders often encounter problems, as they explore new frontiers.
Context: We can study others who succeed, imitate their activities and gain their skills. But these activities create nothing new. Once we have reached their capabilities, how do we know if we’ve improved?
Creative efforts operate in an economy, a system where people manage limited resources to maximize return and growth. Economies drive everything. They need not involve currency. We can measure philanthropic efforts by the number of lives saved per unit of volunteer effort. We can measure companies by price-earnings ratio, market share, civic contributions, employee welfare, or religious conviction. We can measure artists by profit per work hour, the number of event attendees, the number of references on a social network, the devotion of fans, the artist’s technical improvement, the artist’s personal satisfaction, or the political effect of the artist’s message.
Join Dan Greening for a conversation on Agile Leadership Patterns on June 17, 2015 at 6:00pm in Santa Barbara, California. Remote participants can join the meeting online. Dan first used and researched Scrum and agile methods at Citrix Online, several of his publications discuss practices and data from that early work. Now, Dan has distilled our understanding of agility into a small set of practices: if you do them, you’re agile; if you don’t, you’re not.
Please register and mark your calendar!