Skip to main content
Enterprise Agile Planning icon with arrows

This post is from the Collabnet VersionOne blog and has not been updated since the original publish date.

Last Updated Mar 22, 2012 — Enterprise Agile Planning expert

Savant Leadership or Empowered Agile Team?

Enterprise Agile Planning
There 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.Carnac had ALL the answersThis 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"
To the first objection, I have to ask why that situation is acceptable. The adaptive leader would recognize this as risky on more than one level, and ask, "What can we do to ensure system knowledge is disseminated throughout the team(s)?" To the second objection I'd say, "Maybe it is... So what are we going to do about it?" Since we know that man/made systems (especially software systems) are likely to become more complex than they are less complex over time; complexity in the system is going to grow unless something is consciously done about it. So instead of being fatalistic about it, and allowing this to be used as a reason to throttle collaboration, the adaptive leader would recognize this objection as a warning of even more limitations to come, and begin looking to the organization's team(s) for a way to understand and reduce the complexity. High/performing organizations have long realized the advantages that can be gained through the collective creativity and intelligence of empowered (pronounced "trusted") people. Start trusting your agile development team. Give them a license to think, listen to them, let them devise solutions to the problems they face, and reap the rewards.

More from the Blog

View more Government Cloud
Apr 12, 2022 Government Cloud receives FedRAMP Authorization through sponsorship from the United States Department of Veterans Affairs

Enterprise Agile Planning
Flagship Agility solutions can effectively scale agile deve ...
Read More
Nov 22, 2021

What are the qualities of highly effective agile teams?

Enterprise Agile Planning
A team is the core unit of productivity in an agile organization. Wher ...
Read More
Nov 15, 2021

How an open-first attitude revolutionized government tech development

Enterprise Agile Planning
Public perception of government is often that it is slow-moving, reluc ...
Read More
cross functional
Nov 08, 2021

6 best practices for building resilient cross-functional teams

Enterprise Agile Planning
Agile frameworks prize the quality of resilience within every facet of ...
Read More
Contact Us