When we talk about Agile Transformation in an organization, it’s always difficult identifying where to start. There are multiple solutions in the market promising to turn a traditional management organization into an Agile organization. However, as you go deeper, the gaps start showing, low engagement and lack of tangible results often being the most common symptoms to a lack of an agility mindset.
Why don’t one-size-fits-all models work?
At Knowledge21 we talk a lot about BDUF, the concept of Big Design Up Front, where you define at the outset a complete, detailed plan for a solution (and then execute the whole plan, and then measure the results). The main problem with BDUF is that it opposes one of the values in the Agile Manifesto, which is to adapt to change more than following a plan. Whenever we invest a lot of time in planning without validating our ideas in real life, the amount of effort spent allows us to get attached and overvalue those ideas (a bias also known as Ikea effect). That’s why it’s painful to find out you’ll have to pivot your idea. It feels like wasted effort, and in such situations, we find two possible scenarios:
- you accept the waste and get rid of the part of the plan that no longer makes sense
or
- you try to revamp the plan with a few adjustments, so it (badly) fits the needs you discovered.
Of the two, the first is the lesser evil, because you can genuinely consider the best solution possible, whereas with the latter the result will be a Frankenstein, giving you much more work in the long term.
This is why we avoid entering an organization with a predefined idea of the path they will take to an Agile Transformation. There is no recipe, no silver bullet. Each organization has its peculiarities, and using a one-size-fits-all process will end up causing more pain than any possible benefits.
Evolutions, not revolution
Another concept we often see and which is pretty damaging is completely revolutionizing the organization. This attitude is in direct conflict with the Agile mindset value of experimentation because it’s based on the premise that changing the entire environment without experimentation and learning is possible. Sometimes revolutions are necessary, but when we’re dealing with a large beast such as company with hundreds (thousands) of individuals, it’s vital that we understand the impact we’re having on people. Causing a large change in a small team and learning with it is much more useful than trying to apply an enormous mindset change to the whole organization.
In order for the transformation to last, it’s fundamental that the changes be done in a controlled environment, with small observable experiments that allow for learning. If we start a transformation movement, we need first to get the smaller things right. Start with a team, one business unit, establish that this group will be treated differently and will have the autonomy and support to navigate the organization in order to remove impediments. That way, the probability of success and contamination by the Agile mindset is much greater.
Creating an Agile bubble
Any lone Agile team inside a traditional organization will certainly suffer. But with the right sponsors and support, it can be a small experiment that proves it’s possible to change the organization’s mindset regarding work. By contrast, a whole organization being just a bit Agile creates many more problems than solutions, because if employees’ mindset is still undeveloped, the first obstacle they find will send them into “it’s always been like that” mode. That’s why we see so many organizations doing what Jeff Sutherland calls FrAgile: the use of structures like squad, sprint, kanban… and no shred of an Agile minset to be found.
To create an Agile bubble, we must determine who will sponsor agility what is the value it delivers, bearing in mind the objectives and metrics of the organization in respect of our customer.
Based on this, it’s possible to put a first Agile team together, solving the most valuable problems. This team must be focused on better practices, product value, and seek to create a safe environment within the bubble.
Their experience will result in learning and adaptation. As it matures, the same process will be viable with another team, and another, until the whole organization has been contaminated by agility and reflects: “Wow, I can’t even imagine working the old way.”
Organizational Design vs. Results
“Most businesses today are not designed with agility in mind. Their systems are tightly coupled, because their growth has been driven by a desire for efficiency rather than flexibility.” Dave Gray, Author of The Connected Company
Our mind is strange. When we talk about products, we often use the doctor analogy created by Rafael Sabbagh, a founder at Knowledge21: if a patient goes to the doctor and asks for some medication, the doctor will sarcastically say: “Yeah, sure,” and start investigating what might be causing the problem. He’s confident about doing this because deep down the patient doesn’t want the medication itself. They want to solve the problem, regardless of how.
When we talk about products and processes, the same applies: a sponsor, director or boss makes demands on the teams based on how many things they can deliver, but in fact, he’s trying to reach a business result. Whether it’s the client retention rate, volume in $ of turnover, or service time, the manager cares less about delivery itself than the results achieved (find out more about Agile Metrics here).
That’s why, when we’re talking about the Agile Transformation of an organization, the greatest challenge for changing the mindset is encouraging all layers, from the C-Level to the intern, to take their focus off efficiency and start measuring efficacy.
In general, organizations that want to do Agile Transformation start the process by discussing what the new organizational design will look like. An org design, like medication, is the solution, and not the problem we’re trying to resolve. Changing the org design without experimentation is like ordering Aspirin for a foot pain, without knowing its cause. If you have an infection, Aspirin will not only not solve the problem but will mask it.
In order to foster experiment, ensure teams’ autonomy and transparency of each person’s role in the process, we must focus on the problems which really need solving: we need to achieve the company’s business goals.
While we’re only looking at delivery and focusing on efficiency, without concerning ourselves with efficacy, we’ll be building a path to becoming terrified dinosaurs.
OKRs
“Success is not ticking a box. Success is having an impact. If you finish all the tasks and nothing improves, that’s not success.” Christina Wodtke (OKR Coach)
One way of creating this focus on the business goals we need to achieve is through OKRs (Objectives and Key Results). The organization defines a vision of the objectives it must achieve. These objectives should be inspiring, with a clear value, ambitious and a little uncomfortable. Based on them, success metrics will be defined and pursued during a timeframe.
Let’s imagine that an investment company wants to expand its market by exploring a low-income segment with small amounts of money to invest. So they set an objective which also has value for its clients and their short term success indicators:
| Objective | Show the benefits of saving money to low-income workers |
|---|---|
| Metric 1 | Increase the average rate of savings by 5% among base clients over the next 3 months |
| Metric 2 | Increase the monthly amount of clients making a new investment by 10% over the next 3 months |
| Metric 3 | Increase our net client base by 5% over the next 3 months |
Based on this information, the departments of this investment company can propose their objectives and metrics in order to help the company achieve corporate OKRs:
| Dept. | Objective | Metric |
|---|---|---|
| Operations | I, Robot | In the next 2 months, have 70% of first-time clients who previously contacted the call center start using the app for doubts. |
| Reduce the amount of follow-up calls by first-time clients by 25% in the next 3 months | ||
| Marketing | Be a wiz in savings and investments | In the next 3 months, publish 50+ videos with over 20,000 weekly views. |
| Love me, marry me | In the next 2 months, reach the 10,000 marks of subscribers to the channel. | |
| In the next 30 days, increase the conversion rate of leads into clients, from 5% to 10% | ||
| Commercial | The piggy bank for low-income workers | Reach a base of 5,000 people using the functionality of economic and investment suggestions, over the next 3 months |
| Increase the conversion rate of new clients into investors from 30% to 50% in the next 2 months |
Now the team can do its experiments to find out how to achieve those objectives in the next 2-3 months, with total autonomy.
It’s important to remember that OKRs shouldn’t be used as a tool to instill a culture of fear. If the team doesn’t hit an OKR but is able to achieve great learning from the attempt, this is normal and welcome. Often we see a new product or campaign launched, with no return for the business. The big difference here is that experiments should be short-term, with several iterations during these 2-3 months, so the team has more opportunities to fail fast and learn faster, adjusting the path to success.
The team, the Product Owner or whoever is responsible for prioritizing the hypotheses for validation, should keep the organization aligned with the hypotheses that are being tested and which results are being obtained. This allows for the organizational structure to start serving the objectives, and not the other way round. Business results will drive a fluid org design to emerge with the buy-in of all employees, because it makes sense as a value-driven solution.
A word to the wise: OKR isn’t a silver bullet, either. Like any tool, it can be used in such a way as to distort behavior. Marty Cagan even warns us that if we pressure a team too much into achieving a given goal, we may not like the way the team manages to achieve it. So we always have to maintain a critical, questioning thinking, using empiricism to understand what’s best for every organization.
Want to know more about OKRs?
The ebook “OKRs and business strategy for transformation: a brief guide to best practices” is already available at Amazon!
