Let’s face it, agile has been remarkably successful in transforming how organizations think about the ways they make and deliver products and services. What started off as a way for software engineers to deliver higher quality software more predictably has now become the default operating system for most organizations. The agile “transformations” these organizations have undertaken typically start off with the software engineering teams (no huge surprise I suppose) and then spread out to include other digital product teams, design and UX, marketing, HR and, in some instances, even legal and finance. The original Agile manifesto was written about software. The original Scrum guide was written with software developers in mind. 100% of the original authors of the manifesto were software engineers.
As the scope of agile and, perhaps more importantly, organizational agility grows beyond tech teams, other departments are being assimilated into a process that was never designed to include them. They are forced to think differently, to reframe their work and their ways of working in foreign ways that don’t naturally align with the way they’ve always done things. It’s no surprise then that many non-tech teams have begun feeling like agile is “being done” to them, in many cases against their will. They resent it. They reject it. In some cases they even hate it. A victim mentality begins to take shape. “I didn’t ask for this. Everything was just fine the way we were working before.” The resentment grows and soon there’s a clear us vs them mentality in place where “they” are “doing this” to “us” which keeps us from doing the best job that we can. This makes us look bad.
My advice: Stop it. There are no victims in an agile transformation.
Is Agile the silver bullet for all that ails the business world? No.
Can an application of agile principles designed to encourage learning, continuous improvement and a focus on the customer help everyone in the company to deliver more value to their customers? Absolutely.
First and foremost, you, your colleagues in engineering, your boss and your CEO are all interested in making your customers successful. Can we agree on that? (I hope so, otherwise you have bigger fish to fry.) Second, a deeper understanding of your customer, reduced amount of risk, increased flexibility (aka agility) in what you’re working on and when to change course all contribute to the faster delivery of value, yes? (Again, I’m assuming we’re in agreement here.) Now, I’m aware that the way Agile, scrum and SAFe are implemented doesn’t always reflect these values however, this is exactly where your opportunity lies for collaborating with your colleagues to build a better and more inclusive agile process inside your organisation.
Instead of crossing your arms, stomping your feet and saying, “That’s not how we work and I refuse to take part in this,” consider this approach, “The work we do typically takes longer than two weeks. In each sprint we believe we can deliver 30% of our total contribution but as feedback comes in from sprint to sprint, we can continuously adjust the subsequent 30% we contribute to the project.” What you’re doing there is acknowledging that the process as currently designed doesn’t support how you work, explaining what you can do within the existing framework and how you’d use it moving forward to adjust future contributions. More importantly you’ve started a dialogue with your colleagues about how best to collaborate in this new world. You’re not a victim. You’re a partner. Partners negotiate. They experiment. They retrospect and they adjust course based on learnings.
I find that the application of the scrum mantra, “inspect and adapt” to the process itself is often missed by teams. Is any process 100% correct the first time a team tries it? No. Your company’s (or team’s) version of agile is going to be different than at other companies. If you don’t like the way it’s working, bring those concerns to your retrospectives. List, clearly, the impact of this suboptimal way of working and the potential benefits of trying something new. Remember, you only have to live with any process change you make for, at most, one sprint. There’s almost no risk in trying out new ways of working together.
Pushing back against a new way of working with a victim mentality leads with negativity, a wall your colleagues now have to climb over to reach you. Leading with positivity, objectivity and a willingness to learn together lays a foundation for ongoing collaboration and team health. If that’s not how your department is being approached don’t respond in kind. Instead, offer your concerns, potential impacts and suggestions for process experiments. If my assumption earlier still holds, you all have the same goal in mind — making the customer successful. And if that’s the case, no one is a victim. We’re all colleagues continuously searching for a better way to work together.