What does hyperagie mean? Although it is not a new term, here I explain the details about this concept and what it implies for organizations that want to achieve a complete evolution of culture.
Hyperagie: Another buzzword?
Agility– agile en inglés – is a term that has been around for at least 20 years. And I must admit that, although much is written about it, little has evolved over time. Agility can be described simply as "reconnecting" with simple values such as:
- Collaboration and teamwork, over processes and tools that try to prescribe human interaction as if we were automatons.
- Results-oriented work, over management and documents - what is the use of so many documents and so much evidence of work, if there are no valuable results?
Agile officially emerged at the beginning of the 2000s and stated these values within the context of software development (at the time) with small workgroups. And, although the values were broad and general, the models that somehow represented or exposed those values were subscribed to small work teams.
Context and scale of hyperagility
Agile was originally expressed in non-linear or iterative work management models, such as: Donde XP, Scrum and DSDM. However, all these models posed modifications to the work schemes in SW development teams. Hence, the agile manifesto is officially called: "Manifesto for Agile Software Development".
To understand the context of agile - as it was defined - I hope you will allow me a small analogy. Let's imagine that our company - where we work, is a Formula One team.
Agile Team: Formula One
What is the goal of a formula one team? To win races, as many races as possible to win the championship. However, this goal of "winning races" for many means: to be the fastest.
First Mistake: Confusing agile with speed
If you are a formula one driver and over the radio your team tells you: "we need to go faster", the only thing you can assume is that you must push a little harder on your throttle and that, with the same strategy, but "running faster", we will do better. The truth is that this "go faster" strategy only increases the risk.
Agile is confused with speed for one simple reason. If you're the one waving the checkered flag, from your perspective, the first to arrive is the "fastest". The result of a simple equation of time per distance.
However, victory is a combination of speed, acceleration, driving, pit-zone management of the whole team, single-seater set-up, materials, fuel usage, tires, etc. etc. etc. etc. For the guy with the checkered flag, the simple answer is "fastest", but for those aware, the equation is not so simple.
Being agile is a total change of strategy compared to a traditionalist organization.
Second mistake: Better engine doesn't necessarily make you more agile.
Another mistake is to think that just changing the car's engine is enough. Of course, upgrading the car's engine can bring short term benefits, however, it is like changing cars. The driver must get used to and master the new engine to get "the most out of it". Likewise, the team in the pit area must train and get used to this new engine and its peculiarities. The entire team must adjust its race strategy accordingly with these new capabilities.
In other words, the change of engine must be accompanied by a new strategy. And the same goes for the change of any element of the equipment - new staff, new infrastructure, etc.
Agility is more about adaptation than speed, so when something changes in the system - we call this systemic vision - it is essential to assess the impact of the change on the other elements of the system and, of course, seek to hack that change for the results and welfare of all.
Third mistake: What works on a small scale does not always work on a large scale.
The last mistake is to think that what works for one, works for all. Context is critical. At Disciplined AgileOne of the guiding values is "context matters". For while we can establish models of governance, we cannot assume that one thing works for everything. There is no "one-size-fits-all".
For example, Scrum is an excellent (incomplete) model of teamwork. But that doesn't mean that an entire organization should work in Scrum teams and have a Scrum Master and a Product Owner. That simply ignores the context of a more complex organization.
Likewise, if I have a team of 5 or 6 people, I can do team activities. But if I have teams of 100 or 120, I can't assume that the same coordination events and the same communication models are going to work.
So what is hyperagile?
Well, like the formula one team, being agile isn't just about changing the engine. Better teams require better inputs, better organizations to connect to, and a change in organizational DNA.
Imagine an organization with all kinds of operational problems in its IT area. An organization, like many, where the business sentiment (the non-IT areas) feel neglected and underserved.
Now think that, overnight, the IT area is 100% effective and with no technical debt or unfinished business.
Surely, for a few days, weeks or months, the business areas do not know how to proceed. They do not even know how to take advantage of this new "engine". However, after a while they will find a way to make the most of this "new reality". That is where the business itself becomes agile.
Hyperagile is nothing other than the incorporation of agile values into the culture and daily life of the organization. In other words, is the same as agility on an organizational scale.
Why is the concept of hyperagile important?
Well, hyperagility is a term you will surely start hearing more and more often. In this continuous dynamic of renewing concepts and adjusting models, new terms have to appear to frame more complex concepts.
Here we already solved this term. I personally don't use it much and prefer something more understandable like "organizational agility" or "scaled agile".
