I often find myself reflecting on a saying that resonates deeply with my experiences in the agile world: “Don’t attribute to malevolence what can be explained by incompetence.” This phrase has become a guiding principle for me, especially when navigating the complexities of organisational dynamics as an agile coach, Scrum Master, or product owner.
Understanding Behaviour in Agile Environments
In my journey, I’ve observed that when people engage in behaviours that hinder our ability to deliver effectively, it’s rarely out of malice. More often than not, these actions stem from the way they are measured within the organisation. Here are a few key insights I’ve gathered over the years:
Measurement Drives Behaviour: The metrics we use to evaluate performance can significantly influence how individuals act. For instance, if developers are assessed based on the number of lines of code they produce, it can lead to counterproductive practices, such as excessive copying and pasting. This not only inflates their metrics but also detracts from the quality of the code.
The Pitfalls of Traditional Metrics: I’ve seen organisations flip the script, rewarding fewer lines of code in an attempt to optimise efficiency. However, this can lead to a culture where developers are incentivised to do the bare minimum, resulting in a lack of innovation and engagement.
Culture as a Reflection of Measurement: Many leaders focus on changing the culture within their teams, believing that this will solve their problems. However, I’ve come to realise that culture is merely a shadow cast by the underlying measurement systems. To effect real change, we must first address how people are evaluated and incentivised.
The Systemic Nature of Challenges
When I encounter resistance or feel as though I’m fighting an uphill battle to deliver a product, I remind myself that it’s often a systemic issue rather than a personal one. The systems in place can create barriers that inhibit progress. Here’s how I approach these challenges:
Identify Systemic Issues: If you find yourself constantly thwarted by compliance checks or bureaucratic processes, it’s crucial to recognise that these are symptoms of a flawed system. The system is designed in a way that makes it difficult to adapt and respond to change.
Simplifying Change Requests: A common frustration in many organisations is the cumbersome process of handling change requests. When a customer needs to pivot, the response often involves lengthy forms and negotiations. This rigidity is a byproduct of a traditional project mindset that seeks to minimise variance. While this approach may work in manufacturing, it is ill-suited for software development, where flexibility and responsiveness are key.
Shift the Focus: Instead of viewing resistance as malevolence, consider it a reflection of systemic incompetence. By addressing the root causes—namely, the measurement systems and processes—we can create an environment that fosters collaboration and innovation.
Moving Forward
In my experience, the path to agility is not about changing people but about transforming the systems that govern their behaviours. Here are a few steps to consider:
Re-evaluate Metrics: Assess the metrics you use to measure success. Are they encouraging the right behaviours? If not, it may be time to rethink them.
Foster a Culture of Adaptability: Encourage teams to embrace change and view it as an opportunity rather than a burden. This shift in mindset can lead to more innovative solutions and a more engaged workforce.
Engage in Continuous Improvement: Always be on the lookout for ways to improve processes and systems. This commitment to continuous improvement will help create a more agile and responsive organisation.
In conclusion, the challenges we face in agile environments are often not due to the actions of individuals but rather the systems that shape their behaviours. By focusing on changing these systems, we can create a more conducive environment for agility to thrive.
If you found this discussion valuable, I encourage you to engage with me further. Whether you have questions about agile practices or want to share your experiences, feel free to reach out or book a coffee chat through Naked Agility. Let’s continue the conversation!
I think I think one of my favourite favourite sayings, um I don’t know I don’t know where I heard it to be honest I think I’ve heard it a few times from a few different places, um but it’s the that don’t put down to malevolence what you can put down doing confidence.
Right, most of the time when you’re working as an agile coach in organisations or a scrum master or a product owner or a developer and people are doing things in a way that negatively affects your ability to do your job, right, most of the time they’re not doing it because they’re dicks, right, they’re not doing it with their dicks, they’re doing it because they’re measured.
There’s a reason that they’re being measured in a way that results in them making decisions that have a negative outcome, right, or, uh, so somewhere in the organisation there’s some level of incompetence that this decision has not been changed, right. This measurement has not been changed.
The old adage that hopefully nobody still has in their organisation is that developers being measured by the number of lines of code they write, right. We all know that’s a dumb thing to do because especially if you’re a developer because what you do is you start copying and pasting out Shakespeare into the comments and then you end up with these, uh, lots of lots of, uh, lots of lines of code you’ve written.
And in fact, um, I’ve seen organisations do the opposite as well. The fewer lines of code that you write, right, which is meant to be somebody thought it would be a good idea because you want to optimise your code as much as possible.
But what you end up doing is you get a bunch of people that go, well, it’s not raining but today then and I’ll get my bonus, right. So you have to, you have to, people’s behaviours are directly related to the way you measure, right.
You think it’s the culture, right, that creates that. So people focus on changing the culture in an organisation but it’s not the culture. The culture is just as the shadow on the wall of the measures for people reflecting through people’s activities and that’s the shadow in the wall, right.
So you can’t, you can’t actually change that. You can’t change culture. Change the way people are measured. Change the system, right. And this, if you change the system, the light will shift and the shadow will change.
So it’s always a system problem. It’s never actually the people are in the middle and they’re just doing what the system’s telling them to do or the system’s encouraging them to do or, or, you know, like, um, you know how sometimes you feel like doing something is an uphill battle that at every turn you’re, you’re, you’re sabotaged by somebody in your, you know, you’re trying, I’m trying to ship this product to production and you just get sabotaged at every, like, oh, we’re gonna be, oh crap, here comes compliance or, you know, whatever it is, you’re sabotaged at every turn.
That’s because it’s an uphill battle, right. The system has created an uphill battle because they don’t want you to do that. You need to tip it the other way, make it easier.
Here’s a perfect analogy for that. Um, why, why do we have change requests? Yes, that’s the way. Why do we have change requests in organising? You’ve got a project, you try to deliver your back project and the customer comes along and says our business has changed, we need to change what we’re working on and we’re like, well, here’s the 5,000 page change request form and the contract negotiation team that come along with it to help you navigate this problem.
And the reason we do that is we don’t want to change anything because if we’ve got a traditional project mindset, you want to plan out the project at the start, you want to minimise the variance in the project and just deliver it, right. That’s, we need to make 5,000 widgets. You’ve placed an order for 5,000 widgets. We’re gonna make 5,000 widgets and if you come along later and say you only want 400 widgets, that’s tough, we’ve already committed to making 5,000, you’ve signed the contract, right.
That works great for factories, right, because it protects both parties but it totally sucks for building stuff that doesn’t exist yet.
So this, this, this malevolence that we sometimes feel that is directed at us to inhibit our ability to do stuff, inhibit our ability to get stuff done is not malevolence at all. It’s the incompetence of the system. The system has created this level of incompetence in the people that results in that shadow in the wall that we can’t change.
Change the system. Always work on the systems.
Thanks for watching the video. If you enjoyed it, please like, follow and subscribe. I always reply to comments and if you want to have a chat about this or anything else agile, scrum or devops, then please book a coffee with me through Naked Agility.