“And” Leadership

What is an agile leader or manager? There are countless answers to this question revolving around the characteristics or behaviors of agile leaders—for example, collaborative, light touch, servant, and failure tolerant. One of the traits I think is very important is that of “And” rather than “Or” leadership. The most pressing issues to face leaders are usually paradoxical; they appear to have contradictory solutions. Take for example the paradox of needing predictable delivery with that of needing to be flexible and adapt over the life of a project. Agile teams face difficult choices because managers haven’t addressed this paradox. They continue to admonish teams to do both, without really giving them direction about how. Or, then give lip service to adaptability and focus on delivering to plan—scope, schedule, and cost—just like in waterfall days. Or wore, they focus on velocity and forget quality.

Agile team succeed, in part, because they embrace seeing reality, the reality that “stuff” happens during a project and the path to success involves adaptation. Ambiguity, risk, and uncertainty are an integral part of innovative projects today. As such, they offer leaders paradoxical situations—situations that require backing away from the direct paradox and figuring out inclusive solutions. Adaptive leaders need to become “Riders of Paradox” as shown in the figure. The paradox horse seems always to be going in opposite directions at the same time. Furthermore, the leader is exposed, drawn by the traditional norms of many organizations in which it’s OK to be wrong, but not OK to be uncertain.

Agile leaders need the courage to view issue from different perspectives, to gather data without undue prejudice, to formulate both/and rather than either/or solutions. Too few organizations make it past what I’ve labeled “prescriptive agility,” which should be an oxymoron, but unfortunately isn’t. These organizations are as rigid about their agile implementations as they were previously about their heavy methodologies! They fail to move beyond rules to understanding. As the Dali Lama said, “Learn the law very well, so you will know how to disobey it properly.” Adaptive leaders need to be riders of paradox, always thinking “how can I do this, AND that” at the same time.

I’ll illustrate with three other examples from software development, three issues that have been written about as either/or: CMM versus Agile, BUFD (big up-front design) versus NUFD (no up-front design), and Scrum versus Kanban. In each case, proponents on either side have set the other up as an enemy to be defeated, and not looked at what is useful in each. The bottom line is that all models are flawed—Waterfall, PMI, CMM, Deming, Scrum, XP, Kanban, Lean—but all are also potentially useful. The true adaptive leader—be she or he an iteration manager, a project manager, a technical lead, a development vice-president, or a CIO—attempts to “include” the best from different models. Max Keeler from the Motley Fool talked at the US Agile 2010 conference about using Kanban on maintenance projects and Scrum on larger projects. Scott Ambler from IBM has a wealth of statistics from surveys that show most agile organizations use “just-enough” up-front design.

It’s easy to be an “or” leader. Pick a side and state your case loudly, over and over until the opposition gives up. It’s much more difficult to be an “and” leader, balancing between seemingly opposite strategies. However, in our ever-changing and turbulent world, slavishly following the “one right answer” is a recipe for disaster.


    1. Mr. Highsmith,

      The words you express echo my inner most feelings. Hearing them from someone so highly respected in the business and IT industry as you lets me know that I am on the right path with my thinking. I entered the IT filed at age 15, and I am now 36. Throughout my entire career I have attempted to learn the intent behind every software development, business and quality methodology/framework that I have encountered.

      It always amazes me how a good number of people will so strongly defend one approach and admonish all others. Understanding the history of Scrum, DSDM, RUP, CMM, Six Sigma, etc., they all seem to be a result of good people taking the initiative to change a flawed process and/or company. We all experience this on-going obstacle throughout our careers. It is very inspiring to hear this cycle so eloquently stated by someone such as yourself.