Technical Leadership in Scrum Teams and Projects

>> Tuesday, October 27, 2009

I have been working for the past several months in an organization that has a number of teams that apply the Scrum methodology [1]. In fact, I am working within a Scrum team myself. The teams and team members are expected to apply very rigorously a series (if not all of) of the scrum mantras. These include the Scrum vocabulary, concepts and ceremonies. There is a lot to say about this experience but today I essentially want to share my views on team and program technical leadership in this particular scrum program.

What is somewhat striking in the way Scrum is applied in this program is that leadership in general is somewhat downplayed or neglected. Or let me put it this way: governance and leadership remain somewhat fuzzy and the advocated rules and practices encourage this. It is as if there was a reticence to recognize the need for leadership and the need to empower individuals with the responsibility to lead.

I admit that I am somewhat allergic to autocratic hierarchies and that I value collegiality, collaboration, democracy, consensual decision making and all. But I also value efficiency, good design, clear directions and a clear delimitation of roles and responsibilities. An ex-colleague of mine liked to repeat the same riddles over and over (don't we all have such a colleague?) and one of these was: What is a camel? Answer: A horse designed by a committee. I have nothing against camels but, to a North-American at least, they look somewhat awkward. In other words, I strongly believe that without strong and clear leadership in the various aspects of a software development initiative (since this is what we are concerned with), it is very difficult to produce solid, clean and effective software in an efficient manner. It appears, from my experience, that some (if not all) Scrum gurus (or at least practitioners) believe otherwise. At least they act and talk as if they believed otherwise.

As an example, we spent 45 minutes today in a team meeting (we had more than 15 people in the room) called a Sprint retrospective, trying to come up with a solution to a problem we had collectively identified in the preceding 10 minutes. To me, this is a completely futile exercise. I am willing to agree that a sprint retrospective can be useful and that if we collectively recognize that something needs to be taken car of we can fruitfully spend 10 or 15 minutes discussing the problem, gathering different views on the subject and on what should be done. However, trying, on the spot, to elaborate and decide upon a solution to this problem with 15 people around the table is sheer nonsense. Most real problems require analysis, design and implementation planning and this cannot be improvised in 20 minutes by a group of 10 or more individuals. It is best done by two or three people with one of them assuming the lead. In other contexts, the reflex in the above situation would generally be to delegate the responsibility to work on the solution to the most obvious people/person for the job and, if required, to present the proposed solution to the assembly for feedback. Is this approach passé? Is it anti-scrum? I really wonder sometimes.

To illustrate my point further, this particular program includes 6 scrum development teams that produce code on a daily basis and a good part of the software artifacts produced by any given team is used by or uses other team's artifacts. Yet, from the start, technical leadership in this program has been, and still is, fuzzy. The organization has not "officially" (or informally) recognized the need for technical leadership that spans the various teams.

This philosophy (if I can call it as such) is also present within the scrum teams. In fact, when I joined the program and was presented with it's modus operandi, one of my first questions was: Who assumes technical leadership within a Scrum team that develops software? The answer was not clear but between the lines I read that technical leadership was distributed and collegial and that it "naturally" emerged as the result of the sprinting effort. Hum, interesting approach I thought, can't wait to see the results. This notion is actually part of the "official" Scrum approach: the Scrum master exercises leadership but essentially as a coach to help the team apply the Scrum methodology not as an expert in software development. OK, I buy that: The scrum master's role is to help the team work in an effective fashion. So who designs the software? Answer: The team members! I also like that. I never liked the notion that a software engineer simply writes code. But who is responsible for the design of the software? When the answer is again all team members I sort of have an issue. A good leader, in any context, relies on his team members, calls upon their expertise when needed and welcomes initiatives and suggestions but when a choice has to be made, it is the leader's role to make sure the choice is the best one all considering. It is also the leader's responsibility to make sure that other team members design and build stuff that fits into the big picture.

Well, after observing (and working) with the teams for some time, I generally agree that in most teams, technical leaders did emerge. However, the roles and responsibilities remain generally unclear and are not officially recognized, the technical coordination between teams is deficient (nobody is clearly mandated to exercise this role) and a unifying design and direction for the various business functions produced by the various teams is clearly lacking. In fact, most software developers feel they are not given strong or clear technical orientations (or that these orientations arrive very late in the game, when most of the software has already been implemented) and there is clearly a sense of frustration with this aspect of their work.

When did leadership and governance become taboo in the agile world? Since when are we able to run lean, efficient and agile projects and organizations without clear, affirmative and recognized leadership? How are these concepts at odds with the concept of agility? I was comforted to read that the issue of unclear leadership and in particular of technical leadership in the Scrum methodology has been recognized by others [2]. Still others [3] seem to openly recognize the need for technical leads in Scrum teams.

Strong leadership in software development projects does not imply that decisions and orientations are taken blindly and without concertation and discussion. It does not mean that decisions and orientations cannot be challenged. However, without leadership (and in the case I am particularly interested in), without strong and recognized technical leadership inside the team and between teams, everybody is empowered with the capacity to go in whichever direction they prefer or feel is the best. You risk ending up with a camel (or a dog)!


1 commentaires:

Anonymous,  25 November, 2011 00:18  

Right on the money. I've just gone through a scrum book and failed to make any sense of the technical leadership part (or rather of its absence) in the process. It is my understanding that it will take a single self-opinionated difficult team member to turn the whole enterprise into absurd if the "team decides..." principle is implemented to the full as the gurus profess.

Post a Comment

  © Blogger template Webnolia by 2009

Back to TOP