On October 21, 2020, I led a Toronto Agile Meetup “Quicktalk.” Here’s the promotional blurb. “What is there about Agile that hasn’t already been said? Lots, actually, but much of it is “elephant in the room” stuff. We know it’s there, and it’s probably big, but we pretend not to see it. Maybe it’s time to start talking about it.” One of the issues I’ve observed is that we don’t recognize our own dogmatism. A lot of people have a preference for one of the Agile frameworks. This can be for any of many reasons. Maybe it’s the one we learned first, the one for which we have our most recent (or only) certification, the one the “cool kids” are talking about, the one we know the most activities for, the one that “just feels right.” Maybe it’s something else. But we just know our framework, activity, method, process or other solution is the right one. We risk becoming a bit, well, fanatical.
Which leads to another conversation. Agile practices were designed to replace current processes, not pile on. They are instead of, not in addition to.

In my long-ago Scrum training, people from a large financial institution, objected to almost everything our instructor told us. “We can’t do that,” they whined. “Audit won’t let us.” I might have called out, “How do you know? Have you asked them?”

As Agilists, our role is to improve the way people work, not add to their burden. Certain reporting requirements and other practices become redundant when teams work in an Agile way. Does the corner office really need that status report when they can see the work board? Is this security practice still relevant?

Conversations with our bosses, partners and clients can create realistic expectations. Can we hold them? Do we hold them? The same sort of conversation can help us – and our bosses, partners and clients – understand whether agile practices and actually address the business problem. Or which practices address it and which add no value.

A few days ago, a colleague asked me what I would recommend new Agilists do to build their knowledge and credibility. I suggested they learn about business – not just business, in general, but their business. We need to understand what are the business results organizations are hoping to achieve through Agile practices. Are we getting them? Is what we’re doing helping? The software industry has done well to move from a process focus, to a program focus, to a product focus. The next focus must be an outcome focus. What is the point? What are we getting? How is it working?

One of the most disturbing things I have observed is a sort of “Agile Arrogance.” I see Tweets about, “these guys just don’t get it,” and comments about “management morons.” Why are some people so dismissive about people who don’t buy the ideas they’re selling? (Recall the dogma section.) I suspect they define success in their jobs as “people do what I tell them.” Is that really the deal? We are hired and paid for our expertise and experience. We offer our best support in the best way we can. People, including those who hired us, won’t always take it. Recall Jerry Weinberg’s Third Law of Consulting: “Never forget they’re paying you by the hour, not by the solution.” Our job is to make the offer. We offer our mad programming, facilitating, coaching, change management and people skills and experience.

These things we offer are more likely to be appreciated, and our support accepted, if two other traits are in place. You can’t be certified in them and they may not show on your resume. But people know when they are present. They’re worth discussing – and practising – if we are to improve our profession and our own chances of success as practitioners. We need to develop humility and curiosity in ourselves and nurture these traits in others.

We need conversations about all these things, where we use empathy and confidence, in equal measure. What I’ve seen, in over 50 years in the workplace, is that real confidence comes from knowing you don’t have all the answers and being OK with that because you’re going to find them – or you’ll find something better on the way.

 

There’s an old saying that if all you have is a hammer, everything looks like a nail. Are Scrum, kanban, SAFe, unSAFe, etc. our hammers? What if our favoured flavour of Agile isn’t right for the context? What if Agile’s not the answer? What if we open our minds to the possibility that some other solution will work? Do we talk about this? With our employers and clients? Amongst ourselves? Do we even think about this? Or do we introduce our preferred frameworks, structures, tools and processes and make sure everyone does them correctly? Perhaps it’s time to think about how we understand the first value of the Agile Manifesto
They may have hired us to teach teams to use Scrum properly and get all those user stories lined up in Jira with the right amount of story points to the appropriate decimal place. How is that going to help our clients, our customers or our organization?

Perhaps it does that. But do we know? Do they know? When we have a constructive, two-way conversation about the practices they and we are introducing, we contribute. Do we wait for the all-singing, all-dancing, all-ducks-in-a-row. super-technicolour Agile solution to come along, all signed-off and budgeted and staffed up with seals of approval all over it? Change does not have to be a big, hairy deal. We can make change non-threatening – for everyone – by framing change as an experiment. “Let’s try this small thing for a short time and see if it works. We’ll learn something. We’ll use the people and budget we already have. And, if it doesn’t help, we’ll stop it.” Nothing will convince people you are serious about experiments and empiricism like cancelling a change that didn’t work out.