Effective agile leadership patterns

Many organizations struggle with the notion that "leadership" equals position on the Org Chart. That is, the C-Levels lead everyone, division heads lead their division, team leaders lead their team etc. This concept may have been valid at a time when people were not sufficiently educated to discover the best way forward autonomously. But this is questionable in a world where managers don't even understand the work done by their teams. We have discussed previously that leadership is situational based on the situation of the team. Let us take a look at three different leadership patterns.

The Forerunner

The most straightforward way of leading agile is "to boldly go where no man has gone before",
A forerunner experiments, takes new ways, and learns by Inspect+Adapt, taking others along on their journey.

A forerunner is effective when others continue the journey they started.
It's very difficult to be a forerunner when the things you're doing are not the same things others are doing.

The Enabler

Another way of leading agile is by enabling others "to boldly go where no man has gone before".
An enabler considers the roadblocks which prevent others from experimenting, taking new ways and learning by Inspect+Adapt.
To enable, "walking gemba" is essential, i.e. seeing the reality of the problems causing others to not move forward.  Scrum typically sees the Scrum Master as the team's enabler, although the PO can also go a great length in clearing road blocks as well.

An enabler is effective when others can move beyond the path they cleared.
The further a person moves away from the team, the less effective they are at enabling. Likewise, decreasing proximity increases misunderstandings and "doing the wrong thing".

The Thought Leader

A thought leader does not lead by doing, but by providing impulses.
It is completely up to others to start experimenting, taking new ways or learning based on the impulses provided by a thought leader.

A thought leader is effective when others are inspired to try out the things the thought leader suggested.
Thought leaders can be completely disconnected from the team's situation, because they are just offering inspiration. They might even be completely disconnected from the team's organizational context, making their inspiration useful nonetheless.

What this means

None of the proposed three leadership patterns relies on a position on an org chart. Except for the Enabler, who can be effective by dissolving impediments caused by the org chart itself, agile leadership works best without positions or titles on an org chart.
Titles may even be counterproductive. Leading agile is something that you either do or don't. It is entirely possible that a regular developer in a team is a more effective leader than all the managers in the company together.

The most plausible way for a line manager to be an effective agile leader is in an enabler.
Forerunning is only possible by forsaking the position in the Org Chart and joining an agile team.
Thought leadership takes extremely deep understanding and many years of expertise and is difficult to attain for managers.

Conclusion

The harsh truth about "agile leadership" is that organizations have a problem with middle management.
When lots of middle managers find value by acting as enablers, we probably have so many organizational impediments that the organization is pretty much doomed. However, when they can't function as enablers, they can't be considered "leaders" any more than any other person on the development teams.

Sprint 0? Good? Bad?

I recently joined a discussion where people advocated against "Sprint 0".
The arguments delivered are along the lines of "Sprint 0 is only necessary when you consider Scrum a process", "It involves people that don't need to be involved", "It overloads the terms", "Waste", "BUFD", etc.


So, let me create a bit of transparency, regarding what I consider as "Sprint 0":

The following side conditions are in place:

• It's not necessarily the same time box as the delivery Sprints, but we're working time boxed
• There is a Backlog for things we need
• The Deliverables are: 
• A clear Product Vision
• A team that can deliver, including a capable PO and SM
• A technical environment which permits the team to deliver
• Management supports Scrum
• Stakeholders are aware of how Scrum changes the game
• Assured Funding
• Dedicated availability of developers on the team
• The team (i.e. the transition team) is delivering using an Inspect+Adapt approach.

There is no doubt that such a phase is necessary, so that the Scrum team has a chance to succeed.

To me, discussing about how to name that phase is just a game of po-tay-to, po-tah-to.

Maybe we can end the religious discussion around Sprint 0 by just calling it the "Potato"?