Is Your Team Responsive to Change?

Change is a constant in software development and business. Successful organizations are often highly responsive to change. As a developer, you play a crucial role in providing this vital capability.



A company needs to keep pace with the latest innovations and be able to quickly deploy and iterate their own innovations. That’s why it can be super-important to be responsive to external changes — like competitor innovations or customer demand, and internal changes — like new insights and innovations that have more potential than existing items on the product road map.



Unfortunately it’s not enough to assume that your *agile* process will magically make you responsive. In fact I encourage you to reflect on your culture, and your software delivery process, and be honest with yourself; is your process really just waterfall software development masquerading as cargo-cult agile?



I’m going to list a few indicators that help me to understand whether a team’s culture engenders responsiveness. You can use them to ask questions about your team. But first I want to elaborate on why responding to change is important to you as an individual and the companies you work for.

Responding to Change is a Competitive Business Advantage

Businesses who can adapt quickly to changes in the market are able to satisfy the latest demands and take a larger share of the market. Imagine, for example, that Amazon had continued to focus on hard-copy books and ignore the massive upsurge in electronic formats.



As software developers, a lot of the change we face is due to changes in the market (or an improved understanding of it). I’m sure a feature — or an entire product — you’ve worked on got shelved because something else became more important. This is a result of change. Most likely, the management team strategically decided that a more important feature would help to satisfy a more profitable demand.



Another key benefit of being able to respond to change is reducing the cost of mistakes. We’re all human and we all make mistakes. Stakeholders may provide ambiguous or poorly thought out requirements. Developers may deploy bugs. If you can respond to change quickly, you can minimise the cost of mistakes — and the effort to fix them.



Finally, if you want to work on ambitious projects, for innovative companies, who employ top people, then being able to create a business impact is a massive asset. Enhancing your team’s ability to respond to change will be a big contribution to creating business impact.

Types of Change

I’ve noticed certain types of change that are ubiquitous in software development. You can use these observations as the basis for assessing your own process. But ultimately, what’s important is being able to recognise change and making sure that your process is not precluding it. At least not without good reason.



As you read through each of the following sections, imagine it was your company. Could you respond to the change? If not, is this a problem you should fix in order to provide a competitive business advantage?

Requirements Change

You’ve started on a piece of work, you may even be close to finishing it. Then suddenly: “actually could you make it do this instead” is dropped on you. The rug has been pulled from underneath you and the requirements have changed.



I encourage you to embrace requirements changes. Many times stakeholders will have learned something new about customer needs. If you can respond to requirements changes quickly, you will minimise wasted time, and help your company align with customer demand more quickly. Even better, find out why the change is necessary and become more involved with product development.



Another reason for requirements change is that when stakeholders start to see their requirements coming to life, their understanding changes. They have a better idea how the product will work and what is technically possible. They’ll have a better idea of how customers will perceive it. Is your culture prohibitive of continual improvement?



Nearly every feature I work on I show to interested stakeholders well before it’s finished. And nearly every time there’s a “can you make it do this”, or a “this doesn’t seem that useful now I can see it working”. It’s massively cheaper to change a thin vertical slice than a robust, unit-tested, kitchen-sink equipped feature.



A sign that you aren’t responsive to requirements change is insisting on inflexible requirements. Does your process expect stakeholders to fully-define a piece of work up-front? And does it preclude changes once that work is in progress? If so, the business may be suffering from the disadvantages of waterfall software development.



Another sign to watch for is being afraid of interfering with estimates or velocity (usually measured with story points). Its up to you to decide where your priorities lie. This is also a sign that applies to the following types of change.

Priority Change

I once worked on part of a product that was a low-organisational priority, where little was expected of us. Then suddenly, competing products started providing enhanced services that quickly set industry-standard levels of expectation. Instantly, the company’s organisatinal priorities changed and the focus was on us to deliver.



If my team hadn’t been able to respond to changes in the market by rapidly aligning with the new organisational priorities, the team might not even exist now.



A priority change can often seem like whimsical management. Sometimes it probably is. But on the occasions they have identified profitable demand, you will need a process that is responsive to priority changes to take advantage. Otherwise you miss out and a more responsive competitor may get a significant head start.



A few signs that can indicate a culture unresponsive to priority changes are rigid product road maps, distinct life cycle stages (as opposed to fluid and iterative), and blatant priority-change denials.

Scheduling Change

One *agile* team I was part of worked to a rigid schedule, with big up-front commitment. On one memorable occasion an important piece of work wasn’t finished by the end of the sprint. Initially the team basically said: “this is our process — we deploy at the end of every sprint and every sprint is 2 weeks”.



Unfortunately the business didn’t want to wait another two weeks for their feature to go live. Two weeks of lost impact and learning about the new product would have been a massive blow. I’m happy to say that the sprint was stretched by a day, and on this occasion the team were eventually responsive to change. It wasn’t their natural reaction, though.



If you were in a similar situation, would your process allow you to stretch out the sprint? Or would your fixed *agile* process mandate a dogmatic adherence? How about if you needed to schedule in an additional deploy or bug fix?



A scheduling change might seem like hassle. But it can reduce waste and increase your organisation’s ability to learn about customer needs.

Controlling Excessive Change

Too much change can also be a problem. I’m not advocating a free-for-all.

My approach is to make the effects of change visible to everybody so that they can make the decisions. Try making it clear to the business that a requirements change will affect deadlines and push back other features.

Try avoiding and “us and them” culture, though. Be polite and empathetic is my advice.

I like Kanban’s way of being responsive yet controlling change. Kanban systems often allow priority changes until a piece of work is committed. But once committed, a piece of work should be completed. By only committing to work once you start on it, you can be very responsive.

Understanding when there is a good reason is easier when you work closely with the business, because you have a deeper understanding of organisational priorities and customer demand.