Want to become more agile? Ask yourself these 3 questions.

 
Agile is something we are, not something we do. That means in order to be agile, we must embody traits. To keep us on track with these traits, we can ask ourselves questions. These questions ensure our software is easy to change. And hopefully, this means we stand a better chance at delighting our customers.

Disclaimer: Article not relevant in high certainty environments. But let’s be honest, very few are in such a lucky position.

1. Is this decision reversible?

Decisions can really slow teams down. This is not only a drain on a teams ability to be agile but also it’s motivation. Soon you get one guy screaming out in a meeting
 
For god’s sake just make the decision, I don’t care anymore!
 
Often the questions we have can only be answered once we ship. Time spent agonizing over the perfect solution can be better oriented towards making our decisions reversible. If god forbid, the worst happens. How do we reverse it? How do we go back? Because often the only way to find out if we’re right is to ship.

2. Are we planning for future change?

Benjamin Franklin once said: ” in this world, nothing can be said to be certain, except death and taxes.”
 
He was partly right. The other thing that’s certain? Change. Change to our software. Change to the design. Change to the look, change to the functionality. More of our time is spent implementing change than implementing in the first place. That means building a solid foundation for future change should be a high priority.
 
Change is inevitable.
 
That means that in what we do we should consider what this means for change in the future. It’s not a question of how fast we ship the next release, but how fast we ship every subsequent release too. We shouldn’t be sacrificing our quality in the short term. We should always be asking ourselves how hard our code is to change.

3. We’re wrong, but where?

It’s wonderful when a team or business embraces A/B testing. A/B testing says we don’t know who has the right answer. So rather than fight it out we’re going to prove it. But often the same teams that are employing A/B testing are also having religious design wars trying to create the perfect solution in the first place. If we’ve got in place a mechanism for proving what’s best for the users then let’s use it. And waste no time getting the product out. We need the answers.
 
We’re going to be wrong. That’s for sure. So we need to know where.
Lou Bichard
Latest posts by Lou Bichard (see all)
Posted on
Category: Uncategorized