9 things you should get right if you want your company to become Agile

Easier said than done! One team can become Agile with a bit of support and coaching, but once we move to organizational level, we need to think about cross-team collaboration, goal setting, budget allocation and many other elements that have to change. Regardless of the framework, approach to transformation and size of organization, there are a few elements that we need to get right in order to achieve organizational Agility.

Sometimes you might hear an opinion that truly Agile organizations should be completely flat and managers should be all fired. And that’s how a lot of great opportunities for Agile transformation are missed (because obviously managers are not thrilled about this idea).

We definitely want to achieve a flatter organization, and decrease the number of levels of hierarchy, but more importantly we need to teach managers how to be Agile leaders. It means that they no longer will be making decisions and giving orders, but would instead support the teams, enable cross-team collaboration and coach others. In every organization there would always be a few people in managerial positions who value power more than anything. For them this transition might be quite painful, while others usually find their new role much more interesting. Instead of being the only decision maker, you now get to soak in creativity of multiple Agile teams, help them when they get stuck and share your knowledge and skills, enjoying their growth.

The whole organization needs to go through trainings in order to become Agile, but the most critical role to get things right is Product Owners. They will need to learn how to set up team’s goals, how to create and prioritize backlogs, how to work with stakeholders and how to motivate the team. Product Owners should be purpose driven, independent and ambitious, have in-depth knowledge of the product and great soft skills.

It is very important to organize an internal bootcamp or academy for Product Owners before undergoing the transformation so that they learn and practice new skills, while getting to know each other and building a strong network which would later enable collaboration amongst Agile teams.

One of critical steps of Agile transformation is the organizational design where we identify the new teams, roles and reporting lines. In most cases we would be dealing with functional teams that have to be converted to cross-functional. It is absolutely critical for the success of transformation to ensure that teams have end to end responsibility over the products. A team of designers cannot take full responsibility for the design of the app, but a team consisting of a Product Owner, a designer, two engineers and a tester can.

Agile transformation has to start with mapping out all the products and processes in the organization and redesigning the whole structure to build cross-functional teams and giving them full product ownership.

When teams take full end-to-end responsibility over a product, they need to feel safe making decisions, experimenting and trying out new ideas on their own. Experimentation and new ideas might lead to success as well as to failure. In traditional organizations success is rewarded and failure is punished. In Agile organizations both are rewarded. Failing means that you tried something new and got some valuable learnings. Repeated failure is of course a different story, but experimenting and trying out new things should be encouraged in order to drive innovation in the organization.

We can learn from Scrum or other frameworks how to organize the processes inside one team. But this team doesn’t exist in vacuum - when we undergo an Agile transformation, we need to think how to organize coordination and collaboration across teams in the best ways. It is tricky, because on one hand you would want to reduce bureaucracy, encourage self organization and common sense, but on the other hand in a company new to Agile people need some guardrails, otherwise knowledge might not be shared and dependencies won’t be addressed.

Some frameworks like SAFe give a detailed overview of cross-team processes, but in most cases those need to be redesigned in order to fit into company context and actually bring value.

In a lot of traditional organizations people set their personal goals or KPIs and then get evaluated by their managers (or peers and managers) once in a while. In Agile world this might cause problems, especially if personal goals of people on the team don’t align (and they probably won’t align).

Part of Agile transformation is changing the approach to goal setting. We are now looking at the team goals, not individual goals, and the performance management should be adjusted accordingly. At the same time, it is critical to support each individual’s growth and help them to develop professional skills, so performance management system has to consider that as well.

You can still get the vendors involved in your product development after undergoing the Agile transformation, but the approach might need to change. The key problem with outsourcing is that it often causes series of mini-waterfalls and creates a black box. Most commonly a team needs to define the requirements, submit it to vendor, wait for a while (black box) and then get the final result which won’t necessarily meet their needs.

In the Agile world we try to treat the vendors as members of our team, doing planning, reviews and retrospectives together. They need to be involved in our processes to better understand our customers and our requirements. We need to be involved in theirs to request changes before it’s too late and provide information when needed.

The challenging part is the contract (not always it is possible to merge vendors in your team) and additional Agile training you might need to provide to your vendors.

After Agile transformation the teams would (hopefully) become self-organized and will start setting up their goals on their own. But how can we make sure that their goals are all aligned with the company goals and the overall strategy? How do we make sure two different teams are not working on the same thing without knowing? And finally, how do we coordinate cross-team dependencies?

All of that requires a cross-team goal setting process. Most commonly it is done in the form of OKRs on a quarterly basis. OKRs allow us to have teams coming up with goals aligned to the company (or department) OKRs, while having enough flexibility deciding what and how they want to achieve. The process of drafting, reviewing and finalizing OKRs, as well as tracking and tackling the dependencies is not trivial and has to be tailored to the organization.

Finally, budget. This can often be a big pain point, especially if the company used to have rigid project management protocols in place. Teams need to have flexibility to quickly respond to change, so locking in the exact budget per project would prevent them from being successful.

Just like with all other aspects of Agile transformation, there is no one size fits all kind of solution, and it should be tailored individually to each company’s context, but one of the best practices is usually allocating budget brackets to teams while allowing flexibility and requiring approvals only for large expenses. In return teams take responsibility for creating full transparency and delivering business outcomes according to their team’s vision and goals.

Of course this is just a high level overview, and each of these topics deserves multiple pages of detailed description. It is important to understand though, that in Agile there are no things set in stone (other than principles and values), so every transformation case is very individual and might require different approach.