Leading the agile way

What about leadership in the agile world? Do we still need leaders if we run agile? Due to my experience in agile teams my answer is: "Yes, we need leadership but less managers!" The tasks itself are straight forward. But leading agilely means solving them different, new, agile. That means,no power to micro-managers by transparency. Instead, accomplishment and affiliation driven smart enabler and servant leaders without ego. But this is easier said than done.

Lots of stuff is written about working agile. Frameworks, such as Scrum, define the basic team structure, processes and tools about organizing small teams of about 7 people. Other methods, such as SAFe, sketch how to interact between teams and scale agile to enterprise level. And lot’s of best practices (e.g. Spotify engineering culture) describe how to run agile companies by example.

However, I'd like to share my thought on the topic "agile leadership"  I gained from agile projects and teams in the last 8 years.

Personally, I work agile by heart.

Without having called it “agile”, I  gained experiences in 2010, introducing researchers and students to use some artifacts of the Scrum framework, such as standup meetings and sprints, to eventually get something done after burning appr. half of the 1M$. We got that money for a research project, without any specific objectives (not even SMART goals). After a year, I figured, the project was meant to just get some money for the Professors and deliver, well, not necessarily something useful. We were far away from any product at that time. Despite the fact being just a PhD student, I strongly disagreed and reorganized the project to continue lean with a small group of people. In close collaboration with the industry partner, we delivered a small piece of software, eventually.

I continued implementing agile methods in a large waterfall-driven industry project, that cost 5M$ per year, applying Kanban Boards and Pair Specification (the idea of pair programming for writing specification documents in the design phase of the waterfall) to increase product quality and remove management overhead by cooperative responsibility in the team. The poor "writer monkeys" at least enjoyed being responsible for what they designed.

In one of my next projects, I staffed and guided a mid-size agile product team from scratch to develop, sell and operate a software-as-a-service solution in the cloud, two mobile apps and embedded system integration within just 6 month. The rollout went smoothly. To me, that product was incredible fast and well developed.

Leadership is not management.

In classical management, you need leaders as “managers” and “experts" who organize work of the “worker”. (Project-)Managers plan what to do and check if it is done correctly. Firstly, management is not leadership. And there is lots of articles out there explaining that. In this article, I focus on leadership. Secondly, agile leadership does not differ from classical management in terms of aspects. Leadership tasks stay leadership tasks, but the responsibility and the way you solve them in the agile world.

The agile world finds new ways to solve the old, well known leadership tasks.

Agile teams are self-organized, cross-functional and know their purpose (Jeff Sutherland: Scrum: The Art of Doing Twice the Work in Half the Time, 2015). Such teams don't need somebody to tell them what to do. They don’t need classical leaders, because this would interfere with the way agile works. Instead of being the boos, agile leaders are servant leaders (see Theory y).
Agile leaders enable the team. The Manifesto for Agile Software Development  states "We are uncovering better ways of developing software by doing it and helping others do it.". The last part "helping other do it.", is the hook of the leader. 

So far, this is all nice buzzing words. Let's go deeper.

How exactly would you enable people?

As an agile leader, you work indirectly and “on the team” instead of “in the team”. You provide what is necessary to them to do their job. And as a result, you get leadership from them. Think of it as a coach. A sport coach does not make points in the game but is still a leader. (In contrast, ordinary management tasks are done by a role like any other team member. There is no sense in hierarchy in this context.)
It begins with basic requirement for any project or product: budget and investments. You need to assure, that your team gets payed for what they deliver. And if you're not profitable or want to quickly grow, you need investors who bet on your success and give you money to make it happen. That's simple.
An agile team needs four things from the leader

1. self-organization,  
2. cross-functionality,
3. knowing their purpose,
4. a safe environment.

1. Enable self-organization in the team.

To work self-organized, the team needs autonomy. This means, they get the authority to decide about how they work. Autonomy is been granted from management. So, the agile leaders task is to get and maintain autonomy. As a leader you protect the team.
But be careful. Leading does not include infantilizing them. Tread people as adults!

Your team needs information to be self-organized. It needs to be connected to the environment - the company and the customers you're working for. So, the team needs to communicate to the outside and it also needs to get information from the environment, which effect their work. It is not the leaders job to start dealing with important information like with drugs, which might be tempting if you're a person who is motivated by power. Remember, such behavior would not be transparent. Instead, it is leaders task to establish and maintain communication channels.

And finally you facilitate self-organization inside the team by coaching people. Again, it is not about telling them, what to do but enabling them to know how to do it. This means figuring how to run meetings (topic, objective, schedule), setting objectives (e.g. product vision), decision making methods, conflict management and project management (based on Frederic Laloux, Etienne Appert: Reinventing Organizations: An Illustrated Invitation to Join the Conversation on Next-Stage Organizations, 2016). Tread them as your children, who you would want to autonomously live one day, right?

But instead of just commanding what to do and how to do it, agile leaders co-create the tasks above and coach the team to do it. Decision making, for example, is a leadership task. There exist only 4 ways to do it: by order, by vote, by consent, or by consultation. Dead simple to understand but hard to apply. There is no right or wrong in general. There is just a better fit to a specific situation. And the agile leader motivates and guides the team members by example to take responsibility and figure the way they make decision best.

2. Grow a cross-functional team.

The 2nd requirement of an agile team is cross-functionality. A cross-functional team needs members - experts. And these experts must be hired. This means designing an organization structure (roles and responsibilities) is a leadership task, that also might be adapted in cooperation with the team. Additionally, managing staff (hire and fire people) and their personal development, are tasks of agile leaders.
Hence, an agile leader needs to understand what skills it take to deliver. Due to my experience, it is more important to hire people who are open to learn than just experts. Learners get experts automatically. Experts, however, might be stuck in a certain field of expertise. Over time, they get inflexible and stubbornly. But this is not agile! In an agile team, you want to be flexible to react on external changes, such as new requirements from the customer or new technology opportunities, such as new pattern, programming languages, frameworks or development methods. 
On the other hand, being too flexible might end up in not being able to do anything right. So no expertise at all. This is the other end of the scale. But you quickly gain that information if you measure results of your team. And this is not micromanagement. It is just certainty about the capability to accomplish. The issue is not, that your team doesn’t deliver. It becomes an issue if they don’t change, once you figured that together. 
As a leader, you bring people together who are open to change but keen to accomplish.
Since your cross-functional team is capable to do the job and autonomous to organize how to do it, they might start to run quickly in different directions. As a leader, you still need one more ingredient.

3. Align the people by purpose.

Let me paint a picture showing the difference of a classical and agile product development team following the waterfall model (or even V-model, which is just two of them in a row).
The classical team is like a huge tanker. It is steady and a save place but it can not change course quickly. It overcomes a storm by just passing it. An agile team, in contrast, is more like a bunch of small, speedy rubber dinghies, which could quickly circuit a storm.

On the tanker, people are aligned, all in one boat. The people on the dinghy, however, could individually go in any direction. And this is exactly the challenge: You need to align the small dinghy team, give them direction but with a certain degree of freedom (otherwise you harm autonomy). You need a compass. And this compass is purpose.

The 3rd requirement of an agile team is to know (or better feel) their purpose. This the most powerful stage of commitment you might get. But, at the same time, it is the hardest part. And it is the leader's job. Unfortunately, it is not a management task you could copy from any book.

Purpose separates leadership from authority. If people know precisely "what" to do, they scale for well known situations. Good. If they know "how" to do it, they can inspect and adapt the method to deal with uncertainty. Even better. You could reach both levels with authority. But if your team feels "why" they do it, your team mates are hooked and they'll go the extra mile for the team. This is great! It feels great. And it frees you from being authoritative.

And what I personally like most is, with purpose your team figures the most stressful leadership aspect on their own. They do "crisis management".

To my experience, setting a meaningful product vision is a good vehicle to create purpose. Creating a product, that really helps customers, might mean a lot to your team. (Consider this in your hiring process.) Setting up a comfortable working environment and enable them to learn, is also a way to satisfy emotions.

However, it is crucial to be authentic, so it highly depends on the leaders personality. No lies!

4. Initiate a safe2fail culture.

To me, there is one more secret ingredient for leading an agile team. As easy as it is to talk (or write) about it, as hard is it to bring to life. It’s about culture. Hence, you could easily hide behind cloudy words and simply do nothing concrete or measurable but hiding in words. How does that fit into the agile world? Right, it doesn't!

Failure is necessary to learn. How would you learn if you’re doing it right from the start. Who are you knowing everything? And more importantly, how could you work on innovation (technology), which is by definition doing something that has never been done before? To my understanding, it is not possible. So you’ll fail - for sure. You fall. And? The questions are: Do you manage to stand up and how do you learn getting better? We could do that. The required human organ is called brain.  I know, that hurts.

To be clear, safe2fail does not mean that it's o.k. to fail all the time. And it does not mean random "try and error".

To me safe2fail means that you’re

• mighty enough to try some where you might fail,
• feel safe enough to show failure,
• have enough brain power to analyze it,
• are creative enough to come up with plan for the next time,
• have enough brain power to select the best plan - maybe.

As a leader you demonstrate this mindset and the space (time and money) to reflect and apply the resulting improvements. As a servant leader you wouldn't define such culture, you can just initiate it.

Generating the momentum is actually much easier than you’d expect. Simply, fail on your own! And show your team how you inspect and adapt to deal with it. This is leadership by example. If you, as a leader, do not have the standing to fail, how could you expect your team to?

My last big failure still hurts. It was that I did trust in a CEO who asked me for an agile transition of her company. After 14 month it got clear to me, that she didn’t lie to me, but she also didn’t tell me the full truth. So, she was certainly interested in getting her teams agile but she refused agile leadership and wanted to stick to old habits of command and control by hiding and trading information (like Stasi in the days of Eastern Germany). She simply could not share power.
To lean that, I gave 18 month of work. And I experienced that you need real support from all stakeholders, which was management and investors, for an agile transformation, since it is a cultural change - not just some project management methods and tools for the lower level people.

If management asks you for help, you can only trust in them but you could additionally gain some certainty making them prove that they not just talking but doing something for the agile change. Like a discovery sprint. I clearly missed that part. 

Agile leadership allows to split leadership responsibility - it scales

What patriarchal leaders miss is scale. A mafia boss is clearly the bottleneck of the organization. Also classical leadership might presume, that leadership is bound to a single person. This is not true in my experience. Instead, leadership can be separated into neutral, specific aspects, such as crisis management (see above), designing organization structure, staffing etc. Hence, it easily scales, provided that you can trust each other. Being a leader is a role to me.

Some of the leadership tasks are delegated to team members, due to self-organization. Others are co-created by the team and the leader, if the team still needs to learn how to do it. And some are handled by the leader as part of the team. In any case, the agile leader act by example with the goal to enable the team to do their job and to learn to do it even better in the future.

I defined some general rules for myself as an agile leader:

Rule no. 1: Aim to make yourself obsolete

The leaders objective should be to supersede himself. As an agile leader you’re not the boss you’re a servant to the team! Yes, there must be someone making the last call. This is not the point. Try to make them autonomous.

Rule no. 2: Just do it - help!

As a leader you're usually also a manager. Hence, you will end up in many meetings and discussions about strategy, culture and relationships. It’s a lot of work. So you’ll be very busy managing your business. At some point, you’ll become eloquent and good in negotiations. And a common strategy to deal with this bla-bla-situation is to just talk about things and stop actually doing them. You’re the manager, right? Hm. This approach does not work very well in the agile world being in conflict with the agile philosophy. Instead agile leaders simply help them to keep up autonomy, cross-functionality and purpose. Work for the team! Just do it! And they'll deliver great stuff with you.

Summary

Leadership is still leadership, even in the agile world. The objectives do not change. But the difference to the classically managed world is, that leaders can not escape any more into management tasks and hide behind words. Agile leaders need to actually do something. They support teams to become self-organized, gain knowledge, be aligned and feel safe to fail. To me, leadership is one role of many in an agile team, although the broad spectrum of aspects makes it hard to put it into a framework for now.

Since agile leaders support the team to learn, at some point, the leader should become obsolete. But until this happens, the leader should help and protect the team to inspect and adapt and the leader will personally benefit, too. At least there is less potential to get crazy.

Just do it!