The Agile principle # 2 is the one that talks about change!
Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
Change has long been feared in software development. It dates to the 1990s and earlier, so much so that project management had a specific change management approach. Change is something you manage and control. Some changes you formally accept, and they eventually get incorporated into the project. Some you reject… and they become a cause for contract discussions!
Before Design Thinking and Human-Centered Design, that inflexible view was more the standard. Requirements were old, long gathered, late developed, and reached the client months, if not years later. Yet the companies producing the goods (software, mostly) would not be very keen on accepting change. A strong mindset of certainty governed the world of software projects. That came in with traditional project management, that back then was mostly waterfall.
The problem with this conundrum is that it caused more fights about what contracts and original requirements said than actually helping companies (and the teams developing the software) to deliver value to the customers, like the principle number 1 stated.
Ultimately the question hammering in the minds of those software developers was… who do we serve? The project management team or our customers?
Do you prefer to watch a video? Check out this post on our Youtube Channel.
We serve the customer
That was the view ultimately held in the Agile Manifesto. The reason why we accept changes is simply… because we are here for our customers and whatever is not giving them the results needed… well, needs to pivot. The client will get what they need. Maybe just not from you!
The interesting and understandable part is that newer companies such as startups and today’s big tech have no problem with this concept. Not only were they born as early adopters of design as a human discipline, but they were also interested in building products that would catch the next wave of what consumers needed. Most products today (think Amazon, Netflix, Booking.com) do not serve needs that existed maybe more than 20 years ago. Their business model is also quite different.
Older companies, like most of those Fortune 500 and these companies 100 years old, tap into markets that have evolved slowly. The companies basically pushed the features and products, not the customers. Think most bank, insurance, and telecom. How much customer delight do we traditionally see? It is mostly pushing onto the customer a way of operating that is not ideal for them, even though their product is useful. These markets have for the most part offered services and products based on premises and assumptions that benefit both in nature and in execution their businesses, not the customer as front and center. They had no need to think and even trust the power of fast change. They are incumbents. This could be an advantage for them if they know how to navigate complexity. The reality is that we are seeing most of these organizations stumble when adopting Agile practices. They had thought their business differently, especially based on certainty. Bringing Agile to these environments is not just a simple translation of new processes and a few tools. Their relationships with the customers themselves and their ways of doing business need to change.
How, do you ask?
Partnering with the customer
A misconception to undo when talking about change and customers is that we don’t change just because. You know, because of the next flavor of the day. Although you very well could! Many places have, for instance, no questions asked refunds. But the whole point in adopting Agile is to establish a relationship with your customer, whom you serve. And we are living in unprecedented times of fast-paced change and complete transformation of markets. If the client does not adapt, they lose ground: market, and sales. The same is true for the companies serving them. The relationship with a partner is one of conversations, which is very conducive to emerging requirements. Getting a rough idea at first and refining it into something more tangible. Together.
The question for the Agile leader is: How to coach your business teams to understand that and reframe their relationships with their customers?
Developing flexible processes
By understanding what true value with the client is, and by partnering we can both adapt and move forward. The processes for accepting change, though, need to be flexible. The technology used to create the products need to accept adjustments as easy as possible as well.
And there is where the famous inspection and adaption comes into play. If you develop something incrementally, with the partner, which is the customer and other stakeholders involved in that cycle, you know constantly if you are going in the right direction or not. And you course correct as soon as you detect the need for it. It is just cheaper and less risky to readjust requirements.
But here there is a problem. I’m just going to state my experience:
In many of these Agile transformations we see out there these days, the companies are NOT collecting any benefits on this principle. They have layer upon layer of product management roles in a hierarchy, which makes developers far-far removed from the customer. They have a telephone game where information is lost. Information takes longer to travel from producer to consumer. And despite millions of dollars invested and two years in the Agile Transformation, the developers still have trouble seeing what’s relevant for the customer and only discover issues with the product adoption 6 months to a year after they released something to the market.
The question for the Agile leader is: How to work with teams and executives to simplify processes and adopt technology to really respond fast to change?
Getting out of Sunk Cost paradox thinking
Ultimately, accepting change late in the process deals with a fundamental cognitive human bias: the sunk cost paradox. It speaks to our tendency to follow through with something we have already invested time, effort, or money into, whether the current costs outweigh the benefits. “We already spent a million on this project might as well finish it”. Or “We are almost done, let’s just finish it!”, even though the client already doesn’t want it anymore.
In companies where there’s a lot of hierarchy, and in any other circumstances that make it slow for decisions to be made and slow for learning at an organizational level to take place, this bias is stronger. Once again because of the telephone game, so no one has access to the same information at the same time or at least fast enough. In other words: it’s not that the change makes the product cost more. It costs more because we inspect little and late.
The question for the Agile leader is: how to help the organization rethink and express value?
The biggest challenge
In my experience, the biggest challenge in responding to change in general requires that work structures in organizations be very transparent and fast, two things that are difficult when there are 7 layers between a developer and a CEO. They say there’s 6 degrees of separation between you and anyone else on the earth. So having 5 or more layers in companies sounds… interesting.
The discussion about making the structure flatter does not mean getting people out of jobs! They speak of rethinking the way people are organized for work. Hierarchies such as the ones we see in big corporations still reflect that there are those who think and those who execute. And in the middle, many, many layers of those who manage… something. There is a lot of waste, confusion, and room for power play. The path towards success here is answering the question: How can all these people work in networks, instead of pyramids?
Transparency is the only way to make this principle come to life. More than just words, transparency reflects directly on how people are allowed to not only access but use information. Booking.com, as an example, has company targets visible to everybody at any given point in time. That even includes product and environment dashboards where any developer and product person can put features straight into production and understand how those numbers will move in the dashboard. So long as they do not lower by a certain threshold (which everybody is also aware of and collective own), the makers can actually test desirability live!
Other techniques such as A/B testing is an everyday approach to feature making, instead of unilateral decision-making of the “one and only” feature that makes sense. Integrating work into production is just continuous delivery, instead of an event that mobilizes dozens of people and requires a bunch of approvals that take time and convincing to do, probably happening once every 3 or 6 months.
A final word
While the Agile principle #2 is a complex principle to put into practice, the role of the Agile Leader can start with poking people around in the organization, at all levels: do you know what is your customer competitive advantage?
And then start the conversation.