Teams are only as effective as the system in which they operate. So when teams are struggling to execute, it’s worth taking a step back to understand the systemic challenges.

Strategy and execution may seem relatively independent of one another, but in fact they are heavily interdependent. Recently I put this diagram together for a client to try and explain the relationship between strategy, structure and process (execution).

It all begins with strategy. Strategy, or a lack of it, causes two major problems:

Lack of Alignment

Ideally team structure should fall out of the strategy. Teams should be formed to align around strategic goals which they can independently achieve.

When teams are poorly aligned, it creates a network of dependencies which introduces a heavy process burden and long delays. That reduces speed of learning and speed of execution.

Lack of Focus

While all companies believe they have a strategy, they are often weak — by which I mean they don’t enable priorities to be determined and trade offs to be made. A clear strategy should enable better decision making. When it fails to do that, everything is a priority and your execution pipeline becomes a traffic jam. Teams lack focus, they are spread too thin and this again results in poor execution.

Strategy depends on execution — there is no point in having a great strategy if you cannot deliver on it. Likewise efficient execution depends on having a clear strategy.

Teams are only as good as the system in which they operate. If we want high performing teams, we have to enable them by creating well designed systems which set them up for success.

Introduction

I often feel in the agile world we have a tendency to work solution-first — even whilst we coach others to do the opposite. This solution-first approach is driven as much by businesses as it is by us as individuals. Businesses will often hire agile coaches/scum masters to “do” rather than to “achieve”. We get hired to coach, to introduce particular methodologies etc. This isn’t inherently bad, but having worked closely with some excellent product managers over many years, I’ve realised that applying a product thinking approach to the agile coaching space can deliver better value for our customers and users — i.e. the businesses that pay us and the people within those businesses that we help.

Thinking Like a PM

Define Outcomes

When I’m approached to work with a business, I like to steer the conversation away from what I will do to what I need to achieve. What are the desired outcomes? If my engagement is successful, what would that look like? What would change? This conversation helps me to understand the outcomes and success measures the business actually wants — and remains agnostic of particular solutions.

Discover

Once I have an understanding of the desired outcomes, I explore the “problem space” in more detail. I call this activity discovery, and it serves exactly the same purpose as product discovery. During discovery I want to understand how things currently work, what works and what doesn’t. What are the pain points, what are the needs?

In order to find out, I talk to my customers — in this case the people within the business. The people I actually speak to depend on the desired outcome, but I’m always seeking to get a wide range of perspectives so I have a really good understanding of the problem space.

As well as helping me to define problems, I build empathy during these conversations. And there is yet another benefit of this discovery when it comes to introducing change:

• Firstly people are more open to change when they feel they’ve been consulted
• Secondly, it helps to sell change because I can reference a particular problem or pain point and describe how the change I’m recommending will help.

Identify Insights

Defining the problem space is an exercise in gathering information, but the magic really begins to happen when you identify insights. I identify insights by root causing. By asking “why” I can start to uncover the underlying problems that sit beneath the symptoms that have been described to me.

These insights are really the secret sauce of discovery. It’s these insights that enable me to develop a strategy and specific tactics that will result in successful change.

Execution

The next step is of course to deliver on that strategy and execute the tactics. change. Once again I follow the PM playbook by prioritising and then using a test and learn approach. I start small, gather feedback and iterate.

Conclusion

I have found this approach has immeasurably improved my ability to deliver results. It also helps manage expectations — in discovery I invariably uncover systemic issues, and while I can consult and support on tackling these problems, it is not normally appropriate for me to lead on those changes. This helps me manage expectations and secure buy-in for wider change.

Coaching, methodologies and practices all have their uses. However, I find it helpful to think of them as a toolkit which I can leverage once I understand the problems I need to solve and the outcomes I need to achieve. I can then delve into my toolkit to tailor really targeted solutions that can deliver lasting improvements quickly.

Could I help your business identify opportunities to improve? I’m a Business Agility Coach & Consultant helping companies adopt lean and agile working to increase impact, speed and engagement.

Find out more at betterfasterhappier.com

Cross-functional (XFN) teams can seem counter-intuitive. Why? Because we’ve become institutionalised to think that businesses should be organised by function. But cross functional teams are more common sense than crazy. Here’s why.

Last year I supported a company to adopt a fully XFN model. They already had XFN product and tech teams, but they wanted to expand the model and integrate business partners. Not everyone was bought in. Some business partners were very sceptical. And that’s not uncommon. XFN teams can be a tough sell outside of tech (and sometimes even within tech!) I realised I needed a better way to engage the sceptics, and this is what I came up with.

Imagine you own 3 football teams. One team consists entirely of goalkeepers and defenders. The second consists entirely of midfielders and the third of forwards and strikers. Organising your teams in this way is akin to organising by function — you have designed your teams based on their skills, on what they do. The problem is, it takes a mix of skills to win games. Your teams are going to struggle…

If you re-organise your 3 teams so that each has a mixture of defenders, midfielders and forwards, you have now created 3 XFN teams. Each team now has the mix of skills required to win games. The job of a goalkeeper is to win the game; the skill he brings is saving goals. The job of the striker is to win the game; he uses his goal scoring skills. The individual players’ jobs don’t change, but they now play in a team with the complementary skills that will enable them to win games.

XFN teams make sense because strategic goals, like football games, often require a mixture of skills to achieve them. The rationale of cross-functional teams is to optimise your organisation design to support the achievement of your strategic goals. You organise people based on what you want them to achieve rather than by the particular skill that they bring. And the benefits?

• When a team has all the skills they need you liberate them to move at speed because you have removed dependencies
• You create a melting pot of diverse skills which increases innovation
• You break down silos — no more “us and them”

I have found the football analogy helps people understand why cross-functional teams make sense — it creates an “aha” moment! It doesn’t kill scepticism but it does spark some curiosity and a willingness to experiment with this type of structure.

A few other reasons I like this analogy:

• Football teams have a shared priority: to win the game. (Good) XFN teams have a shared outcome to achieve
• Football teams have a shared game plan. (Good) XFN teams have a shared strategy.
• Football teams prize team results over individual performance. (Good) XFN teams optimise for team success over individual glory.

When you align people around outcomes you set them up to achieve better results faster.

Also worth noting two important things I’ve learned on my journey so far:

• Cross-functional teams are not the same as Scrum teams — they are about creating alignment around outcomes and strategy and the skills to execute on that strategy independently.
• There’s no need to be cross-functional for the sake of it. Some outcomes can be achieved within a function or functional team, and that’s fine. If a team has all the skills required, they are already independent.

Are you looking to adopt cross-functional teams? I am a Business Agility Coach & Consultant helping organisations to grow, scale and deliver value fast.

Find out more at betterfasterhappier.com.

I recently posted about this on LinkedIn, and it proved surprisingly popular. So I thought I’d share it here, together with some of the discussions the post generated.

Recently I’ve read books about Amazon (Working Backwards), Google (How Google Works) and Netflix (No Rules Rules). I consider them to be successful agile organisations and I want to learn from them. But search these books for a mention of agile — or scrum — and you get precisely zero results. So what do they talk about?

Each have individual cultures — and in many ways quite different cultures. But here are the most common themes:

1) Talent

Working Backwards and How Google Works dedicate a whole chapter to talent. 25% of No Rules Rules is devoted to talent and maintaining “talent density” — a high percentage of high quality people.

2) Culture

How Google Works and Working Backwards both kick off with a chapter dedicated to their culture. No Rules Rules is entirely about the culture of Netflix and the steps they took to build it.

3) Leadership

Each chapter in all three books discusses the role of leaders — in everything from innovation, to strategy, decision making and recruitment. When it comes to the latter each specifically calls out the importance of hiring well. At Amazon, Hire and Develop the Best is a leadership principle. In How Google Works, hiring is described as “the most important thing a leader does”. And in No Rules Rules? “Your number one goal as a leader is to develop a work environment consisting exclusively of stunning colleagues.”

While there are other common themes, I’ve called these out because my impression was that they are foundational. They are the prerequisites for everything else these companies are able to do.

Normally we would talk about Leadership -> Culture -> Talent. I’ve flipped the order because what struck me was that each culture was possible only because of the talent. In No Rules Rules, “talent density” is explicitly called out as a prerequisite for every other element of their culture. Nothing else they do is possible without hiring the right people first.

These companies are not necessarily perfect, but it’s hard to argue with their success. I found all three insightful and inspiring. Collectively they make for one of the best learning experiences I have ever had and they left me feeling energised.

Arguably this is confirmation bias, but it reinforces what I’ve learned from my own experiences: if you want an agile culture with high autonomy and innovation, you need to hire for it. Great leaders hire great talent, great talent enables great culture. Focus on leaders, talent and culture. Simply hiring agile coaches and scrum masters or adopting methodologies isn’t going to cut it.

So that was the post, and here were some of the interesting challenges people made in the comments...

One theme amongst the comments was that, just because agile and scrum weren’t mentioned in the book, doesn’t mean those things aren’t happening there. It’s a fair point — and some people that have worked at these companies say scrum is used at times, as are other agile approaches. My take is that while these things may be used, they weren’t mentioned in the books because they were not considered critical to success. Instead leadership, culture and talent were the driving factors.

Someone pointed out that attrition at Google and Amazon is very high. This actually doesn’t surprise me. These are very high performance companies and my impression was they attract people who are extremely driven. Not everyone is going to enjoy these cultures. They are high energy work places. They don’t sound peaceful! At Amazon in particular it was extremely evident that people work very hard. That’s not automatically a bad thing, but as Amazon themselves say, it’s not for everyone.

Another comment suggested that it’s easy for these companies to hire top talent because they are enormously rich. That’s true — now. But these companies weren’t born rich. There were plenty of stories of crowded offices and desks in corridors. At one point Netflix had to cut a third of its workforce. Ironically that proved to be a turning point. Performance rocketed and gave birth to their concept of talent density which they claim is central to their success. So, personally I don’t buy the argument that “it’s easy for them”. It didn’t start easy, and each book is intentionally instructional “We did it, and you can do it to!”

But my favourite comment of all came from Aki Taha — he worked at both Google and Netflix. He shared with me an article he’d written on the differences in the hiring processes at Google, Netflix and Uber (where he also worked). It is fascinating how very different these processes are and how they originated from the culture of each organisation. The article is written superbly, I highly recommend it and I’ve already subscribed to Aki’s blog.

Via their hiring process, companies communicate — loudly — what it’s like to work for them. Are you listening for the signals?

All in all the post generated a lot of commentary — 214 comments and counting. I’ll be interested to see what you think!

Are you looking to create an agile culture in your company? I am a Business Agility Coach & Consultant helping organisations to grow, scale and deliver value fast. And I firmly believe that talent is fundamental to achieving these.

You can find me at betterfasterhappier.com.

Introduction

I recently wrote about the limitations of the Agile Manifesto when adopting agile. Following on from that I thought I would look at the limitations of agile methodologies, and discuss why guardrails prove an alternative — or complimentary — approach to putting agile software delivery into practice.

The Limitations of Methodologies

Agile adoption tends to be dominated by methodologies — Scrum, Kanban, LESS, SAFe and so on. And this is not altogether surprising. Fundamentally lean and agile are about a set of principles, and translating principles into practice is hard. A set of principles with no guidelines are much like ingredients with no recipe. The various methodologies provide a recipe. These recipes can be helpful, but the danger is that following the recipe becomes more important than the results that recipe achieves.

Methodologies become counter productive when we understand what we should be doing but not why. To be clear, I am not anti-methodologies per se. They form a useful part of my toolkit. However, the goal is to achieve agility, not to adopt a methodology.

Rather than focus on methodologies, I have found it helpful instead to use a set of guardrails to guide agile adoption. In this article I’ll discuss the purpose of guardrails and share a set that have worked well for me.

Using guardrails

Back in 2018 I attended a training course on how Spotify practices agile. One of the many useful things I picked up was the concept of “Minimum Viable Agility” (MVA). This is a concept Spotify had adopted from Em Campbell-Pretty’s book Tribal Unity. In the book MVA is described as follows:

Consider the minimum level of agility you expect from teams and make this the only constraint you place on their work practices. A number of practices that have close to universal applicability.

The “essentials at Spotify” are non-negotiable — these are things teams must do. Outside of these, teams are free to choose how they work.

I was really inspired by the idea of using guardrails. I see them as an alternative form of “recipe” — a different way to help teams translate principles into practice. I have found they provide enough practical guidance to adopt agility whilst also giving teams the autonomy to tailor their practices and processes to suit their particular context. A team practising high tempo experimentation has a very different context to a team building a large feature. A good set of guardrails can ensure both those teams achieve agile working whilst allowing them to adapt their ways of working to their own particular needs.

Defining Guardrails

When it came to defining my own set of guardrails, I started by being clear about what they should achieve. I have previously written that I define the goal of agility as working in short feedback loops:

The goal of agility is to work in short feedback loops. Short feedback loops are important because they allow us to learn, validate and course correct early.

By course correcting early we can:

• Avoid waste and increase value by ensuring we’re building the right thing — that ultimately, the products and services we create meet our customers’ needs and drive value for the business.
• Avoid expensive mistakes and improve quality by ensuring we’re building the thing right. Early validation that our software behaves as expected ensures we’re building reliable, resilient products.

In summary, agility means optimising to work in short feedback loops so we can increase value and improve quality.

I would argue that as long as we are working in short feedback loops, the methodology or framework within which we work doesn’t matter too much.

With this goal in mind, I worked backwards to define a set of guardrails that would define how to work in short feedback loops.

Delivering in Short Feedback Loops

Through long and often painful experience, I have learned that delivering in short feedback loops is actually quite straightforward. I have boiled it down to this simple formula:

Small batches + Limiting WIP = Short Feedback Loops

I have consistently found that if work is broken down small and there is a focus on finishing work (using WIP limits) short feedback loops are achieved. So these form the heart of my guardrails. Beyond these are some additional supporting practices that I believe are valuable.

My “Minimum Viable Agility”

The guardrails I’m going to describe work well for software development. While the concept of guardrails is holistic, I wouldn’t automatically use this particular set outside of software development. Practical guardrails for a marketing team might have some overlap but wouldn’t necessarily be identical. It’s also worth noting that these guardrails are specific to software delivery — they presuppose that discovery has been completed and we are confident that we are “building the right thing”.

This is my default set of guardrails which I then tailor as necessary.

The image briefly summarises the purpose of each guardrail, but here is a little more context for each.

Define goals and measures of success

As I described above, one reason to work in short feedback loops is to increase value. Before we build anything we should understand what value we expect to deliver and we should know how we can measure the success of our deliverables.

Measure platform health

The second reason to work in short feedback loops is to improve quality. If we are measuring quality we can ensure that this is indeed being achieved. I have also found this particular guardrail reassures teams that we are not trying to increase speed at the expense of quality.

Work in small batches & Limit work in progress

As discussed above, these are the critical elements that achieve short feedback loops. As “small” is relative, I find it useful to be specific about what “small batches” actually means. I adapt this depending on context, but by default I suggest that “sprint level” stories and tasks are small enough to be completed in 3 days or less. So the workflow from “To Do” to “Done” (on production) should be achievable within 3 days. However, this depends on having feature toggling capability and continuous deployment. Where those don’t exist this number will be challenging — although it is definitely worth having it as a goal to work toward!

WIP limits are dependent on the team size and shape so they cannot be prescribed. I encourage teams to consider board and column level limits and experiment to find the optimal set. As a rule of thumb I recommend a board WIP limit the size of the team — so if there are 6 people in the team, aim to have no more than 6 items between “To Do” and “Done”.

Visualise work & Hold daily stand-ups

Both of these support limiting work in progress and encourage teams to focus on finishing. While visualising work highlights bottlenecks, stand-ups provide the opportunity to discuss and resolve them.

Stand-ups are often run as status updates, but I find they are more valuable if used as a short planning session for the day ahead. By walking the board and focusing on tickets rather than people, the team can decide where to spend their effort that day in order to keep work moving and get it completed.

Hold regular retrospectives & Measure cycle time

Both retrospectives and measuring cycle time support continuous improvement. Retrospectives are the feedback loop to ensure teams have time and space to inspect and improve how they work. They should be “regular” to keep that feedback loop short — as with everything else, we want to course correct early.

I’m a huge fan of data-driven process improvement and there are a host of metrics that I use, but cycle time is the daddy. Cycle time measures the length of our feedback loop; as that is ultimately the goal, it is the one metric I consider to be non-negotiable. Retros provide the ideal opportunity to review cycle time and to provide an objective measure of improvement. It’s worth noting that I’m not suggesting retro discussions are limited to discussing cycle time, but rather that it is a useful input and a valuable topic.

Why are my guardrails different to Spotify’s?

There is nothing in Spotify’s list I disagree with, it is simply that my guardrails have emerged from a different use case. I typically work with teams where a continuous deployment capability, automated tests and code reviews are the norm. Those practices have been specified as part of a technical strategy but have not necessarily resulted in iterative agile delivery. My guardrails were defined to ensure that delivery practices exploit those existing technical capabilities. The ability to continuously integrate and deploy is not much use if we don’t work in small batches. Conversely, working in small batches is very hard to achieve if you don’t have automated testing!

The key to guardrails is to make them relevant to the context. Guardrails, like methodologies, stop being useful if they are one-size-fits-all.

Conclusion

I have now had the opportunity to apply my guardrails across multiple industries, multiple platforms, multiple companies and multiple teams, and thus far they have always worked. Very often the teams I work with are already using a methodology (typically Scrum or Kanban), but with limited success. Helping teams understand the goal of agility and introducing these guardrails has enabled them to move beyond methodologies to agility. It has also given those same teams the confidence to flex their ways of working. They can shift their focus to achieving agility rather than conforming to a methodology.

That said, if you want to try using guardrails, they need to work for your particular context. Take inspiration from Spotify’s guardrails or my own, but define a set that makes sense for your company and your teams.

Has this article piqued your interest? Could I help your teams? I am a coach and consultant that helps teams and organisations adopt agility. Find out more about what I do at betterfasterhappier.com.

The agile manifesto is arguably the most unhelpful document in the history of technology. There. I’ve said it. Don’t get me wrong, I don’t disagree with anything it says, and I’m grateful that it challenged conventional methods of software delivery. Not to mention which, it has triggered a much needed re-think about how we all work which is (very gradually) creating much better ways to work.

That said, the manifesto does have some serious issues — to name just a few…

• It’s not terribly clear (we’ve spent the last 20 years arguing about what agile actually is)
• It’s never been iterated on (continuous improvement anyone?)
• Principles are very difficult to put in to practice (enter Scrum)
• It’s open to (mis)interpretation (“We’re agile, so we don’t plan…”)
• It tends to focus more on agile delivery and output — building the thing right rather than building the right thing

I could probably go on, but the point I want to make is that as a means to communicate and market agile it falls short. The goal of agility is unclear.

As someone working with businesses and teams to help them adopt agile, the first thing I have to do is sell it. From software engineers to CEOs, I need to be clear on what agile adoption means for them and how they will benefit.

When answering the question “what is agile?”, many doggedly cling to the agile manifesto as a means to explain. I have done that myself in the past, and learned through failure that it doesn’t work. To that end I’ve come up with new ways to answer that big question. While I always tailor my “agile - what & why” pitch to the audience, I thought I’d share the two definitions that I use most often.

Selling Agile to Teams

More often than not, software delivery teams are now expected to work in an “agile way”. And they do so faithfully, but often blindly. They work in sprints, they hold stand ups, they attend retrospectives. But few could articulate the purpose of these activities — they know the what, but not the why.

When engaging with this audience, this is how I define agile:

“The goal of agility is to work in short feedback loops. Short feedback loops are important because they allow us to learn, validate and course correct early.

By course correcting early we can:

• Avoid waste and increase value by ensuring we’re building the right thing — that ultimately, the products and services we create meet our customers’ needs and drive value for the business.
• Avoid expensive mistakes and improve quality by ensuring we’re building the thing right. Early validation that our software behaves as expected ensures we’re building reliable, resilient products.

In summary, agility means optimising to work in short feedback loops so we can increase value and improve quality.

And that’s it. If you understand that as the goal of agility there is suddenly a good reason to adopt it — more value + better quality. Secondly, now that you understand what you’re trying to achieve, you can start figuring out how you and your team can work in short feedback loops — instead of just doing what “Scrum says…”.

If you treat working in short feedback loops as your ways of working goal, you shouldn’t go too far wrong.

Selling Agile to Business Leaders

When it comes to business leaders, I use a different sales pitch. Beyond technology and product, leaders remain pretty confused (and deeply sceptical) about agile.

Your first hurdle to overcome is the belief that agile is exclusively a “tech thing” and doesn’t apply elsewhere. Start prattling on about the agile manifesto at this point and you will alienate your audience pretty fast — and remember that as an agile advocate you’re assumed to be a tech person, so they already think you’re a bit nuts…

When engaging with leaders I use a more holistic definition of agile. This is partly to tailor the benefits to them, but also because the definition needs to make agile relevant to the whole organisation — and to the culture that underpins it.

So my definition for this audience is:

Better: Increase your ROI by creating products and services your customers want

Faster: Reduce lead times to learn faster and realise value sooner

Happier: Increase engagement to attract and retain top talent*

The biggest sell for business leaders is improving ROI — which they’re typically under colossal pressure to do. Highlighting the commercial benefits of agile is the key point to land. Moving faster comes a close second — poor execution is a deep source of frustration. And whilst being happier is not necessarily seen as the primary benefit (sadly), leaders do recognise the logic that better talent tends to produce better results, so keeping good people happy is logical.

*Note: My thanks to Jon Smart on this. His early definitions of agile inspired this and I’ve run with it ever since

Conclusion

The agile manifesto is great, but recognise it for what it is and what it isn’t. If you want to engage people with agile adoption, be clear on the goal and the benefits. Whether you borrow my definitions or use your own, you will likely find that your way of working ultimately does conform to the values of the manifesto, you’ll just get there a hell of a lot quicker.

Has this article piqued your interest? Could I help your business or teams? I am a coach and consultant that helps organisations adopt agility. Find out more about what I do at betterfasterhappier.com.

Introduction

No, the title isn’t just clickbait, it’s a serious question. Early in my agile career I attended a meet-up where the speaker observed that “No-one is allowed to criticise agile, so it never gets any better”. Ironic eh?

So in the spirit of continuous improvement, I’m going to plough on and accept that I might be in for some outraged comments. And in truth I don’t think there’s a simple answer — hence the blog post!

When it works

Early in my career I certainly believed in self-organisation because I watched it happen. However, I failed to recognise why it worked and that those prerequisites don’t exist by default.

There were two conditions that enabled self-organisation:

1. Ownership — by luck rather than design we had a large number of people with a strong sense of ownership. They were proactive, they used their initiative and they took responsibility for making things happen. In addition, many of those people were strongly influential within their teams. They were respected and their peers were inclined to follow their lead.
2. Tech Team Leads — we had designated leads within the teams. The key word here is within — these people worked hands on alongside their teammates, they were not simply overseeing and managing. Creating these leadership roles meant there were clear expectations and accountability within the teams.

Since that early experience I have seen self-organisation fail more often than not which is why I’ve started to question it.

When it doesn’t work

Rather than self-organisation, what I see more often is that everyone is responsible so no-one’s responsible.

If you haven’t deliberately hired people with a strong sense of ownership, you won’t automatically have people that take responsibility for self-organising. What’s more, when you do have those people they don’t always have the necessary influence within their team. In other cases they lack confidence — in flat structures, people can feel taking the lead is overstepping the mark.

Making it work

So is self-organisation a myth? Not entirely — my early experiences proved that it is possible. The myth is that self-organisation will “just happen”.

Self-organisation can work, but we need to create the conditions to make it work rather than expect it to magically evolve. So how do we do that?

Google’s Project Aristotle set out to define what makes teams effective. Amongst the five characteristics they identified were:

• Dependability: On dependable teams, members reliably complete quality work on time (vs the opposite — shirking responsibilities)
• Structure and clarity: An individual’s understanding of job expectations, the process for fulfilling these expectations, and the consequences of one’s performance are important for team effectiveness.

To me these get to the heart of making self-organisation work. Dependability requires people to take ownership, not to “shirk responsibility”. Structure and clarity involves defining clear expectations.

Optimising for self-organisation means seeking out people with a strong sense of ownership. You can also increase ownership by holding people accountable — but that depends on setting expectations first.

In my experience, defining roles and responsibilities is a good way to set expectations. This avoids the trap whereby everyone is responsible so no-one is responsible. There is no one-size fits all here and your approach will depend on your organisation and culture, but one way or another, clear expectations and accountabilities have to be defined.

Some approaches that I’ve found helpful include:

Create Tech Team Leads

In less mature organisations I’ve seen this make a big difference fast. The key to this role is leading, not managing. It can include line management, but it doesn’t have to — I’ve seen it work well both ways.

As with any leadership role, you need to choose someone with good leadership qualities — this is about leadership not dictatorship. One organisation I worked with found that using the Team Lead title gave people a “God complex”. I’d suggest this was caused by poor choice of leaders rather than by the title itself.

Choosing good leaders may mean hiring for the role rather than promoting internally. If you consistently find that you lack strong candidates internally, it’s worth revisiting your recruitment and assessment process — consistently hiring people that lack leadership qualities is a problem in itself.

Creating the role is not enough. To set your leads up to be effective, provide a clear description of the role. What activities do you expect them to undertake or lead? What are they accountable for? Provide the “structure and clarity” that will set your leads up for success.

Define roles and responsibilities

An alternative to team leads is to take a similar approach but apply it to senior team members instead. As with team leads, set clear expectations by defining the responsibilities of the role.

One note of caution — where multiple team members share the same set of responsibilities this can lead once again to everyone being responsible and things falling between the cracks. To avoid this, senior team members will need to align and coordinate; if you don’t see that happen you may need to instigate it.

Use “rotating scrum masters”

Delivery is often an area of weakness in cross-functional teams because it is unclear who takes ownership for the team’s process. The answer is that, in a self-organising team, everyone takes ownership. In reality it is more common that no-one does.

Some organisations address this by using dedicated scrum masters or delivery managers. This may or may not lead to self-organisation — a team is not really self-organising if it relies on this dedicated support long term.

An alternative approach is to define a scrum master/delivery manager role which rotates around the team. The key here is that, as with any other role, it is clearly defined — activities and responsibilities are clear. When the role is undefined it becomes merely ceremonial.

Responsibilities vs accountabilities

In cross-functional teams, it can be helpful to define accountabilities versus responsibilities. For example, a Product Manager might be accountable for ensuring the team is creating maximum value, but she is responsible for the health and quality of the technical platform. Conversely a Principal Engineer or Tech Team Lead might be accountable for the health and quality of the technical platform, but responsible for ensuring the team is creating maximum value.

I find it helpful to define accountabilities and responsibilities as “leading” and “supporting”.

For example, the Principal Engineer would be accountable for identifying the need to upgrade a software framework, but the Product Manager is responsible for enabling that by making space for it on the backlog. That doesn’t mean the Principal gets what she wants by default — there should be a healthy push and pull to ensure the work offers some value and to define when it actually needs to happen. The key here is that a Product Manager shouldn’t be expected to identify the needs of the technical platform, but nor should they be able to evade responsibility for a healthy platform.

Define accountabilities and responsibilities across the workflow

Another approach I’ve used is to define the team’s end to end workflow, and work with the team to define who leads and supports activities at each step.

For example a Product Manager might lead a kick-off while the rest of the team supports this activity by attending and contributing.

Likewise a Tech Team Lead might lead a technical design session, while the rest of the team are responsible for supporting this activity by attending or being available to answer questions and provide clarification.

Hold people accountable

All the approaches outlined involve setting expectations in some form or other. But there is no point setting expectations if you don’t hold people accountable to them. An expectation for which someone is not accountable is optional…and an optional expectation is not an expectation!

Holding people accountable can be uncomfortable, but it cannot be shirked. Self-organisation devolves power to a team and with that power must come responsibility. A failure to hold people accountable is as damaging as failing to set expectations in the first place.

Conclusion

Self-organisation can work, but it doesn’t just happen. You need to create the conditions that enable self-organisation.

But why does self-organisation matter? Should we even care? It matters because autonomous working environments depend upon it. Empowering people to work autonomously leads to better products and services delivered faster. It also improves engagement. Working autonomously depends on self-organisation.

If we recognise the importance of self-organisation we can start creating the conditions to make it work rather than hoping it will evolve organically.

Are you looking to improve self-organisation in your business? I am a Business Agility Coach & Consultant helping organisations to grow, scale and deliver value fast.

Find out more at betterfasterhappier.com.

Introduction

Speed and the challenges of scaling

The inevitable challenge that all successful start-ups face is the need to scale effectively. There are many elements to this, one of which is how to stay agile at scale. In a small company of 10, 20, 30 people, agility comes naturally. It gets much harder to maintain this speed as your company grows.

But, why does speed matter?

1. Speed enables you to realise value sooner
2. Speed reduces the time it takes to learn how to meet your customers’ needs; this reduces investment in products and services your customers don’t want. This means you can maximise the time and effort spent on delivering the products and services your customers do want, thereby increasing your ROI.

So how do you maintain speed as your business grows? There are 3 key elements to remaining agile at scale:

• Alignment
• Focus
• Autonomy

In this short series of articles I’ll cover each of these areas separately. This instalment looks at how autonomy increases speed. You can find part 1 on Alignment here, and part 2 on Focus here.

How does autonomy affect speed?

Quite simply, autonomy reduces bottlenecks. When every decision has to be escalated to leadership, leaders become bottlenecks. These bottlenecks create delays which slow you down.

What is “autonomy”?

Check the dictionary definition of autonomy and you’ll see it described as self-directing freedom or self-government. Within a business, autonomy is more nuanced. Jason Yip of Spotify, defines autonomy as “feeling free to act, with all your capabilities, to contribute toward a collective outcome”.

In a business, autonomy is the freedom to act within a set of constraints. Spotify is a music streaming app so Spotify’s employees are probably not free to create an e-commerce platform selling craft beer!

Constraints come in various forms. Business goals and outcomes operate as constraints, brand guidelines and coding standards are another example. Constraints act as guard rails, defining the space within which teams and individuals have the “freedom to act”.

A nice analogy for this is a football pitch — the pitch defines the space in which the players are free to play.

Leading autonomously

Autonomy starts with leadership devolving authority to teams and individuals. Dan North describes this perfectly as “Bringing the authority to the information, not the information to the authority”.

However, achieving autonomy is not straightforward. To successfully lead autonomously requires three things:

1. Clarity
2. Capability
3. Accountability

1. Clarity

Clarity involves providing the full set of information that will enable people to work with minimal supervision. This means defining:

• Outcomes and constraints
• Context

Outcomes and Constraints

Make it clear what needs to be achieved by defining outcomes — the goals to be achieved and the measures of success to validate them. Ensure the destination is clear, but let teams figure out the journey to get there.

The constraints are any limitations or restrictions in achieving the outcome. For example, an outcome might be to increase average order value, the constraint might be to do so without reducing customer satisfaction.

Context

In order to ensure teams make the best decisions, they need full context. This is perhaps the most challenging aspect of leading autonomously, because as Kim Scott puts it “When you know something deeply, it’s hard to remember that others don’t”.

In his book, No Rules Rules, Netflix co-founder Reed Hastings describes how one of his managers made what he considered a poor decision. When Hastings sought to understand the thinking behind the decision, he discovered that the manager had actually made a perfectly reasonable decision based on the information he had. The poor decision had been made because Hastings and his leadership team had not shared the context that would have enabled the manager to make a good decision.

Leaders typically carry huge amounts of information and context; when you are possessed of the context yourself, it’s hard to remember what you know that everyone else doesn’t know! But as the Netflix example illustrates, lack of vital information will lead to poor decisions, so it’s crucial to build the habit of constantly communicating context.

2. Capability

Empowering people to work autonomously requires them to have the right level of skills and experience. Ask a bright and hardworking graduate to be CEO of a company and, despite their best efforts, they will likely struggle.

The level of autonomy needs to be proportionate to the level of capability. Consider the following:

Ideally you want to be on the trajectory illustrated by the red arrow. It doesn’t matter where your journey begins so long as you continue to move towards the top right hand corner. The areas you want to avoid are the top left and bottom right corner.

In the top left corner you have frustration — you have high levels of capability but low levels of autonomy. At this point you are failing to make full use of your team’s abilities (and this will eventually lead to your best people leaving).

In the bottom right hand corner you have chaos. You have empowered people that don’t yet have the capability to be able to act independently. In this case you need to decrease the level of autonomy while the level of capability is improved.

3. Accountability

Providing autonomy empowers people. With this power must come responsibility. When people are given greater power it must be accompanied by greater accountability. If you’re not going to tell people exactly what to do, you need to be confident they will figure it out themselves.

The agile world talks frequently about autonomy, but much less frequently about autonomy, but these must come as a pair — autonomy fails without accountability. The well-known Netflix Culture document talks of “freedom and responsibility”, but it treats them as a pair: with freedom, comes responsibility. With autonomy comes accountability.

As with capability, the level of autonomy needs to be proportionate to the level of accountability.

We can map autonomy to accountability in the same way as we did with capability — you want to be on the trajectory illustrated by the red arrow, avoiding the top right and bottom left corners.

In the top left corner you have frustration — you have high levels of responsibility but not enough freedom. At this point you are constraining your teams and you need to empower them.

In the bottom right hand corner you have chaos. You have empowered people but they are not taking responsibility. In this case you either need to increase the level of responsibility or reduce the autonomy.

Improving Capability and Accountability

While low capability and accountability are barriers to autonomy, they are not fixed. They can — and should — be improved in order to enable greater autonomy. In some cases this might be achieved through formal training, but very often through coaching.

There are plenty of great coaching models, the one that I find particularly useful is David Marquet’s “Ladder of Leadership”.

In his book Turn the Ship Around, Marquet describes his experiences of creating greater autonomy on a nuclear submarine. He describes this as changing from a “leader follower” culture to a “leader leader” culture.

His ladder of leadership nicely illustrates how accountability and capability can be improved through coaching. As individuals grow and develop, they can become more and more empowered.

Conclusion

Alignment and focus are reasonably easy to introduce, autonomy much less so because it relies on skills and behaviours that you may not yet have. Autonomy is critical to enabling speed, so it’s a crucial investment, but be prepared for the long game.

Also worth noting that enabling autonomy creates a more challenging and engaging environment which in turn will help you attract and retain high calibre talent. After all, smart people like to figure things out for themselves, rather than being told what to do…

Are you looking to scale your business? I am a Business Agility Coach & Consultant helping organisations to grow, scale and deliver value fast.

Find out more at betterfasterhappier.com.

Introduction

Speed and the challenges of scaling

The inevitable challenge that all successful start-ups face is the need to scale effectively. There are many elements to this, one of which is how to stay agile at scale. In a small company of 10, 20, 30 people, agility comes naturally. It gets much harder to maintain this speed as your company grows.

But, why does speed matter?

1. Speed enables you to realise value sooner
2. Speed reduces the time it takes to learn how to meet your customers’ needs; this reduces investment in products and services your customers don’t want. This means you can maximise the time and effort spent on delivering the products and services your customers do want, thereby increasing your ROI.

So how do you maintain speed as your business grows? There are 3 key elements to remaining agile at scale:

• Alignment
• Focus
• Autonomy

In this short series of articles I’ll cover each of these areas separately. This instalment will explore how focus increases speed. You can find part 1 on Alignment here, and part 3 on Autonomy here.

The power of focus

Focus is the superpower that all businesses possess but few deploy. It is a superpower because it enables you to move faster. Put simply, focus means doing fewer things simultaneously. The more initiatives you run in parallel, the longer each takes.

Consider this simple scenario. You have two objectives, A and B, and a team of six people to achieve them. You could decide to split the team across both objectives and pursue them simultaneously.

Alternatively you could tackle them sequentially with the entire team focusing on completing objective A before moving to objective B.

In the first option both objectives take long to achieve as each has fewer people to work on it.

In the second option, the first objective is achieved sooner. This increases the speed of delivery and realises value sooner. What’s more, this release of value continues to accumulate as you tackle objective B.

The impact of delays

The scenario above demonstrates the benefit of focus in its simplest terms. The less visible impact of focus is in reducing delays. Delays occur when too many initiatives are in flight and effort and attention is divided between them.

In Lean Enterprise, O’Reilly, Molesky and Humble refer to an example from Maersk. In this case a feature that took just 82 hours to complete took a total of 46 weeks to deliver end to end.

As you can see, the man hours involved were relatively low, but the delays dramatically increased the delivery time.

So why did the delays occur? One possibility is that people simply sat idle for weeks at a time. The more likely explanation is that the delays occurred because multiple features were in play, and time and effort continually switched between them. Delays were introduced as attention shifted from one feature to another.

Limiting work in progress (WIP)

Delays increase the time it takes to deliver. Limiting work in progress (WIP) aims to reduce these delays by ensuring effort can be focused on completing one initiative before undertaking another. The aim is to stop starting and start finishing. WIP limits help to keep delivery time as close as possible to the actual man hours involved, reducing delays to a minimum.

The concept of limiting work in progress comes from the Toyota Production System (TPS) which in turn has heavily influenced both the principles of lean manufacturing and lean software development. Toyota sought to optimise for flow efficiency (speed) over resource efficiency (being busy). They recognised that optimising for resource efficiency created bottlenecks which resulted in delays and these delays reduced speed.

Optimising for speed by limiting WIP was one measure of the TPS that enabled Toyota to produce better quality cars faster and cheaper than rival General Motors. GM’s cars took 50% more time to develop, required 3 times as many engineering hours, were substantially lower quality and more expensive to produce.

Limiting WIP is a counterintuitive concept, but as Toyota proved, it has a dramatic effect on speed.

Conclusion

Focus increases the speed at which you deliver products and services by concentrating efforts on a minimal number of priorities and reducing delays.

Achieving focus requires the discipline to ruthlessly prioritise. There will always be more things to do than there are people to do them. Developing a robust process to prioritise will always be valuable and ensure effort is focused where it is most valuable.

Understanding your capacity will also help you to avoid initiative overload. This is where aligning teams around missions can help — the act of defining missions forces the need to identify priorities. Defining the teams that will achieve these missions will surface bottlenecks by exposing areas where capacity is low.

Are you looking to scale your business? I am a Business Agility Coach & Consultant helping organisations to grow, scale and deliver value fast.

Find out more at betterfasterhappier.com

Introduction

Speed and the challenges of scaling

The inevitable challenge that all successful start-ups face is the need to scale effectively. There are many elements to this, one of which is how to stay agile at scale. In a small company of 10, 20, 30 people, agility comes naturally. It gets much harder to maintain this speed as your company grows.

But, why does speed matter?

1. Speed enables you to realise value sooner
2. Speed reduces the time it takes to learn how to meet your customers’ needs; this reduces investment in products and services your customers don’t want. This means you can maximise the time and effort spent on delivering the products and services your customers do want, thereby increasing your ROI.

So how do you maintain speed as your business grows? There are 3 key elements to remaining agile at scale:

• Alignment
• Focus
• Autonomy

In this short series of articles I’ll cover each of these areas separately. This instalment examines how alignment increases speed. Part 2 on Focus is here, and Part 3 on Autonomy is here.

Stay nimble at scale

The key to remaining agile at scale is to stay small as you get bigger. Amazon famously described their initial approach to this as “two-pizza teams” — if it takes more than two pizzas to feed a team, the team is too big!

In practice, this means structuring your organisation into smaller units that can operate independently. At this point you might be thinking that businesses already do that because they’re organised into functions. But the key here is independence. Functions are indeed smaller business units, but most customer and business problems cannot be independently solved by a single function — they require a cross-functional effort.

Functional vs cross-functional teams

Historically businesses have organised by function. Essentially this means organising people into teams based on a common skill or discipline, so teams are organised by what they do.

The key difference with cross-functional structures is that they organise people into teams based on what they need to achieve. In other words, teams are defined based on a common purpose.

It is this common purpose which allows cross-functional teams to operate independently, and this independence is what liberates teams to move at speed. Reducing dependencies between teams reduces the need to align and coordinate, thereby dramatically reducing the process overhead which tends to slow down larger businesses.

Functional structures have been the default method of organising businesses for so long, that cross-functional structures can seem counterintuitive. In fact they are a far more logical way to organise. Consider this scenario…

You are the owner of three football teams. One team consists entirely of goalkeepers and defenders. The second consists entirely of midfielders and the third consists entirely of forwards and strikers. Organising your teams in this way is akin to organising by function — you have organised your teams based on their skills. The problem is, it takes a mix of skills to win football games, so your teams are unlikely to be successful.

If you re-organise your teams so that each has a mixture of defenders, midfielders and forwards, you have now created three cross-functional teams.

Each team now has the mix of skills to enable them to win games. Each team shares the common purpose of winning games, each individual brings different skills to help achieve this. The purpose of a goalkeeper is to win games; the skill he brings is saving goals. Likewise the purpose of the striker is to win games; he uses his goal scoring skills to achieve this.

As with football games, strategic goals require a mixture of skills. The rationale behind cross-functional teams is to optimise your organisation design to support the achievement of your strategic goals. You organise people based on what you want them to achieve rather than by their particular skill.

Defining mission-based teams

To define teams based on purpose, you need to be clear what you are trying to achieve. At this point it is helpful to have a coherent strategy. Based on your strategy you can identify outcomes, customer problems and key KPIs. These can all be used to help define your missions. Once the missions are defined you can identify the skills you need to accomplish each mission.

Conclusion

Small, independent teams enable agility at scale because they reduce dependencies and thus keep process overhead low. The process of defining cross-functional teams forces you to define your purpose which creates greater clarity and focus. Increased focus also accelerates speed by ensuring effort is concentrated where it can deliver most value.

Are you looking to scale your business? I am a Business Agility Coach & Consultant helping organisations to grow, scale and deliver value fast.

Find out more at betterfasterhappier.com.