Distributed Agile Leadership

Distributed teams are the norm for many organisations today. Companies are global, communications technologies allow people to live away from the "office" location and many of the new workforce are nomads. Becoming a high-performing team is possible in a distributed group, it just takes more effort to overcome the inherent challenges of distance.

This is the sixth in a series of articles which explores the impact of cultural differences on distributed teams - "Distributed Agile - how to work with teams across the globe". You can subscribe to receive notifications via RSS.

I've started developing a distributed agile framework together with 2 others: Hugo Messer, and Savita Pahuja.  We are still in the inception phase. Our belief is that we should open source a big part of the framework. The framework we have developed consists of 6 'bubbles':

1. Culture
2. Organization
3. Product
4. Teams and Tools
5. Communication
6. Leadership

Introduction

Even with the best of planning for your distributed Agile team, without good leadership in place, all of that planning can come to naught.  With that in mind we will now take a look at some leadership trends that are relevant to self-organizing distributed Agile teams.

Instead of proposing a new “Distributed Agile Leadership Framework” our goal here is to inform the reader of important and relevant trends.  It is left to the reader to incorporate these in their own Distributed Agile team or organization.  Leadership is a very personal discipline, and differs from person to person and organization to organization.  It is for this reason that we will not attempt to prescribe a leadership framework but rather an effective set of tools for Distributed Agile teams.

It is also key to note that Agile is broader than just software development, and leadership is also.  Our leadership discussion in this section will transcend focusing only on software, but is at the same time fully applicable to software and technology. 

We now begin with a very relevant trend in leadership and organizations: There has been a shift in leadership and management approaches toward empowered and self organizing teams. This has been termed the shift to “Teal” Management.

While the “shift to Teal” is a more big picture view, there is an interesting perspective on self-organization in teams and organizations that states basically that organizations with self-organizing teams actually still have leaders / leadership.  This perspective brings the big picture view above more in focus in individual organizations and companies.  This is discussed in a book by Lex Sisney titled “Organizational Physics - The Science of Growing a Business”.  Sisney proposes that in reality instead of having top-down or bottom up organization, some of the most new and adaptable organizations are actually “Design-Centric” organizations.

Source -  Team of Teams: New Rules of Engagement in a Complex World

Although it looks like in this example there is simply a team of teams and no other organization, you can actually see in the diagram below that there is still a leadership structure, but it is based on “Design-Centric” leadership.  Buurtzorg - a provider of local nursing services in the Netherlands - is a good example of a Design-Centric organization.  Below, the example is based on the approach used in the US war in Iraq by US General McChrystal to lead his special operations forces.

Source -  Team of Teams: New Rules of Engagement in a Complex World

So the leadership shift is not a choice of top-down or bottom-up, but rather one where the leader designs a system within the organization that allows teams to self-organize and to be empowered to deliver the organization’s objectives.  If this is done well, there is little need for the leader to intervene in the organization or system because the people and teams are able to effectively lead and guide the organization themselves.

Source

Sisney concludes that a mix of top down and bottom-up is ideal in the Design-Centric approach.  My co-author Hugo notes that vision, strategy, culture and structure are not only the work of the leader, but evolve in the organization.  The teams are a part of shaping these key aspects and not just the leader single handedly setting direction.  This evolving organization is a leadership concept that is also described by Frederic Laloux in his book “Reinventing Organizations”.

Source

Modern Agile

Another relevant Agile leadership trend is the evolution of Modern Agile.  These principles build on the foundations of Lean Principles, and the Agile Manifesto, and help to extend Agile beyond the domain of software development.   Again in this section we look at Agile leadership questions, practices and virtues broadly extending beyond core software development teams.  However this section is completely applicable for leadership of a distributed Agile software team, as it is for a distributed Agile team developing smart phones, a book, or a new clothing line.

For those not familiar with the principles of Modern Agile, we will provide a brief introduction here.  I also provide a short video blog introduction to the topic that can be found on the Auspicious Agile blog.  The image below is the Modern Agile “Wheel”:

Source

There are four guiding principles, as seen in the wheel above:

1. Make People Awesome
2. Deliver Value Consistently
3. Make Safety a Prerequisite
4. Experiment and Learn Rapidly

As we explore leadership in distributed Agile teams we will look in more depth at how some of the principles from Modern Agile apply.

Keeping in mind the principles of “Teal” Management and Design Centric organizations, as well as Modern Agile let’s now take a look at some of the leadership Questions, Virtues, and Practices that apply to distributed Agile teams and leaders.

Questions

1. Is there a common leadership team / structure across the different team locations?
2. Does the leadership culture reward and value collaboration?
3. Is decision making delegated to the lowest practical level in the distributed Agile organization?
4. Is leadership empowering and encouraging of distributed Agile teams?
5. Do Agile teams trust their organizational leaders and believe that they say what they mean and mean what they say?
6. Does the organization's leadership cast a clear vision and strategic themes / imperatives that are shared with and known by all team members in all locations?
7. Do distributed Agile teams feel safe to make mistakes and learn from them?

In the rest of this section we look at some ideas and stories related to these distributed Agile leadership questions.  Our first story is about a distributed team that I worked in that crossed the US and Asia, we encountered multiple issues based on these questions.   Because we had a team in Asia, and a team at our headquarters in the US there was an “us” vs “them” mentality.  This caused most decisions and communications to be scrutinized and certainly not as effective as they may have been if we had fostered a “we” mentality instead. 

At one point a new interim leader was installed, that leader actually never set foot in Asia.  This made for an environment where there was little trust among team members at our distributed locations.  Travelling to meet people in person and establish rapport and understanding is very key to getting distributed teams off to a good start.

In one organization much of the work that my team was responsible for in Asia required pricing our products and services for the various Asian countries where we did business.  However, our US headquarters would often ignore, or override our suggestions for price adjustments for Asia and would simply apply US pricing throughout the region.  In many cases this caused us to not be able to be competitive in the Asia market.  This is an an example of not delegating decision making to the lowest practical level in the organization.  As a result much of the efforts of our team in Asia were frustrated because decisions were made by leaders far away from the “heartbeat” of what was actually happening with our work on the ground.

In our question regarding whether the organization’s leadership culture rewards and values collaboration, we will share another experience: In another organization the incentive scheme set up for development teams does not encourage collaboration.  Rather the incentive scheme rewards individual contributions and in many ways actually encourages team members not to collaborate and to withhold information in order to get ahead of their peers.  Even for team members with the best of intentions the system is not structured to foster team collaboration. 

W. Edwards Deming is quoted as saying - “the aim of leadership should be to improve the performance of man and machine, to improve, to increase output, and simultaneously to bring pride of workmanship to people.  Put in a negative way, the aim of leadership is not merely to find and record failures of men, but to remove the causes of failure: to help people to do a better job with less effort.”  Deming’s point is that if leaders do not create the system to help people improve, it makes little difference how hard individual people in the organization work, the system must support their success.  So to foster collaboration leaders need to reward the efforts of teams, and not only look at individual effort.

The Modern Agile principle of “Making Safety a Prerequisite” is the focus of our next question.  Do the distributed Agile teams in your organization feel safe to make mistakes and to learn from those mistakes.  In Joshua Kierievsky’s InfoQ article introducing Modern Agile, he recounts a story from Google where an engineer cost the company millions because of a coding mistake in the AdWords code (AdWords is where Google makes its money).  However, rather than making an example of the engineer who admitted to the screw up, the engineering manager brought the team together to hold a “What did we learn” session.  The team identified what went wrong and how to prevent similar problems in the future.  It was identified that these learnings likely saved Google far more than the original mistake cost them.  But the biggest learning was that there was a safe culture to speak up if a mistake was made and to learn rather than being blamed.  Unfortunately, more often than not there is a culture of blame that prevents distributed Agile teams (or any team) from really feeling free to learn or admit mistakes.

It is key to ask the leadership questions that we have outlined above to ensure that your distributed Agile team is able to be effective from a leadership perspective.  John Maxwell, best selling author and speaker is known for saying “everything rises and falls with leadership”.  Even if your distributed Agile team has a great product idea, and all the right tools and skills, like our team in the story above, your team’s efforts can be frustrated by not setting up the right leadership structure to empower your team.

Virtues

1. Empowerment: motivate people to self-organize and take decisions
2. Servant leadership: mentor and coach instead of control
3. Share: openly share vision and strategy across locations
4. Trust:  Make mutual trust between distributed teams and leaders a centrepiece of the working relationship
5. Evaluate and Reward:  Team progress and contribution toward organizational goals across all distributed Agile team locations
6. Growth Mindset instead of Fixed Mindset:  Ability to lead distributed Agile teams and empower the teams to continuously learn

Next we will look at some stories and ideas related to the distributed Agile leadership virtues.

I share in my Auspicious Agile blog the story of “Bob” that I title “The Worst Agile Boss I Ever Had”.  At a US based services company we had been one of the early team’s adopting Agile methods.  What made Bob such a bad manager was that he was a fear based leader.  There was almost no trust in the team because of Bob’s approach to leadership. In fact this is the only instance in my working career where I witnessed a grown man break down in tears in a business meeting.

A lack of trust in teams can lead to a crippled team that can not perform.  Conversely a high level of trust can lead to highly effective Distributed Agile teams (think Open Source projects like Apache, Linux, Tomcat, and even WikiPedia).  While not dominated by one person or boss, these projects have a high level of trust between participants who have common goals and shared vision.

Growth “Agile” Mindset and Servant Leadership are also critical leadership elements for distributed Agile teams.  Growth “Agile” Mindset is described by Carol Dweck in her book “Mindset, the Psychology of Success”, as a mindset that is always learning, taking on new challenges and getting smarter because of new challenges.  This is juxtaposed to a Fixed mindset which is described as one that believes it can not get any smarter, and therefore must avoid any challenges or failures at any cost.  Servant leadership is simply described as serving through your leadership and leadership being your form of service.  A servant leadership approach means the leader is not leading only for their benefit, but they are leading as a form of service to the people on their team or in their organization.  For more background the reader can view this Auspicious Agile video blog on Growth Mindset and its importance.

While these the terms Growth Mindset and Servant Leadership may be overused, it doesn’t diminish their importance.  For example even when a distributed team or organization adopts Agile methods, a lack of Growth (Agile) Mindset can limit their success.  The distributed team / organization may use Scrum, and follow all of the Scrum ceremonies.  However, if a problem arises leadership’s first response may be to find someone to blame.  This non- Growth Mindset behavior by leaders will render moot most -- if not all -- of the benefits of using Scrum as a distributed Agile method.

Likewise servant leadership is an essential ingredient for distributed (or any) Agile teams to live up to their potential.  When servant leadership is lacking we end up with the fear based scenario described earlier with my old boss “Bob”.

On the other hand when servant leadership is demonstrated there are very different results.  An example is in a blog post I wrote entitled “The Best Agile Manager I Ever Worked For”.  There the team manager / leader “Jack” supported our Agile development team.  We trusted his intentions, and even though we were under tremendous pressure to deliver a US Government project, our Agile team had high morale and was able to deliver.  The key difference was that (whether he knew it or not) Jack was a servant leader.  He was not ego or fear driven, but rather his actions were focused on making the team more successful.

We have only covered a few of the virtues here, I hope that you can see what a difference leadership makes in the work and productivity of a Distributed Agile team, or any team for that matter.  So when you structure your team, consider culture differences, tools, products, but always start by ensuring you have the right leadership in place to make your distributed Agile teams really soar!

1. A Lean / Agile servant leadership approach
2. Empower distributed Agile teams to deliver value
3. Allow those close to the work to make relevant decisions about their day to day work
4. Cast clear organizational and product vision for Agile teams, so that teams can enjoy a high level of alignment and autonomy
5. Funding and allocating budgets to distributed Agile teams to "spend" on their product backlogs
6. When there are multiple Product Owners across locations use a Product Management Group or Chief Product Owner and "Delegate Product Owner" structure to align them

Here we look at some stories related to these distributed Agile leadership practices.  In a talk by Henrik Kniberg at Agile Tour Bangkok he described the way he organized teams in his experience at Spotify and LEGO.  He noted that the more alignment a team has based on clear leadership direction, the more autonomy that teams can enjoy.  This is to say that what gives Agile teams the most autonomy is actually not a lack of leadership, but rather clear leadership vision and alignment.  This is interesting as it reflects the idea we discussed in the introduction about “Design-Centric” leadership and organizations.  Instead of a top-down or bottom-up Approach.

For those familiar with Scaled Agile Framework (SAFe), the model for funding Agile programs use ”value stream funding” which means that the organization or stakeholders allocate a budget, but after that they leave “content authority” with the Product Owner and the teams.  This structure allows those closest to the work to determine how to best deliver value in terms of features and stories.  Leaving teams free to deliver the highest value to their organization even if they are distributed at multiple locations around the world it is not necessary to keep returning to leadership to get approval for changes.

Another leadership practice is to have multiple Product Owners.  In Large Scale Scrum (LESS) this takes the form of a Product Owner and Area Product Owners responsible for specific areas.  In SAFe this takes the form of a Product Management team and Product Owner of each team that work with the Product Management team.  The key here is that the Product Owner(s) are key leaders in a distributed Agile team, and having clear vision and alignment allows for team clarity and autonomy.

If you are interested in learning more about the distributed Agile team leadership questions, virtues, and practices covered here you will want to read our soon to be released ebook, planned for release as an InfoQ ebook and on Amazon.  The ebook will cover the 6 bubbles and go into more depth, and include more stories from our team and other experienced practitioners as we follow our “open source” ebook model.

About the Author

John Okoro is the creator of Auspicious Agile and he has founded Agile services practices for Rally Software in Asia and for a US management consultancy.  With nearly a decade using Agile methods, John is an expert at using Agile practices and methods at Enterprise scale and in large and distributed organisations.John is a frequent speaker at Agile and industry conferences and an InfoQ contributor on DevOps.  John has consulted in the telecommunications, entertainment, real estate, information services, financial services and professional services industries for numerous Fortune 500 companies including Disney and Accenture. He is experienced with start-ups, entrepreneurial ventures and working with US government clients.  John also teaches on Agile Scaling at National University of Singapore (NUS).

Distributed teams are the norm for many organisations today. Companies are global, communications technologies allow people to live away from the "office" location and many of the new workforce are nomads. Becoming a high-performing team is possible in a distributed group, it just takes more effort to overcome the inherent challenges of distance.

This is the sixth in a series of articles which explores the impact of cultural differences on distributed teams - "Distributed Agile - how to work with teams across the globe". You can subscribe to receive notifications via RSS.