Agile and Current Technology: Are We Adapting or Missing the Mark?

When the Agile Manifesto was created 21 years ago, software development, technology, and the world, in general, were different.

Agile was first created in response to the frustrations around the traditional software development processes of the 1990s—years from idea to development to deployment—and the explosion of personal computing, meaning that software had to keep up, but it was struggling to do so.

What really made Agile work in the early days was the cross-functional team of people who collaborated in the room with their customers, building products and constantly iterating and testing.

As it evolved, we wrapped the core structure with different processes to get there but forgot the fundamental principles that made Agile successful. We’ve taken practices that worked in that room but overlayed them on top of organizations that aren’t teams in a room with the autonomy to change their software.

And because of that, we hear whispers that “Agile doesn’t work anymore.”

We get it. Organizations that adopt Agile have a lot on the line. They do it because they think it will increase their product delivery time, reduce mistakes, make them more predictable, get an edge on the market, and respond to customer feedback and changing demands. The list goes on.

Not only that, but they also invest thousands or millions of dollars and months or years in doing it. So, they lose money and sometimes even their jobs when it fails. There isn’t much forgiveness when leaders make promises of success to an organization that they can’t deliver on.

The problem isn’t that Agile doesn’t work. We’ve proven that it works if you do it right. The problem is that adopting Agile alone is not enough. You can’t simply put Agile practices on top of an organization not set up for them to succeed. And when you do that, Agile will fail every time.

We must also adapt Agile to a changing technology landscape and work environment. More often, teams are not working in a room together, and customers aren’t either.

For Agile to remain successful, we must remember the core principles and shape the organization to adapt to make those things work the way the world is now.

What Made Agile Work in The Beginning

Agile officially began with the Manifesto in 2001 and was designed to:

• Empower developers
• Increase development speed
• Working processes focused on the user
• Ability to adapt
• Quick response to customer feedback
• Small autonomous teams
• In a room with their customer
• Constant iteration and testing
• Local apps on local servers

Because of this small scope of software development, it was easy for small teams to operate with autonomy. They had a small, controlled environment they deployed into that only they had access to. The security requirements were minimal, as were the places where the applications needed to be deployed.

Remember, in 2001, people were still getting started with personal computers, and though they were becoming more and more common in households, not everyone had one. The amount of technology and software required to support it was minimal compared to what it is today.

Over the last 21 years, Agile has remained successful for those who still remember its core principles. The problem we’re facing now is that the technology landscape has evolved, and so has the way we work.

To adapt Agile to work today, we still have to remember that what makes Agile work is setting up the systems and the structure of the organization to be successful. No amount of culture change or practices will work if the underlying systems are not there first.

How Technology Has Changed & Its Impact on Agile

Fast forward to today, and the complexity of software and the problems we are solving are much broader. This leads to the following:

• Teams can’t encapsulate software development.
• Dependencies between teams
• Teams operating separately from their customers and markets
• Lag in response to customer feedback
• Inability to react quickly to market changes
• Delay in deploying and re-iterating software

Now, we are also deploying applications differently—to the cloud. This enormous scope of deployment creates more obstacles resulting from technological advances:

• Requires more robust security
• Specific development skills
• More moving parts that work together
• Cloud needs to work anywhere, anytime, on any device
• Code and user experience suffer
• Increasingly difficult to consider the whole ecosystem of deployment

When the performance scale is much larger, and the stakes are much higher, there’s increased risk involved from a financial standpoint. In a world where everyone is constantly online, one application launch failure can result in consumers rejecting the application altogether.

Today, consumers are more ruthless than ever, and though feedback is essential, there are so many applications on the market that consumers might not wait for you to fix yours.

So, while software needs to be moving quickly, so do the teams developing the software. It means that organizations need to create the conditions for speed and autonomy in team pockets.

The problem is that they don’t always do that. They don’t make the conditions for teams to operate correctly. They don’t build backlogs. They don’t encapsulate teams because the problem scope is too large for them to do that.

They adopt Agile into an ecosystem where it can’t work, but they blame it when it doesn’t.

Haven’t we learned yet that Agile practices aren’t successful without the systems to support them?

Agile won’t give you the leverage you think it will in the market without overhauling an organization, restructuring teams, and fundamentally changing the work environment. Agile is not a quick fix, as much as people want it to be.

 How We’ve Adapted Our Approach Over the Years

1. Establish Software Development & Agile Transformation Knowledge

The first adaptation we’ve made is to establish our knowledge and experience surrounding software development, Agile Transformation, and how the technological landscape has changed. We’ve learned a lot from working with clients over the last 12 years as a company and people whose experience began way before that. We acknowledge that things aren’t the same as they were 21 years ago, and we have created special teams to help tackle software challenges. We have also gathered groups of incredibly knowledgeable people who understand how Agile works on the ground and how to implement it in many different-sized organizations. We also know where it can commonly go wrong and how to help.

2. Leading with Empathy in Client Engagements

Arguably the most important thing we do is lead with empathy in every client engagement.

We don’t just walk into an organization and demand things be changed because we said so.

It’s essential to establish empathy about the problems the organization has faced and wants to solve, especially if they tried implementing Agile before and failed. The stakeholders and executives involved in those types of Transformations will be hesitant, have trouble trusting our process, or be skeptical that we can make it work for their organization—but there’s a reason they bring us on board.

Because of their hesitation, we need to develop a trusting relationship. We listen with empathy for their problems and where things go wrong, work to deeply understand what matters to them, and create transparency for the process ahead.

3. Build Trust and Influence with Key Stakeholders

To build trust and influence, we develop a relationship of communication and transparency every step of the way. While these stakeholders may not be involved with the day-to-day teams, software development, and training, they must be in the loop to support their people.

The better leaders can understand what needs to change and why the more influence they will have in getting their people to change. Many Transformations fail to include executives and key stakeholders in the minutiae, thinking they don’t need to know when it couldn’t be further from the truth. Because they influence their organization, they will have more power to affect lasting change.

Overall, our strategy has adapted over the years to encompass the changing technological landscape, with teams to handle software Transformations and organizational Transformations. This is the complete package of what Agile requires today to set up the foundations and systems for Agile to succeed.

Agile Still Works If You Do It Right

In the industry, we still see people beating the culture first or practices first drum. But we know from experience that no amount of culture or practice change will Transform a broken system. To achieve sustainable Business Agility, you have to change the system first.

When the system is not set up to support small autonomous teams, weed out impediments, break dependencies, allow for constant iteration, and work within designated sprints to completion, no amount of daily process or culture boost will help.

Cultural change may seem like it works at first, but when things don’t actually change, morale will tank, and people will go back to doing things the way they always did. The same goes for practices. If they aren’t producing results, what’s the point?

Along with that, we must continue to consider the current state of technology, how we build, deploy, and iterate software, how people use it, and what the consumers want. We must make the systems work with how and where people want to work. We are shifting to a lot of remote work, which will probably be the norm well into the future.

As the world becomes increasingly digital, we must adapt our approach to ensure that Agile’s core principles are honored and set up to work. As long as we set up the ecosystem first, everything will fall into place after that.

With a solid organizational foundation, we will create an environment and organization that can quickly adapt to the continually changing technological marketplace.