I have been doing Scrum for well over 7 years. I like Scrum, I am one of its strongest proponents. In fact, my company, Net Objectives, is one of the largest Scrum companies in the country in terms of the number of people we have trained and coached in Scrum-related activities. Yet, I am amazed at how many Scrum trainers/coaches/practitioners continue to miss the point of leadership and management in software development.

For example, I was recently part of a series of e-mail discussions that included many experienced Scrum practitioners. I was surprised by the number of posts describing leadership as either manipulative in nature or just a plain old bad thing. Then I noticed a post by Ken Schwaber that seems to underscore an attitude that management typically involves itself only in bad ways (see here for the full text):

The catch is that Scrum, like all Agile methodologies, depends on self-managing teams—the exact opposite of most top-down directives. While management may understand that Scrum succeeds largely because the people doing the work define how to do the work, resisting the urge to intervene can be very hard, particularly when someone has stuck her neck out to make the top-down implementation happen. Managers who have initiated the Scrum implementation often feel responsible for its success and revert to command-and-control tactics.

There underscores the notion that self-managing teams and direction from the top are somehow opposed to each other. In practice, this may be. But that is because in practice, leadership is missing. Direction in the form of command and control is bad. Direction in the form of vision and matching people to their abilities is not. This points to one deficiency I have seen in the general Agile community, and one that, I believe, is a serious impediment to having the Agile community have success at the enterprise level. I am referring to the fact that most Agilists do not trust management to do what is right – they feel the team must be protected from management. I have heard this opinion voiced in several books and from several leading agile consultants/practitioners – and I disagree with it.

While it is true that the direction of the team should not be capriciously changed, I rarely hear conversations about educating management in why capricious change is a bad thing – instead we must make it so they have no change to meddle. Ironically, the entire Chicken and Pigs metaphor for which Scrum is famous for strengthening this. We can’t have Chickens (management) even have the option to talk as they will derail our team. Why? Because deep down we don’t trust them. Yet, we expect them to trust us to self-manage ourselves.

Unfortunately, this attitude has been pervasive from the beginning of the Agile community. Given the heavy focus on over-bearing process that has gripped this industry for years, this is not surprising. However, it is time to include leadership and management in the transition to agile methods. We must see how we can marry respect for people (and hence the team) along with process.

This requires leadership and proper management.

Let me define what I mean by leadership and management. I like Marcus Buckingham’s definitions of these two complimentary but distinctive roles. Buckingham, in his excellent book, The One Thing You Should Know describes leadership as the "ability to create a solid vision of a better future for those people he/she is leading. " A leader must have a compelling desire to move towards that vision. Buckingham defines management as the "ability to match people’s tasks with their skills. " A good manager is liked a skilled Chess Master. As opposed to checkers, where all the pieces (until one gets kinged) are the same, in chess, different pieces have different strengths. A good chess player knows how to use these strengths. A good manager knows how to maximize the strengths of his staff. Hence, leadership and management are not opposed to each other – they just have different functions.

Ironically, the need for proper leadership and proper management is illustrated in another excerpt in the same article by Ken Schwaber that I alluded to before:

Command and control has two negative effects on a Scrum team. First, developers get in the habit of waiting to do anything until they are told what to do. As a result, they often are afraid to take the initiative and are used to blaming management for stopping them from doing so. Second, management often feels as if it is not doing its job if it doesn't come up with answers and instead waits for developers to figure out solutions on their own, including letting them make mistakes.

In practice, teams require leadership. Without it, it is very likely they will continue moving forward in the way they have in the past. Again, many Scrum consultants say what is needed is a ScrumMaster to do this. But even here, the community is split equally between the ScrumMaster’s role to remove impediments from the team and the ScrumMaster’s role to lead the team. Depending upon which CSM course I am listening to or which Scrum Gathering I am going to I hear different things.

In any event, even if the team can provide it’s own leadership, it is still left to work within the existing structure of the organization in which they find themselves. This may not be a good thing.

Keeping Buckingham’s views in mind, the role of leadership and management then is to create the vision for the Scrum teams to be effective and to staff the teams with the appropriate resources. But just creating the vision is not enough. Leadership and management must help create the structure within which the team works to assist the team. This is something Scrum teams cannot do on their own. Ignoring this issue is what often has Scrum teams feel they must protect themselves from the organization when what they need to do is help the organization see how to better support the team.

If Scrum can’t help us here, what can? This is where Lean Thinking comes in. In a nutshell, Lean Thinking tells us to set things up so we can have fast-flexible-flow. That is, we can get customer requests in and get business value out – quickly and repeatedly. At Net Objectives we base our entire software development philosophy on this (which is why we call it SPeeD: Sustainable Product Development). The issue is – “how can I develop software quickly now (to deliver business value quickly) while retaining the ability to add business value quickly in the future.”

Scrum is effective because it is an implementation of this Lean Thinking philosophy. In fact, Scrum was invented by Jeff Sutherland out of his study of Toyota and their use of Lean and the knowledge management strategies developed by Takeuchi and Nonaka.
Lean’s underlying foundation is based on a combination of:

1. Respecting people
2. Continuous process improvement
3. Avoiding waste by eliminating impediments to flow

Lean doesn’t set up a “management vs team” mentality. Instead, it embraces management and team. Management to assist the team in building the best process possible.
At some point, I hope all Scrum/Agile practitioners also embrace management, not as a problem to overcome, but as a valuable resource to enlist. I suggest that by learning more about Lean principles that Scrum practices can be improved. Without embracing leadership and management, we will have great difficulties in getting Scrum to be successful in the enterprise.

In a future post I’ll talk about why Scrum has had a better track record in product organizations than it has in IT organizations. The reason for this is, not surprising to those how understand Lean, related to this blog.

If you are interested in how Net Objectives can help you extend and support your Scrum practices with Lean Principles, please send me an email at alshall @ netobjectives.com (leave out the spaces) and I’ll be happy to discuss it with you or forward you on to the correct person in our organization. You can also get more information from our website by registering here.

Technorati Tags: Design Patterns Lean Lean-Agile Scrum

tag with del.icio.us