Organizational Culture Eats Developer Autonomy For Breakfast

The harsh reality vs the Agile promise

The harsh reality vs the Agile promise

“Agile” is more than 20 years old. It is based upon several lightweight approaches that saw the light of day in de years before (like XP, Scrum, and Crystal). One of the cornerstones of Agile is the emphasis on the autonomy of the developers. They should be in control of the what, when, and how.

Agile sparked a revolution. It showed everyone that there’s a better way to build software by moving from control to empowerment. Gradually Agile took over the world. Many teams and organizations are on the journey to embrace agility as it is depicted in the Agile Manifesto.

Today, there’s little doubt that Agile has brought us a lot of good. Some will argue that it is outdated and that we should move beyond Agile, to build upon it. But many others have never reaped the full benefits of Agile.

Two decades after the birth of Agile, many developers still face the harsh reality. Organizational culture eats developer autonomy for breakfast.

Let’s remind ourselves what Agile is all about and discuss the chasm between organizational culture and Agile.

Image by Muhammad Saleh from Pixabay

Core Values

“Individuals and Interactions vs Processes and Tools”

It is mind-boggling when organizations incentivize the usage of processes and tools as the main means of communication. Burndown charts and velocity reports rule. Rigid procedures determine how you communicate with your stakeholders.

The impact on the developers is catastrophic. Because without the opportunity to interact, discuss and gather feedback they are merely a cog in the machine. They are producing software instead of creating valuable functionality.

The first core value to creating better software is through appreciating individuals and interactions more than processes and tools. It’s such common sense.

Whenever I ask people what they prefer, they will tell me collaboration and direct interactions are better than using tools and processes. Regardless of the region or position in the organization, direct interaction is overwhelmingly preferred.

Many will argue you also need the processes and tools. Like Jira, like a certain structure to ensure all boxes of software creation are ticked. But this should enable direct communications instead of crippling it.

“Working software over comprehensive documentation”

Since the early 2000s, we have seen many developments that enable developers to release their software often. Today, deploying multiple times a day is no exception. Continuous deployment is a thing these days. On the surface, it seems that this Agile value is being embraced everywhere.

But sadly, this value has been misinterpreted terribly. Because it has not merely to do with delivering software fast and often. The key here is working software. Working software doesn’t equal error-free functioning software.

Sure, it is important to release software that is technically sound. But it should also do what the users want it to do. Software is working software when it does what it is supposed to do. And we can’t know this upfront.

It’s impossible to know and document upfront how to build the software so it does what the users want. You need to learn this with an incremental approach. You develop a small chunk of functionality and allow the user to provide feedback on this increment. The feedback is then information to build the next increment of the product. This way, you can truly build working software.

When you are asked to ignore this reflection opportunity and instead deploy software continuously, you are — again — merely a cog in the software-building machine.

“Customer collaboration over contract negotiation”

All core values of the Agile manifesto are related and essential. I already touched upon the importance of the customer’s feedback on the software increments you create. This is one aspect of customer collaboration. But there’s more to this.

Customer collaboration doesn’t only involve feedback on the software. It’s also important to look at the bigger picture, like:

• What does the customer want to achieve with the software you are building?

• How does the current increment impact this goal of the customer?

• What other factors are impacting the next thing to focus on? Think technical developments, actual usage of the product, and market developments.

I discussed how demoing the software increment is often ignored. It’s even worse with the bigger picture. Many organizations ignore to have fast feedback on usage and developments. They rather work with contracts that set everything in stone.

Contracts are almost always output-oriented. They commit developers to deliver specific software by a specific date. Rather than discussing what a customer wants, a contract is about what will be delivered, regardless of whether it will help the customer achieve their goals or not. This sets the developers up for a rate race.

The better way is to agree upon the desired outcome by a certain date. This allows for collaboration toward those outcome-based goals. It enables the developers to find to experiment and learn together with the customer.

“Responding to change over following a plan”

Sadly, many developers live in a world of estimates that turn into commitments. Plans that are turned into promises. Sure, changes may come. In the shape of extra work that needs to be completed by the originally planned date.

Often, a plan is a good thing to have. You want to have a common understanding of what you wish to achieve, by when, and at what cost. The issue is not the plan. It is the restraint to make changes to the plan.

As soon as you consider the plan sacred, you are in trouble. Because you then ignore new learnings. When we are at the start and creating the plan, we have many unverified assumptions. These can’t possibly be the basis of a rigid plan.

Principles

The Agile Manifesto also has 12 principles that align with the core values. They are either ignored or distorted.

“Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.”

Don’t do this: continuous delivery only. As it will make developers feel like they are in a software factory.

Do this instead: focus on delivering value to the customer. This will empower the developer through collaboration.

“Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.”

Don’t do this: changing requirements are added on top of the original plan. Preferably without changing the delivery dates so the developer gets overwhelmed with work.

Do this instead: plan your work as late as possible to maximize the chances you work on the right things. This will allow developers to avoid being overloaded.

“Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.”

Don’t do this: delivering all the features of the product faster. This only results in tightening the screws to be more “efficient”.

Do this instead: delivering small chunks of the software faster to be able to get feedback on it. It is about understanding what brings value and what does not.

“Business people and developers must work together daily throughout the project.”

Don’t do this: business people — or management — disrupt the team on a daily basis. As a result, developers don’t get the opportunity to focus and work on the best possible solutions creatively.

Do this instead: foster collaboration. Make it easier for developers to align with the business and users.

“Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.”

Don’t do this: just tell people they are motivated. That should be sufficient, right?

Do this instead: Set clear goals, foster the environment, and trust the teams to do their work.

“The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.”

Don’t do this: Ignoring this altogether and trust the sales or product managers to be right. What could ever go lost in translation? Which then would result in needless rework, when the customer shows they don’t like the solution?

Do this instead: help the developers to align with the customers or users when they need to do this.

“Working software is the primary measure of progress.”

Don’t do this: working software equals technically working software. This triggers a feature-factory mentality in the organization. Making the developer a cog in the machine.

Do this instead: create software that is working as desired. Which will help the developer to collaborate on finding the best possible products.

“Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.”

Don’t do this: Whenever a team or individual developer can’t keep up, it’s their fault. They should find ways to make their lives easier. They are self-organizing, isn’t it? This is putting absurd pressure on a developer.

Do this instead: When working in iterations, sustainability is about avoiding the constant pressure to deliver and finding the balance that fits the developers to thrive.

“Continuous attention to technical excellence and good design enhances agility.”

Don’t do this: Early delivery trumps technical excellence. This is what happens when deadlines are king and the plan is sacred. Meeting deadlines often sadly trumps quality. The developer will suffer in the end, because poor quality software will be resolved by them. And probably outside of office hours.

Do this instead: don’t accept quality sacrifices for early delivery.

“Simplicity — the art of maximizing the amount of work not done — is essential.”

Don’t do this: Developers need to build what was planned. There can’t be any work not done. So this is outrageous to suggest in many organizations. With that, developers will work on things that don’t add any value. Which is hardly satisfying.

Do this instead: embrace the simple solution. don’t go overboard with gold plating a product. Because that doesn’t serve anyone.

“The best architectures, requirements, and designs emerge from self-organizing teams.”

Don’t do this: Teams are often allowed to self-organize, but only to develop, test and deploy the software. Architecture, UX, and requirements come from outside of the team. This will always lead to friction, delays, and quality issues.

Do this instead: trust the developers in the team to do all of this themselves. Or have the architect, and UX engineer in the team in the first place.

“At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.”

Don’t do this: The most frustrating retrospective meetings are those where organizational impediments are discussed for the tenth time, but with the recognition that they fall outside of the influence of the team. Nothing will change anyway. The team can tune and adjust whatever they want. The organizational impediment won’t go away. This will have a devastating impact on motivation.

Do this instead: Allow teams to challenge the organization and help them reflect on processes or tools that hold them back. Embrace change.

Cherry-picking from the Agile Manifesto

Many companies state they have adopted Agile. But what they did, was cherry-pick from the Agile Manifesto. They adopted agile to increase productivity and accelerate software delivery. There are two things you would NOT automatically achieve with agile approaches.

You also see this in the adoption of the SAFe framework. A behemoth of a scaled agile approach that fits neatly into the many existing organization models. And as a result, nothing changes except for the state of the developers, that are forced into working as feature factory personnel.

Living in a world where sprints are death marches, plans are promises, velocity is a metric to increase over time, and everything is only about delivering more software faster.

Agile in name only has taken over the world. And developer autonomy suffers from it.

Originally posted October 2022.