Last Updated Mar 22, 2012 — Enterprise Agile Planning expert
Savant Leadership or Empowered Agile Team?
Enterprise Agile PlanningThere can be many reasons organizations struggle with their agile adoptions, but often it is because they're clinging to the idea that only a select few people can be trusted to do the real thinking. Design decisions are left in the hands of the leads or senior engineers, and so are the estimates. Tasks are then doled out as piecework to the "team resources" (who were recently drafted from the resource pool). Problems that arise are funneled to a leader, who evaluates them and dictates a plan of action.This type of "savant leadership" // or a few smart people taking it upon themselves to be the brains of the operation // tends to perpetuate a learned helplessness among the team members and a lack of a sense of ownership of their work. This has the unfortunate side effect of increasing the possibility that the work won't get done on time and/or won't be acceptable. And since all the decision/making is done by somebody else, who can blame the team when things take too long or it turns out that they built the wrong thing? Moreover, if the same handful of people always have the floor, existing blind spots become even larger. The ensuing groupthink can be suffocating to opportunities for innovation, both in terms of product and process. So although we might have applied agile development labels and we go through the formalities of the prescribed meetings of some particular agile development framework, if we haven't changed the way we think about our work and the people with whom we work, we're not going to see better results than we did before. We'll just have bundled the same set of ineffective principles and practices into some new packaging. The frustration most of us dealt with for years in waterfall is that we tried to plan and control our way to success, but we found that the world around us wasn't particularly interested in complying with our plans, and always seemed to wiggle free of our controls. What's refreshing when we first stumble upon this agile stuff is that we're allowed to acknowledge (finally!) that we're dealing with adaptive problems // problems for which there is no canned solution, and which may morph as we begin to apply solutions. For an organization to be successful in dealing with such problems, its leadership must be correspondingly adaptive. In doing so, adaptive leadership shouldn't attempt to provide all the answers, but rather, make a practice of keeping the vision clear and becoming really good at framing the right questions so that their people can collaboratively devise the best solutions possible right now. Two very common objections to this concept are:
- "Only our senior people really have the system knowledge to make design decisions and estimates"
- "Our system is too complex"