The following post details how you can better think through business agility. Rather than viewing your agility as a collective measure of practices and tools, you need to see agility as a reactive ability. Too often, we fall back on the erroneous thinking that an organization or team is agile because they are doing a framework, or has a set of tools or structure common with other agile-minded organizations. Many miss the bigger picture of what agility is about.
Proactive vs Reactive
A very talented developer summed up agility nicely using the concepts of Proactive and Reactive approaches. Traditionally the way to mitigate uncertainty is to come up with all the scenarios and proactively solve for each to ensure a successful project delivery, or additional business capability. We view this as a good thing. We commonly praise people for being proactive. In fact, that is the first habit of Franklin Covey’s book The 7 Habits. However, in an agile context, you cannot work in this way.
Why reactivity should be valued
If you are serious about being agile, you need to accept some general truths:
- You do not have all the data to make a correct decision.
- You do not know how your customers will react
- Change is constant
Because of these general truths, you need to make small decisions, gather more data, evaluate and make another decision. The state of your business or product will be in a continual loop, constantly evolving over time. As will the preferences of your customers. That is where reactivity comes to play. The better you increment, deliver, evaluate, and adjust will dictate the effectiveness of your agility.
In an agile paradigm, reactivity is the key. Can you react to customer feedback quickly or do those changes take months to implement? If circumstances yield a specific set of opportunities for a limited time, how quickly can you react to those circumstances and take advantage of those opportunity?
Agility is the ability to react. In this paradigm, you cannot proactively come up with all the scenarios that would fit your new capability, customer demand, or opportunity. Doing so would mean a lot more time at planning and mitigation than you can actually afford. Since change is constant, you are better off implementing off what you know to a smaller degree and building on either that initial success or failure as you react to more data.
Being Proactively Reactive
Rather than trying to solve all of the unknowns on the front end, I would recommend you take a different approach and be proactive about acquiring more information. Being proactively reactive means that you should plan, design, and build what is necessary to move forward in a small way, but get more details you need to make a better decision. If you have a problem 80% solved, why wait until you solve the other 20%? Release what you have while making plans on proactively reacting to the 20% outliers. This is what proactively reactive means. You make active steps to be able to react in a quick and planned matter where your knowledge ends.
Striking a balance
The key to agile reactivity is being able to find the balance between planning, discussing, and implementing. Planning is important. Understanding what may happen is useful. However, if it is at the expense of incremental progress and real-world data, you are hindering your team, company, or goal. You need to be able to get feedback quickly so that you can react to what you are learning. There is a line between analysis and paralysis and you need to be able to recognize the difference.
Proactively reacting will allow you to find that balance. When you plan to react, you are ensuring that you have a means to deal with unknowns. It also allows you to provide a better solution as the new data helps you better prioritize and define what comes next.
Applying Proactive Reactivity Individually
You may be reading this and not in a position to guide a team, or company to being proactively reactive in solving problems. Not a problem, the nice thing about agility is that it applies on an individual level.
Advice for the Agilist
I bet most of you reading this article has some sort of project, hobby, or side hustle that you have been thinking about for some time. However, instead of sharing that thing, you have been constantly tinkering, researching, or tweaking that project because the “timing isn’t right”. Well, the time has come to be proactively reactive. Whatever it is, you need to share it and get feedback on that thing. Now, when you get feedback, positive or negative, resolve to react on that feedback. Either continue in the direction you were going (if things are positive), or find a way to pivot. Resolve to react to the new information you receive.
Even if it turns out to be a disaster and you decide to quit on that thing, you just saved yourself time by not expending more effort on it. You just freed yourself up to learn something else, try something else, or direct your energies in a new endeavor.
The thing to remember is to be proactive about getting feedback and reacting to that as quickly as possible. You will find more motivation in that feedback as well as answers to questions you may have had in regards to your project.
If you found this helpful, please share with your colleagues, friends, boss, etc. Also, feel free to start reading my Agile Laws series here.
Thanks for reading!
Agile ↑
