The Agile Leader

… is probably one of the worst titles that you can give to a post if you want readers to read on. But as readers of this blog probably figured out by now, I am far from a marketing genius, so hopefully you’re still reading on.

Henrik Kniberg of Spotify fame, has put together one of the better posts about leadership that I’ve read in a while, sadly choosing a similar title to the one I chose for mine.

What is an Agile Leader?

He came up with a very simple definition to the job of a leader. A leader’s job is to ensure that everyone in the organization is capable of answering these 4 questions:

1. What does winning look like? Vision/Mission.

2. What’s the plan? Strategy and tactics.

3. What’s the score? Progress, status, feedback loops

4. What is preventing us from winning? Continuous improvement, people, teams, strategy, tactics.

He later breaks it down to a more detailed list of responsibilities:

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.

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.

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.

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.

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.

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).

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.

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.

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.

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.

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.

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.

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.

Dependencies. 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.

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.

Fast failure. Create a context where small failures can happen early and often, thereby reducing the risk of a big failure at the end.

Note that the fuzzy term “ensure” is being used a lot. This is done by design, as the leader cannot enforce these things to happen, she can only “do whatever she can to create a context where this happens” which is what “ensure” means in that context.

This nuance hints a more profound and perhaps controversial statement made later on in the post about accountability: “people should be accountable for their behaviors, not results“. As  Henrik explains:

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

It is a profound, and thought-provoking statement, because traditional performance management systems are wholly oriented around results ,rather than behaviors. How one might go about designing a performance management system that’s oriented around behaviors, without compromising on rigor, is something that I’m still mulling over.

The Agile Leader

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s