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.
“Persuasion is where you come up with a way to sell a new idea to your boss. This is pretty much what the Agile Manifesto was for.” Giles Bowkett
Ironically, Giles reveals our dirty little secret: we must sell our ideas to management because, without them, we cannot grow Agile in our organizations beyond what we’re experiencing today. Giving up is a cop-out and ensures mediocrity by leaving the “gap” between developer and manager unsolved. It’s time to stop with the anti-Agile posturing and, instead, try a new experiment where we speak Agile in a language understood by “people who don’t do things.”
Ignoring the Problem is Anti-Agile
Our most creative, progressive Agile thinkers are moving on, leaving behind critical people that can help us create more human-friendly, Agile organizations. I recently published an article highlighting harsh statements by Agile leaders exposing the too-common disconnect between Agile principles (“being Agile”) and misguided practices in the name of “doing Agile”. The article showed how traditional management thinking has fueled the ignorant assumptions about Agile software development. Too often, we now have “Agile in name only” organizations that create more pain, not less, and are characterized by a devout resistance to change – but no shortage of consultants happy to continue billing hours. Small wonder many claim we should detach Agile values from the word “agile”.
At the same time, killing our scarred child seems like the worst kind of waste. Since when was our response to a problem decidedly anti-Agile? Giving up on the problem abandons “individuals and interactions” and, worse, ensures the subversion of Agile continues to grow!
We should have expected stiff resistance and pushback from mid-level managers and protected specialists, because all we told them was “Get out of the way!” They advanced their careers by focusing on individual performance and mastering a command-down, please-up mentality. Further, many organizations host intense political battles over territorial control; promoting change can make managers vulnerable to resentment and sabotage. Most managers do not practice Agile themselves, so speaking to them about Agile in the developer-centric language of the Agile Manifesto for Software Development practically assures confusion. Small wonder that Agile is perceived to be “for developers only” and assumed to be a change in how we execute a low-level process, not how the organization—particularly management—behaves.
Stop Settling for Bottom-Up Transformation
Where does this leave us? Without Agile language that speaks to these fears of management, our organizations will continue to struggle with challenging bottom-up transformations, much like we’ve experienced in recent years. Bottom-up transformation, typically led by developers, creates additional and unnecessary cultural hurdles for change to overcome, primarily in “selling” the idea to management and non-software verticals.
However, when organizational leaders—especially those serving in executive roles—promote a strong Agile message, we create top-down transformation and a pathway to agility that is far easier. When systems of work are expected to reflect Agile principles, no selling is needed; middle management will be more inclined to change based on the influence of respected authority. In a top-down transformation, we spend more time collectively pursuing a better outcome for our organizations, rather than fighting the oppression of the status-quo.
Therefore, it appears obvious that the people we’ve singled out, and given up on, are critical to our continued evolution of Agile. Abandoning them is not in our best interest, especially knowing that organizational leaders are often already disengaged. We need to engage and inspire them by speaking in a language that connects them to the organization through Agile values and principles.
We Need Insight, Not Complaints
If we agilists are responsible for comments like “Agile is a cancer”, then we should fix the problem ourselves and stop whining that people are abusing Agile. After I published “The Subversion of Agile”, Dan Greening at Senex Rex contacted me and pointed out that whining about grouchy anti-Agile “friends” isn’t going to change anything (other than perhaps increase their Twitter follower count). In classic coaching form, he asked: “What can we do about it, then?”
The answer lies in fixing the problem through the use of more legitimate, disciplined Agile practices. When we try small, focused experiments informed by the real values and principles of Agile, outcomes improve. The key to enabling the trust and shared vision necessary to take the first steps toward a next-generation Agile business platform is the transformation of our software manifesto to an organizational conversation. I believe that the Agile Base Patterns could help cure the cancer affecting Agile today.
Agile Base Patterns as a Cure
The Agile Base Patterns describe a set of patterns that organizations exhibit to enable the use of methodologies informed by Agile principles (readers are encouraged to review the link provided above for a thorough explanation). In summary, Agile organizations:
- Measure economic progress
More than simply guessing at financials to approve work! An Agile organization measures value, in the form appropriate for the mission, and uses leading indicators to steer progress.
- Proactively experiment for improvement
An Agile organization thrives in a culture of continuous improvement at all levels and leverages feedback loops to provide guidance.
- Limit work in progress
There is no mistaking activity for accomplishment. An Agile organization emphasizes getting things done, decomposes work into valuable pieces, and leverages “pull” systems of work to ensure flow.
- Embrace collective responsibility
Agile thinkers have learned to create collective responsibility in development teams by promoting collective code ownership and reducing silos of knowledge. But at the organizational level, when outcomes miss the mark, leaders of Agile organizations examine causes in the environment before simply blaming development teams.
- Solve systemic problems
Agile organizations are not content to put a coat of paint on the problem. They pursue deep causes of their problems and are not afraid to cross team and organizational boundaries to obtain the outcome desired.
The Agile Base Patterns show that every aspect of business benefits from Agile thinking. We’ve spent years reiterating the philosophical nature of Agile, but the Agile Base Patterns take a focused stab at describing behaviors precisely, speaking to culture and business activity at all levels.
The patterns avoid software development specifics, creating a new, more general language that organizational leaders and managers can understand and appreciate. Management no longer needs to fear looking misinformed or worry that “developer-speak” conflicts with business reality. Frustrated change agents no longer need to feel like they’re speaking to a brick wall. Further, the Agile Base Patterns illustrate what “being Agile” means and why these cultural behaviors preclude our ability to create—and execute—better systems of work (“doing Agile”).
Agile is not a Cancer
With clear principles and patterns in hand, we can reduce the anti-Agile rhetoric and generate the insightful thinking our collective organizations need. With this knowledge, we can conduct meaningful and intuitive conversations with non-software, non-technical colleagues that need our help. By translating the Agile Manifesto into a non-developer, behavioral format, we can collaborate with leaders and managers to try small experiments in organizational change.
The Agile Base Patterns negate the rampant misinformation that has corrupted a great deal of people. There is nothing about “daily standup meetings”, “story points”, or sticky notes on a wall. Just simple, concise cultural behaviors that we can test for and adapt to. If we can get managers and leaders to focus on the organizational environment, i.e. the Agile Base Patterns, our teams and product strategists can focus on execution enabled by an Agile culture.
By starting with a language that offers a definition of the Agile organization, we now have the ability to engage more people rather than isolate them. It’s not that “they don’t get it” and “don’t do things.” It’s that we haven’t addressed the root cause of Agile failure and haven’t done the right things to encourage collective knowledge of Agile. Let’s not settle for hoping our Agile stakeholders adjust their frame of mind through following rules and process; instead, speak to them in the context of their organization.
Your next Agile conversation might be the tipping point needed to cure the cancer we’re suffering from today!
Special Thanks
A huge thank you to Dan Greening and Ryan Ripley for peer reviews.
We welcome guest blogger Zach Bonaker to Senex Rex blog this week. Let us know if you’d like to guest blog for us.
Senex Rex tackles challenging problems at the agile management frontier. We help companies, teams and leaders accelerate and sustain value and quality production, so we can all live better lives. We collaborate with the best minds in the business. Contact us for help with agile transformation, turnaround management or performance improvement.
Great article.
I would challenge your assertion that you need to “get better and more strict” with Agile. I would posit that managers have to find better ways to align themselves with the company goals. If we can show how our departments running in Agile are functioning better towards corporate goals I think it will come down to base line economics – Team Agile makes the company money. Team non-agile doesn’t make that much money. Team Agile wins.
Now how to do that is difficult. I think the right KPIs can either aid or derail a department. I have seen the trainwreck of KPIs. So beyond that I am not sure how to push that forward.
Pingback: 003 - Agile for Humans | Agile Answer Man
Pingback: AFH 003: Agile is a Cancer | Ryan Ripley
Pingback: 5 Base Patterns to Guide Agile Teams | Ryan Ripley