(translations: Russian, Turkish)

Agile product development has become the norm in many industries (especially software). That means products are developed by small, self-organizing, cross-functional teams, and delivered in small increments and continuously improved based on real customer feedback. Pretty much as described in the Agile Manifesto – but replace the word “software” with “product” (because it really isn’t software-specific).

That’s all fine and dandy. However when things get bigger, with dozens of teams collaborating over organizational boundaries, things obviously get more complex and painful. Even if the entire organization is neatly organized into scrum teams, you can still end up with an unaligned mess! Here’s a picture that might feel familiar:

Before trying to “manage” this complexity, ask yourself “does it really need to be this big and complicated?”. Perhaps you are trying to build the whole elephant in one go. Perhaps your teams are organized by function, creating lots of dependencies. Perhaps your architecture is too rigid, too fragile, or too coupled.

So start by trying to simplify things. Some wise person said “Don’t scale agile – descale your org”. Maybe you can re-org into one or two teams with just the right mix of skills, all co-located and 100% focused and with direct customer contact. They may well be able to build the same product (or better) in half the time and for half the cost! Don’t fall into the mental trap of believing that more people = better. More people might be better in some cases, but the only thing you can be certain about is that more people = more cost and more complexity. The potential benefits are, well, only potential benefits.

But OK. Sometimes you really do need to get a whole bunch of teams and departments and vendors to collaborate on something big and complex. Let’s just say that’s the case. I’ll be nice and give you the benefit of the doubt.

If so, you most likely need a leader! Someone to focus entirely on coordinating the different teams, keeping the moving parts in sync, and keeping an eye on the big picture. And that’s what this article is about.

Agile relies on self-organization, which is super-effective (when done right). But with more than a handful of teams, self-organization sometimes needs a helping hand – someone to create and maintain the environment that enables self-organization in the first place – things like a clear goal, a short feedback loop, effective communication channels, etc. Essentially, make “1 + 1 = 3” (because of synergies) instead of “1 + 1 = 1.5” (because of misalignment).

Let’s call it the Agile Leader. And the main job is to create alignment!

At the team level agile methods already include leadership roles such as Product Owner and Scrum Master. But at a multiteam-level there is no formal leader role defined. That’s because smaller efforts usually don’t need a single appointed leader – the success of Scrum has shown us that effective leadership can happen without a single appointed leader. However, the more people involved, the more likely you are to need a dedicated leader, a full-time person who focuses on just that – regardless of whether you call your multi-team effort a “project”, a “program”, a “bet”, a “product” or whatever.

The leader doesn’t necessarily need to be one person, it can be a pair, or a small tight-knit team – as long as they collaborate tightly and speak with one voice. For the purpose of this article i’ll assume it is one person.

Example: At Spotify, most medium-to-large initiatives are led by a “TPD trio” – a small leadership team consisting of one person from Tech, one from Product, and one from Design. That way we make sure all three perspectives are always taken into account. However, for large efforts that span far beyond just tech and product and design, the trio isn’t enough. Should the trio be expanded, or should we have an additional leader role? And what should we call such a role? We’re still experimenting with that.

Think of the label “Agile Leader” as a placeholder for whatever you decide to call the role. If depends a bit on how you organize your work. Pick whatever title fits your context – Chief Engineer, Chief Product Owner, Project Manager (if it is a project), Program Manager, Uber Scrum Master, Release Train Engineer, Chaos Pilot, Road Manager, Zen Master, Coordinator, Driver, Project Coach, Catalyst, or whatever. Whatever you call it, it is critical function and it needs to be there for any complex cross-functional endeavor that involves more than a handful of teams. The person(s) in that role need to be motivated, dedicated, and skilled.

I intentionally call it Agile Leader in this article. The word “Agile” is there to emphasize that this article is about an agile product development context, which is very different from a waterfall context. I use the term “Leader” instead of Manager because, well, in a well-running agile organization most “management” is handled by the teams themselves. So the primary purpose of the role is to provide leadership, not management. But the distinction isn’t binary, of course.

The purpose of this article is to paint a picture of what a great Agile Leader does, so you can more easily find, grow, or become this person – and help your multi-team efforts succeed better! This is not a formal definition of the role, just my take on it.

So, in short: try to minimize the need for big, complex, multiteam efforts. If you can’t then at least make sure you have an awesome Agile Leader!

Isn’t this a Project Manager?

Maybe, but not necessarily. A “project” is just one of many ways to organize work, and often inappopriate for product development. However, If you do work in Project form, and the projects are fairly big and complex and involve synchronization among many different teams and organizations, then the Agile Leader is effectively an Agile Project Leader. I wrote a separate article called What is an Agile Project Leader, with some discussion about the project model in general. But for the actual role description that article links back to here. Don’t get stuck in a loop 🙂

Again, the choice of what to call the role is highly contextual. The purpose of this article is just clarify what type of leader you will need to execute it in an agile way.

What does an Agile Leader do?

My Spotify colleague Babar provided a nice summary, using a sports analogy:

What does winning look like? Vision/Mission. What’s the plan? Strategy and tactics. What’s the score? Progress, status, feedback loops What is preventing us from winning? Continous improvement, people, teams, strategy, tactics.

Do we all know why we are here, what winning looks like? Do we know the plan, the strategy? Do we have a way of seeing where we are now? Do we see the impediments, things that are slowing us down? Are we continuously trying to remove the impediments?

The answer is most likely “no” to some of these questions (otherwise, congrats, keep up the good work). So that’s the job of the Agile Leader – do whatever it takes to turn these into “yes”. That won’t guarantee success, but it will certainly increase the odds.

In a smaller efforts using Scrum, this work is covered by existing roles and bottom-up cross-team collaboration. With large efforts we face misalignment across teams, and things falling into cracks between different parts of the organization. So the Agile Leader focuses a lot on communication and creating clarity. If everyone involved has the same view of where we are, where we are going, and why, then we are more likely to work together to move in that direction.

Uh, be more specific. What does the Agile Leader actually do?

So what does this mean in practice? What does an Agile Leader actually do?

I hate to say it, but…. it depends! There. I said it.

It depends on context, and what’s working well today and what’s not.

Keep asking yourself: “What needs to happen that’s not already happening? What can I do to cause this to happen, without becoming a bottleneck myself?”

Example: You notice that releasing is a pain, and that we need better release coordination between teams. Instead of running around trying to coordinate this yourself, you bring up the problem with some of the teams – check if they agree that it is a problem, and discuss how we might deal with it. Together you decide to set up a recurring meeting where people that have stuff to release sync with each other, and provide a shared living document where they can see and edit upcoming releases. Initially you facilitate the meetings yourself, but after a while they become self-managing. You encourage the teams to automate as much of release management as possible. Over time the recurring meeting isn’t needed, because the teams talk to each other directly and release coordination is no longer an issue.

Although I can’t tell you exactly what an Agile Leader should do, I will give a list of examples. Think of it as different “lenses” you may wear as leader. You might be doing some of these things yourself, but for the most part you should be creating a context where these things get done without your involvement.

NOTE: I use the term “ensure” below. Obviously a leader can’t force these things to happen, so in this context “ensure” = “do whatever you can to create a context where this happens”. In practice this may involve facilitating, encouraging, arguing, challenging, organizing meetings, creating documents, visualizing stuff, informal hallway conversations, etc.

So, here’s the list. Take a deep breath:

Vision/mission. Ensure the the work being done has a clear purpose, clear hypotheses, clear boundaries/scope (“what are we NOT doing”), and clear success metrics based on business impact rather than deliveries. Ensure this is crystal clear to everyone involved, teams as well as customers and other stakeholders.

Ensure the the work being done has a clear purpose, clear hypotheses, clear boundaries/scope (“what are we NOT doing”), and clear success metrics based on business impact rather than deliveries. Ensure this is crystal clear to everyone involved, teams as well as customers and other stakeholders. Iterative and incremental delivery. Ensure that the work is split into sub-deliveries, to enable iterative and incremental delivery rather than big bang. Avoid large projects whenever possible, instead try to split the work into a series of smaller projects whenever feasible.

Ensure that the work is split into sub-deliveries, to enable iterative and incremental delivery rather than big bang. Avoid large projects whenever possible, instead try to split the work into a series of smaller projects whenever feasible. Adaptive planning. Ensure that plans are created and communicated to everyone involved. Ensure the plans are adaptive rather than predictive, and updated as we learn. Ensure that deadlines are communicated and forecasts created as necessary, and updated based on empirical data as the work progresses. Make sure any constraints (date or scope) are clear to everyone.

Ensure that plans are created and communicated to everyone involved. Ensure the plans are adaptive rather than predictive, and updated as we learn. Ensure that deadlines are communicated and forecasts created as necessary, and updated based on empirical data as the work progresses. Make sure any constraints (date or scope) are clear to everyone. Feedback. Ensure a short feedback loop with tight and frequent communication between teams and customers. Collaborative planning, demos, etc. Ensure that hypotheses and assumptions are field-tested early and that learning happens continuously. Ensure that progress is measured based on actual deliveries and feedback and business impact, not by compliance to plan.

Ensure a short feedback loop with tight and frequent communication between teams and customers. Collaborative planning, demos, etc. Ensure that hypotheses and assumptions are field-tested early and that learning happens continuously. Ensure that progress is measured based on actual deliveries and feedback and business impact, not by compliance to plan. Continuous improvement and knowledge sharing. Ensuring that learning and improvement happens continuously as the work progresses (not just at the end), and that key learnings are shared within the teams as well as across different parts of the organization.

Ensuring that learning and improvement happens continuously as the work progresses (not just at the end), and that key learnings are shared within the teams as well as across different parts of the organization. Focus and alignment. Ensure that participants are focused and dedicated (not multitasking), and aligned with the same list of priorities. Bash silos. Ensure that people are focusing on achieving the highest possible business impact with the lowest possible effort and output (working smart is more important than working hard).

Ensure that participants are focused and dedicated (not multitasking), and aligned with the same list of priorities. Bash silos. Ensure that people are focusing on achieving the highest possible business impact with the lowest possible effort and output (working smart is more important than working hard). Impediment removal. Ensure that waste and impediments are visualized, prioritized, and systematically removed. Encourage teams to own and solve their own impediments whenever possible. Collaborate with other managers and take ownership of impediments that are escalated.

Ensure that waste and impediments are visualized, prioritized, and systematically removed. Encourage teams to own and solve their own impediments whenever possible. Collaborate with other managers and take ownership of impediments that are escalated. Decision enablement. Ensure that decisions are made in a just-in-time manner and by the people who have the best insight into the matter, decentralized whenever possible. Ensure that nobody (including you) becomes a decision bottleneck. Minimize the number of decisions that have to be made by you.

Ensure that decisions are made in a just-in-time manner and by the people who have the best insight into the matter, decentralized whenever possible. Ensure that nobody (including you) becomes a decision bottleneck. Minimize the number of decisions that have to be made by you. Visualize status and progress. Ensure that everyone can see the “big picture” – dashboards and such showing where we are going and why, where we are now, impediments, etc. Keep it at a high level, leave the details to the teams.

Ensure that everyone can see the “big picture” – dashboards and such showing where we are going and why, where we are now, impediments, etc. Keep it at a high level, leave the details to the teams. Flow . Optimize for end-to-end flow of value, not resource utilization. Look for bottlenecks and queues, and apply systems thinking and lean principles to streamline the delivery of business value.

. Optimize for end-to-end flow of value, not resource utilization. Look for bottlenecks and queues, and apply systems thinking and lean principles to streamline the delivery of business value. Self-organization and autonomy. Make the goal and current situation clear so that people can think and act autonomously, with no need for you to tell them what to do. Ensure people are given problems to solve rather than tasks to execute. Harness the collective intelligence of the group, rather than trying to be a mastermind yourself.

Make the goal and current situation clear so that people can think and act autonomously, with no need for you to tell them what to do. Ensure people are given problems to solve rather than tasks to execute. Harness the collective intelligence of the group, rather than trying to be a mastermind yourself. Staffing and capacity planning . Work with managers to ensure that the right people and teams are available at the right time to maximize the velocity and chance of success.

. Work with managers to ensure that the right people and teams are available at the right time to maximize the velocity and chance of success. Budgets and estimates. Ensure that any budget and contractual constraints are known and managed. Ensure that estimates are done by the team closest to the work at hand, kept at a high level, and adjusted when necessary. Ensure that estimates are treated as estimates, not promises. Make costs transparent.

Ensure that any budget and contractual constraints are known and managed. Ensure that estimates are done by the team closest to the work at hand, kept at a high level, and adjusted when necessary. Ensure that estimates are treated as estimates, not promises. Make costs transparent. Dependencies. Ensure that cross-team and cross-company dependencies are visualized and managed effectively, and that teams aren’t blocked waiting for each other.

Ensure that cross-team and cross-company dependencies are visualized and managed effectively, and that teams aren’t blocked waiting for each other. Cross-functional collaboration. Use techniques such as co-location and cross-functional communication channels to reduce siloing and suboptimization.

Use techniques such as co-location and cross-functional communication channels to reduce siloing and suboptimization. Communication. Create an environment that facilitates high bandwidth face-to-face communication and minimizes the need for unnecessary documents, emails, and other low-bandwidth communication. Documents should be used to support communication, not replace it.

Create an environment that facilitates high bandwidth face-to-face communication and minimizes the need for unnecessary documents, emails, and other low-bandwidth communication. Documents should be used to support communication, not replace it. Fast failure. Create a context where small failures can happen early and often, thereby reducing the risk of a big failure at the end.

Special point: Motivation. Motivation is the key currency for any creative, complex endeavor – much more important than man-hours. Motivated people build better stuff faster. The difference can be quite mind boggling! But motivation is not a separate point – you can’t just “motivate people”. Instead, people will be intrinsically motivated by things like Autonomy, Mastery, and Purpose.

A good guiding principle is “Don’t motivate people – remove the demotivators”. If people see you removing real impediments and creating a high-trust environment that helps them work effectively – that will probably motivate them a lot more than things like hawaiian t-shirt fridays, free drinks, and ping-pong tables.

Uh, that’s a loooong list! Where do I start?

Distill it into a shorter list for your context!

For example, get together with some folks, rate each item based on “how important is this for us” and “how well is this working today”. Then shorten the list to the top 5 things that are important and not working well today. Use that as a basis for finding a suitable Agile Leader (or for prioritizing your work, if you are the leader).

What about accountability?

So is the Agile Leader a single point of accountability? Is this the single wringable neck in case of failure (for some definition of “failure”…)?

No, certainly not! Everyone involved is accountable. But people should be accountable for their behaviours, not results.

That may sound crazy at first glance, but think about it for a moment…

A product may fail to succeed despite all the best efforts of the team – it may fail for random reasons, it may fail because of acts outside of the team’s control. And vice versa, a product may succeed despite crappy efforts from the team and leaders, it may succeed because of blind luck or because there was no competition. This is complicated by the fact that failure and success is usually hard to define, with a big fat gray zone in between.

An Agile Leader should ensure that, when things fail, they fail early! She does that by building in a fast feedback loop (frequent delivery to customers, validated learning, etc). She ensures that we learn from the failure and use those learnings in the next product, or next iteration of this product.

If we punish failure, we incentivize people to hide failure, and thereby minimize learning. If we punish failure, we incentivize people to avoid all risk, and thereby kill innovation. Failure (and the associated learning), should be celebrated, not punished! To a limit, of course. Keep the feedback loop short, so failures aren’t fatal…

So although the Agile Leader may act as the “face” of this project/program/product/whatever to external stakeholders, she is not personally held accountable for success or failure. She is however, held accountable for behaving in a way that maximises the odds of success. And this applies to all participants, not just the Agile Leader.

What kind of person is suitable for the role?

At the minimum, the Agile Leader needs to (in my opinion):

Passionate about the product, customers, users, and business impact. Be excited about the Agile Leader role and willing to focus on it 100% Buy into most of the role description above, and want to grow in that direction. Have at least some real-life leadership experience (in any context) Have at least some real-life experience with agile ways of working (in any role) Be willing to get training/coaching/mentoring for the skills that are weak or missing Be willing spend time learning and continuously improving their skills as agile leader.

There is obviously no “perfect” Agile Leader, but below is a “Definition of Awesome”. I don’t expect anyone to fullfill all these points, but the more the better :o)

In a perfect world:

You are business-minded and passionate about getting people aligned towards a common goal.

You have experience managing large, cross-functional efforts (e.g. spanning functions such as engineering, marketing, content, legal, and others). Agile or not. Some of best leaders I’ve seen come from big failed projects – they know how not to run a project.

You are flexible and pragmatic about methods and processes, and are able to use your judgment to apply the model and approach that fit best with the context.

You have deep understanding and experience of agile and lean thinking, and some experience with concrete frameworks and techniques such as Scrum, Kanban, Lean Startup, and Continuous Delivery.

You steer clear of waterfall projects, but you also understand that Agile doesn’t mean No Planning or No Architecture.

You know how to provide strong leadership and guidance, without become a bottleneck.

You know how to get people inspired and rallied around a higher purpose.

You understand that people are people, not just resources, and that focus and motivation matter a lot more than man-hours.

You understand that people are most motivated and effective when given a problem to solve, rather than a solution to implement.

You know how to get people talking with each other across departments and other organizational borders. You aren’t scared off by politics.

You know how to enable self-organization in large cross-functional efforts, and how pull-based scheduling works in practice.

You know how to make the important stuff visible.

You have a knack for spotting waste and calling it out.

You understand that plans are important, but they are a tool and not a goal, and must be updated as you learn.

You understand that uncertainty is a fact of life when innovating, and is best managed through a tight feedback loop rather than detailed upfront planning.

You hold people accountable for their behaviour more than their results. You reward people for learning rather than punishing them for failing.

Final words

I hope this doc helps you improve the success rate of your large multi-team efforts. But don’t forget – scaling is a last resort. Scaling hurts no matter how you do it, so keep things as small as possible (but no smaller…).

Big thanks to Alistair Cockburn, Mary and Tom Poppendieck, Anders Haugeto, and a bunch of Spotifyers and Crispers who helped improve this article. I’m honoured to have such an awesome group of advisors!

Note that this my personal opinion, my take on what an Agile Leader is (or should be). Some people may disagree, that’s fine. I’m also happy for feedback, although I won’t always have bandwidth to respond.

Further reading (there’s infinite material on agile leadership, but here are some things that I happened to have read and liked):