Truth, Lies, and Agile

When I first discovered “agile software development” in 2005, and experienced working in an “agile way”, the impact on me changed my career. People say you gravitate towards what you’re good at or enjoy, and agile helped reveal how much I value working together on a goal.

At that time, my mentors in agile software development reiterated to me the importance of using principles for experimentation, how technical practices are the systemic constraint of software agility, and how continuous improvement is not a meeting or post-mortem. They guided me with customer centricity, introduced new methods and programming practices, and motivated me to learn systems thinking.

But most of all, they kept me mindful that the manifesto for agile software development is about agile software development. Today, I lament the state of agile in the industry today: what agile is perceived to be, what people talk about, what experiences folks have with “agile transformation”. Similar to exploring the gaps between what Scrum is, and what Scrum isn’t, I’d like to do the same with agile. What follows isn’t an all-inclusive list; rather, the topics which I believe are misrepresented often and most damaging.

Throwback to years past: “Agile is a wasteland” and other labels

Circa 2020 and a well-known agile manifesto signatory is curating unbecoming labels for the state of agile. Certainly, now that it’s been said, agile is finally dead. After the infamous premature proclamation in 2019, there’s no way that pesky agile can survive this one… right?

Well, there’s an even peskier problem underfoot. See, somehow agile managed to keep going after a different signatory declared it dead in 2014. And that instance followed yet another different signatory burying agile in the ground while the audience at Agile 2009 cautiously listened in.

What a waste of time we engage in. Labels, accusations, assumptions, proclamations. For all the effort and thought we put into such behavior, the state of agile–however you see it from your place within the large-scale system–is unsurprisingly surprising. We’re shaking our fists at the most basic of systems principles (channeling John Gall here):

COMPLEX SYSTEMS EXHIBIT UNEXPECTED BEHAVIOR
– combined with –
COMPLEX SYSTEMS TEND TO OPPOSE THEIR OWN PROPER FUNCTION

That’s not to say coping or giving up is beneficial. Rather, since a system cares not about your desire for order or function, labeling it has no discernible effect. Agile is how you see it from your position within the system; you might consider, instead, how to use it wisely.

Or, if you’d prefer a gentle nudge, consider this throwback from 2015 and work with patterns, rather than labels, accusations, assumptions, or proclamations.

Do you need an “Agile Coach”? Probably not.

“Agile Coach” is a made-up thing. I’ve met countless people who hand me a business card with “Agile Coach” on the front. I have worked with stables of coaches from consulting organizations. I’ve lost count of the number of “Agile Coach” job descriptions I’ve been asked to review. Describing the responsibilities, behaviors, and activities of “Agile Coach” often varies among people. And in my experience, asking management to describe how the role delivers value to people comes out vague and equivocal. I’ve observed the role tends to be about “driving” things (process, training, change) and, speaking as someone whose career has primarily been this very title, often does more harm than good. 

Dangers of Optimizing for “Role Success”

Could you imagine what the human body would be like if each organ in the body were incentivized and managed according to separate role-specific criteria?

Perhaps we want all our body parts to pull their weight and be productive. The heart may be encouraged to increase its beats per minute by 15% day over day. Your poor eyes might be measured on reducing blinks to ensure more constant sight. The stomach could be subject to any number of possible scenarios – keep up the flow of digestion with less stomach acid (“do more with less!”) or ramp up productivity by creating more acid (“100% utilization!”). Just think about how your lungs could be subject to performance management! What a mess it would be… the human body would be so out of sync you might even question if it could remain functioning. No need to wonder; when we manage the body this way, the results are catastrophic.

If the detriment to complex systems is evident in managing parts, why do we similarly manage our companies to the tune of “Role Success”?

In Opposition to the Convention of Hiring: New Principles for Hiring

Annie looked down at the table and softly said to her fiancee, “I’ve never been this nervous, or excited, about a job.” Sitting on the table was a package from the company she had been interviewing with. The interview process had been unlike anything she’d ever experienced; she felt fairly evaluated, trusting of the company mission and values, and she knew the company was a perfect fit for her. The day prior, the company informed Annie she would receive a package–the very package on her table–and would contain everything needed: the company’s hiring decision, feedback, and other insights from the hiring process.

Annie took a deep breath and opened the package.

Towards a Culture of Teams

Have you ever been asked to work with a team, then observed team members interacting with each other, well… never?

The desire to transform an organizational culture to one inspired by teams is understandable. There is no shortage of evidence, both anecdotal and scientific, which suggests teams (and teamwork) are a competitive advantage. The desire for such results through the use of self-organizing teams has led to the popularization of teams as a common organizational design.

What I’ve found in my career, however, is a tendency for organizations to both manage and incentivize teams like a “matrix” (of individuals) despite the assumption or label of “team”. The net effect is predictable: silos within teams. Research has shown my experience to be prevalent and related to inattention of cause-effect relationships between people and their environment, plus absent knowledge of base conditions which invite teamwork (Devine et al., 1999).

Truth, Lies, and Scrum

I enjoy when people contribute their knowledge about agile software development to other humans living on planet Earth. The wisdom I’ve gained from such mentors aside, I think it’s terrific people are passionate, engaged, and excited enough to share their insights with others. As the most popular way to put agile values and principles in play, Scrum is arguably the subject most frequently written about in the agile community. Again, these articles and discussions about Scrum (and inferences about agile) are intended to assist, educate, and inform others in improving their careers and/or perspectives. This is terrific, too. Unfortunately, much of what is written tends to be misguided, misunderstood, or flat-out wrong. 

With respect and kindness for all those who take time to contribute, especially those cited as examples of problems, I’d like to share some truths of what Scrum is, what it isn’t, and how you can improve as a practitioner. This isn’t an all-inclusive list; just a handful of topics which I see misrepresented often. 

Open Space Conferences Aren’t

Two years ago, I wrote the following blog post discussing my general dislike for the Open Space conferences I’ve attended. While I attempted to convey a logical reason for my feelings—and how I propose a remedy—the post sat in my drafts list for concern of upsetting folks, or generally coming off as an incoherent rant.

Recently, I’ve observed a few folks I admire state concern over the prevailing use of Open Space, as well. This has given me courage to add my voice to the mix, as I believe Open Space conferences really aren’t.

A Ramble About Metrics

You’re sitting in the director’s office with a nervous feeling.

“So, about those agile metrics I asked from you…”, she says. Your stomach churns and pulse quickens.

How will you show the progress of agile transformation? How will you measure improvement in teams and people? And how will you avoid the trap of shallow metrics like say:do ratios and velocity?

Cross-Post: “Seeing the System With the WADE Matrix”

I’ve written a post in collaboration with Derek Wade to share a wonderful retrospective technique I learned from him. The “WADE Matrix” is a simple design to help retrospective participants identify opportunities for improvement, as well as see the cause-effect relationship of the system (beyond the team). This retro format has been my “go-to” method for new teams, new facilitators, and anyone interested in systems thinking.

Colleen Johnson, co-founder of ScatterSpoke (a highly recommended digital tool for facilitating retrospectives), has kindly hosted the article on her ScatterSpoke blog. You can learn about this retrospective technique by following the link below – enjoy!