Was the agile manifesto made for fast-growing teams and scale-ups? Tony Grout, Enterprise Agile and DevOps Transformation Director at Atlassian (now Chief Product and Engineering Officer at Alfresco) gave a great talk at UXDX2018 on how to improve agility at scale (and the signs that shout that agile isn’t scaling for you).
18 years ago 17 people got in a room in Utah and argued about the future of software. They decided that they had enough of bad practices, unhappy developers and churned customers, and created the Agile Manifesto. Although revolutionary for its time, the agile manifesto did not talk about scaling. Because fast-growing software companies were not a common challenge in 2001.
As soon as you go beyond one team, you already have scaling challenges that the agile manifesto was not addressing.
“It’s like being in the battlefield and the battlefield is filled with fog and you have no idea where the enemies are, where your friends are and what you should be focusing on at any given time.” Click to tweet.
Watch the full video with Tony, or read on to see his insights.
So how can you improve agility at scale?
Scaling is all about tracking the flow of work and optimizing the flow of value. If you get this right, you’ve nailed it.
We have to zoom out and think about how work flows through the teams and thinking about the organisation as a whole. Zooming out and focusing on the overall flow, company structure and objectives is the key to delivering value.
1. Delivery Over Individual Teams
The issues with teams and managers that want to be in the best teams is that they typically optimise to make sure that everybody on their team is really efficient. This leads to a common challenge - many managers are focusing on efficiency over effectiveness. They locally optimise their team to excel in their performance. The issue comes when everyone focuses on the efficiency of their own team and forgets about the big picture. Sometimes taking a step back, discovering where the bottlenecks are and re-assigning work is the right approach. For example, if the DevOps team is operating super fast and the UI team is always behind their deadlines, it might be worth investing some of the engineering team’s time in building a solution for the UI people to move faster.
Always make sure you’re optimising for the flow of work through the teams. This might mean some teams might need to be slower.
"It’s not about one team moving fast, but for all teams to be delivering value." Click to tweet.
Capacity planning needs a common currency. Managers have to make sure that everyone is talking in a common vocabulary.
Tony gives a great example of how all the International Space Station components were built in different countries. To facilitate the process, they created a special role, called “Interface manager”. All Interface managers were working together to get a shared syntax and vocabulary across teams and departments.
Agile teams, regardless of how adaptable, will always need a common vocabulary and language when they work together.
"Harmonise the edges. Make sure you all are talking in a common vocabulary when it matters." Click to tweet.
3. Minimize your dependencies
Why are you always waiting so long for features?
Here’s a simple task: try and get 4 team members on a team dinner in a fancy restaurant. To get in the restaurant though, everyone must be there at 8 o’clock. If one person is late, they won’t be seated. The reality is that the chance of everyone turning up on time is 1 in 16.
Now, imagine if you have 4 teams you have to rely on to ship the next version of your product. The math is the same - the chance of being on time is 1 in 16. And this is if you don’t factor in deliverability within the team.
According to recent research that Tony shared, 5-9 people teams are 6% more productive than 9-16 people teams, but 2x more unpredictable if they depend on another team. Two small teams will double the uncertainty to ship your product on time, so the best approach is to experiment in your organisation.
"Minimize the team’s dependencies, because it doubles your uncertainty. Experiment with bigger teams." Click to tweet.
4. Decide close
Leaving the decision to senior executives only will make you a 100% winner of a 1% market. You should trust your team and let people who are closest to the problem and the user to make decisions, test and execute. If the person with the data is the person at the bottom, you have to make sure that your process allows the person at the bottom to make decisions independently.
Make decisions close. Leave them to the people most familiar with the problem. Click to tweet.
5. Make sure you put in guardrails not deep methods
A fantastic example is Lloyds Bank’s Money Manager gave a great perspective on how simple testing instead of deep research, studies and analysis could help us avoid catastrophical product mistakes. Lloyds Bank spent millions of pounds on building a budgeting tool that no one used or needed. It turns out that regardless of the extensive research, people don’t need an app to tell them how to spend their money. This could have been avoided with simple testing.
You can only learn a lesson after you run a test. Ideally, your tests should be smaller than what Lloyds Bank did.
Tony Grout is really passionate about the idea of building “guard rails”, instead of focusing on big complicated methods. Once you roll out and bake in a complex method into your organisation, it makes it very difficult to change if it’s not delivering and could lead to years of restricted opportunities. Instead, organisations need to build guard rails to keep team’s brains engaged and encourage them to improve their processes. The easiest way to implement this, according to Tony, is agree on a few simple KPIs, communicate them well with the wider team and let them decide if whatever they’re working on is moving towards any of these goals, within their measure of scope. People are smart, let them deliver.
To improve agility at scale, get a bigger perspective. Zoom out. Apply the above. And you’ve got this. Click to tweet.
I hate "It depends"! Organisations are complex but I believe that if you resort to it depends it means that you haven't explained it properly or you don't understand it. Having run UXDX for over 6 years I am using the knowledge from hundreds of case studies to create the UXDX model - an opinionated, principle-driven model that will help organisations change their ways of working without "It depends".
Free Community EventsSee all
Get latest articles straight to your inbox
A weekly list of the latest news across Product, UX, Design and Dev.