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.
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”
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.