Being agile is all about how well you can pivot and change direction, right? If your team can stop what it’s doing and immediately pivot to support that new urgent policy mandate, it’s the epitome of agile success. You are the perfect example of the Agile Manifesto statement that says you value “responding to change over following a plan.”
But are you though?
Some of you may be reacting more than responding. There’s a difference and it matters.
Psychology Today suggests that a reaction is instant, driven by beliefs, biases, and prejudices of the unconscious mind. Conversely, a response is more deliberate, based on information. A response weighs the long-term effects and stays in line with your core values.
I like how the Growth Equation puts it.
“Responding, a spin off from the word responsibility, is considerate and deliberate. Reacting, on the other hand, literally means to meet one action with another one. It is immediate and rash.”
Maybe you’re pushing back on me mentally concerning any notion that you and your team are reactionary in your work. And hey, sometimes reactions are necessary. I get that.
But before you close me off, let’s explore both sides of this coin and see if there might be a takeaway for you.
Responding to Change
You have a strategic direction you’re pursuing. You move forward with the best information you have at the time — validating assumptions and mitigating potential risks. Something you learn along the way throws a wrench into the mix and forces you to rethink an approach.
You take in the new information and assess what the next right thing is. This is responding to change.
This response is within the bounds of the strategy you’re actively pursuing. Maybe one of your assumptions about the user, the problem, or the solution is proven false. That, by the way, is a good thing. You adjust and respond with your eye still on the strategic objective.
The key to responding to change in this scenario is that the catalyst for the change rarely comes completely by surprise.
If your assumptions about the user, the problem, or the solution is wrong, you should have known it could be wrong because you work from assumptions.
When you work from assumptions, you remove any possibility that you cannot be wrong. In fact, you are ideally working hard to disprove those assumptions to find your way to the best outcomes.
Responding to change is responding to the invalid assumptions you make, but you remain on course to still achieve the desired outcome or strategy.
Reacting to Change
You have a strategic direction you’re pursuing. A new policy mandate is handed down or your boss tosses a new seemingly unrelated initiative at the team and says it must be done right away.
This urgent request from a higher-ranking official, which perhaps came with a deadline they announced publicly, prompts you and the team to scramble to get the changes done quickly. This is reacting to change.
The reaction is to events and people outside of your current strategic focus. It’s a pivot in the truest sense, causing you to put the strategic and important thing you were doing on hold, or cancel it, to make room for another.
Sometimes you need to stop what you’re doing and pivot away from it because you learn it’s no longer what you should spend time on. Reacting can be good when circumstances dictate it, but this situation doesn’t happen often.
Reacting is bad when it’s the norm. It seems like you live in reactionary mode as your organization jumps from one thing to another. Sometimes it’s “shiny-object syndrome” — chasing one new idea after another. Other times it’s trying to meet the whims of a higher-ranked official.
You may have a strategic plan, but you rarely get to live it out due to so many pivots — pivots that are rushed and reactive. The result is a misaligned architecture, technical debt, stressed-out teams, and a lack of strategic focus.
Your Agility May Not Be Very Agile
If you don’t have time to think or act strategically, you’re in reactionary mode. It may feel agile because your team is able to pivot and deploy whatever is thrown at you. But it’s not very agile at all.
Agile is about finding better ways to discover and deliver the next right thing. That requires intentionality. It requires validating or invalidating assumptions. The next right thing is aligned with strategy. Agile ways of developing reduce technical complexity and debt. Reacting cannot help you do any of that.
Information that challenges your thinking is great. Actionable steps to improve the situation are even better. Here’s how you can begin your transformation away from reacting toward responding.
The first step is to recognize where you are. Be honest with yourself, even if you’re the cause of that reaction. Deliberate responses to change require you to slow down a little. Be ok with that.
Having a bias for action is good. If something is worth doing, get started. But first, take the time to make sure it’s worth doing.
The second step is to pick one urgent request and challenge the requestor (or yourself) with the question, “what problem are we trying to solve?”
Your goal is to slow down enough to articulate the problem, the impact of the problem, the intended outcome that will result after doing this proposed thing, and lastly, understand how it supports your strategic direction.
The answers are in the questions you ask. This exercise often leads to a different, and better, decision.
Be persistent and consistent. Insist on data to back up the assumptions. Do just enough to satisfy the reactive request. Often the urgency and frenzy will go away and you can get back to your strategy. If it doesn’t, slow the pace down going back to step two.
Agility means nothing if you’re delivering quickly all the wrong things and making a mess along the way. I look forward to hearing your reaction, I mean response, to these ideas.