There Are No Victims in an Agile Transformation

There Are No Victims in an Agile Transformation

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. 

Dan Leeds

Improving delivery & results

4 年

I think one of the biggest causes of resistance is over-emphasis on process / methodology over principles. In most of these cases in knowledge work, what’s being produced are documents - less complex than software. Kanban adoption model can be a lot more respectful - understand value stream, start where you are, make work visible. Start improving. People still have to agree that they can work better, but it doesn’t have to be premised on ‘going agile’ meaning adopting scrum as a complete shift.

Jazmine V.

Quality Supervisor

4 年

Thanks for posting! I loved this article.

John Westgarth

Delivery Manager at Culture Amp

4 年

Thanks Jeff - love the way you have laid this out - with a focus on learning, improvement and customers. These three lenses give teams (any team) an entry point into agile before starting to adopt the practices that can bring these to life. ie its much easier for a team to see the value in a conversation about how a customer responded to something when it was shown to them, before finding value in the planning aspects of Scrum etc. If a team can identify who their "customer" and setup a feedback loop - then they're on a great path.

Rick Lehtinen

Seasoned Technical Writer and Trainer

4 年

Very insightful, Jeff. I was surprised at first by the layer of complexity that Agile added, but I soon saw it was an asset in my role as a technical writer because it helped me discover resources when I needed to uncover additional information or resolve conflicting information. Now I embrace it. Cheers, Rick Lehtinen

要查看或添加评论,请登录

Jeff Gothelf的更多文章

社区洞察

其他会员也浏览了