Team Agility Vs Business Agility

Team Agility is when a delivery team is using Agile practices and techniques to produce software or value. They might be doing daily stand ups, working in sprints, collaborating closely and have a consistent rhythm/ heartbeat. They might even have everyone co-located and available for ad-hoc conversations.

However, they might not have as much empowerment as they need. Sometimes a decision may be made outside of the team on their work. A solution may be created for them and handed over for them to deliver. Promises may be made on their behalf without their full commitment. Some stakeholders may occasionally make unfeasible demands.

These teams are working well within their Agile delivery team “bubble”.

So what is Business Agility?

Being Agile as a business starts way before the delivery process. It’s before estimation. It’s before planning. It’s before refinement/ analysis. Business Agility begins with the inspiration and incubation of ideas.

When new ideas are formed, these are just opinions until proven otherwise. They need to be fleshed out and tested before it moves from a hypothesis to a validated feature. The way to do this is to engage and involve your dev team early on. These people are the domain experts of the product.

They will have lots of ideas and feedback based on their day-to-day work on the product. Going to the team with an idea/ problem/ goal or challenge, is a brilliant way to help get their buy-in and get them motivated to achieve the objective!

Additionally, ensuring the team are across the testing of these ideas, either through users or A/B testing helps them to stay close to the analytics and KPIs of the product. This collaborative and feedback-centric approach will increase your speed-to-market as well as increasing the likelihood of building the right product.

Another key ingredient to building an Agile business or product is empowerment. When decisions and sign-offs are made outside of the team without involving the people actually responsible or accountable for delivering the product, the team may slowly become disengaged.

If they have little or no input to the shaping of the product, they might feel under-valued. If product priorities are constantly decided and changed by people who are not Product Owners or Product Managers, then the people in these roles can start to become undermined and frustrated.

Empowering the teams and individuals involved in creating the product, means trusting them to deliver the required results. Putting your trust in this group of creative people, helps them to feel invested in the future of the product. Giving them autonomy will enable them to influence the direction that the product takes. This will result in getting to a successful product, quicker.

Typically, accurately funding Agile delivery teams is difficult to do in a traditional way when there is limited certainty about the end solution. When Agile teams are placed into traditional funding and governance models, it poses some challenges for the overall business when striving for the goal of being Agile as a business.

Predictability and certainty will still be required at a high-level, even though at the team level, they will be trying to operate in a dynamic, validating and value-driven method.

This mixture of flexibility and adaptability with predictability and certainty can occasionally cause some frustration when it comes to the planning and reporting of these teams. Looking forward, an alternative funding approach is to fund a team of a given size, for a defined period of time, whilst accepting some uncertainty about the actual features that they may deliver at the end of that financial period.

The role of a Software Engineer in its purest form is not to write code, but to solve problems. So with this in mind, we could aim to create problem-finding governance and funding models.

In this approach, the funding of a team is based on the goal or outcome that they are setting out to achieve. Rather than focus on the functionality or how something looks and feels, the focus shifts to the value or benefit the work results in.

This goal or outcome-based funding gives the teams the flexibility they need to be able to innovate on the best solution as they learn more about the users and their problems. Building in the room for this validated learning and the emerging complexities, enables a business to respond to change, whilst following an adaptable plan, and therefore realising benefits in an Agile way.

Summary

To conclude, it’s relatively common for delivery teams to achieve Agile maturity over time, and get to a point where they are disciplined and experienced enough to successfully deliver stuff in an Agile way.

However, to become Agile as a business, it takes a much wider group of people to buy-in and be invested in the overall efficiency of moving from ideas to delivering value.

There are likely to be some challenges faced, such as, fear of change, increased collaboration and empowerment, and accepting some uncertainty when trusting autonomous teams.

Once you’re able to start improving these aspects through effective coaching and servant-leadership, you may well be on the journey to achieving overall agility as a business.

Arrange a Conversation