To be or not to be agile at your company

I guess you are wondering if this is a purely theoretical and philosophical article. If this is the case, you better review your pre-assumption right at this point. The aim is not to, as Shakespeare, deep dive into the soul of your company, but rather to take a realistic approach of what is going on in the market.

For starters, one thing you can’t deny (or you can, if you have been lost in the Antarctic continent, with no access to the web): The world is changing in an even faster pace than we could ever imagined.

The second thing you can’t deny: The organizations, as they are designed now, are not able to keep up with this pace of change.

These same companies are struggling to thrive on the market that is becoming more and more competitive each day and, if the executives rely only on the “This is the way we have done during the last 20 years”, they are already part of the past and they couldn’t even realize it yet. It’s just a matter of time. Unfortunately.

Change is happening, where you like it or not.

It’s like economics: You can ignore it, but it won’t ignore you.

The question is now: How can I prepare my company for today’s situation, but also, for the future? How can I incorporate quick feedback, have experimentations and learnings into small periods of time, pivot or persevere according to them and to the strategy of the company? How can I be able to adapt quick to the market while still being predictable and sustainably deliver products and services to my customers?

The answer to all of those questions is one: You have to embrace enterprise and business agility, regardless of the methods or framework you’re gonna choose (Scrum, Kanban, SAFe, Scrum of Scrums, LeSS among others. Agile is a perfect fit for situations where you have to quickly adapt and move to the next strategic thing, with a minimum effort, knowing that you’ll learn all along the way. Agile is not made for simple context, where we master the technology, where the scope is sort of known/fixed, but it’s made for complex projects and situations, where we have a short time to figure out what to do before we do anything, where our resources are rare, and we have to deal with many constraints.

Now that you know why we have to do it, it’s also important to know how we do it.

Although there is no cake-recipe about how to implement (if someone tries to sell it to you, run from it), some patterns have emerged over time. They will ease a successful adoption and, also, will help your company on thriving during these very uncertain times.

Here you have some of them:

• Understand the objectives of your organization to transform to agile: Implement agile can’t be your objective, it needs to be a mean to an end. As a leader of your organization, you have to identify what are the problems you need to solve. Is it time to deliver your products to market? Is it lacking flexibility? Is it a quality problem? Is it to reduce the organizational complexity to develop your products? Do you have issues aligning your products to the strategy of your company? You have to dig deeper into your organizational problems, identify them and then, check if agile can be used as a tool to help solving them. If yes, then think about implementing agile.

• Communicate the vision: Having an agreed vision for change and not communicating it, is the same as it didn’t exist. Communicating the vision is extremely important as it creates a shared understanding of the desired future state of the organization, but also helps to motivate people to act as one and will help coordinating all the actions towards this common objective.

• Bring people along: Create a small group of very engaged and motivated individuals to carry on with the transformation while looking for improvement points. Work with the teams, leadership and stakeholders to ensure that people have whatever they need in order to do the best job as they can. These group of people shall have representative(s) from management, as managers are the only ones that can effectively change the system (the company). Also, we can never forget that the these leaders have as a mission to lead, that means, they should lead the transformation itself. It’s like Drucker said, “If you want people to be motivated, tell them their work is important”.

• Decentralize decision-making: Move the authority for decisions to where the information is. You have to help preparing the teams to make decentralized decisions by investing in their technical competence and by providing organizational clarity with decision guardrails. Can these teams decide whether they will create a new development center in another country? Most likely not. Can the teams decide if they need a new CI/CD platform to speed up their job? Most definitely yes.

• Do not declare victory too soon: Leaders have the tendency to declare victory too soon, way before these new practices were converted into new behaviors and these new behaviors have been incorporated or changed the culture of the company. Changing practices, behaviors and the culture (as a consequence of it) is a fight for which we have to be resilient and prepared. Stay alert, stay sharp, stay focused and don’t declare victory to soon. But not to late either! The key is to celebrate small victories, without losing sight of the next challenges to come.

Why not or when not to use agile?

As stated earlier, not all the organizations are a good fit for agile. Please, don’t get me wrong. It’s not that your organization is not “good enough” to implement agile, but rather, there won’t be any or very limited benefits on implementing agile. In this case, the gains would not justify the risk and effort. Take a look at the graph below, it’s known as Stacey complexity model. It explains the context that agile and a classic (waterfall) approaches will produce better results.

As you see on the graph, agile can bring the biggest benefits on either complicated or complex environments, with regards to technology and stability of requirements. It doesn’t mean that standard methods cannot be applied on complex/complicated environments, it’s just that it’s not the correct tool to bring the best results. Same way as applying agile on simple contexts, it won’t bring the benefits expected.

So, before doing your “bricolage”, better choose the right tools for the job. If you only have a hammer, everything will look like a nail.