Agile Leadership  🔗 **Source:** [Agile Leadership](https://blog.scottlogic.com/2026/08/10/agile-leadership.html) > [!note]+ Document Notes > > [!info] Generated analysis — not the author's words. Sections below are machine-written > > from the captured source. Only text inside `> [!quote]` blocks is verbatim from the author. > > Do not quote or attribute any other line to the named author. > --- > tags: [agile-leadership, mission-command, engineering-management, trust-and-delegation, organizational-culture] > author: Dave (Scott Logic) > source: Scott Logic Blog > reference: https://blog.scottlogic.com/2026/08/10/agile-leadership.html > date created: 2026-08-10 > --- > # 🏷️ Title: Agile Leadership > ## 🧭 Table of Contents > - [📝 Summary](#-summary) > - [📖 Main Content](#-main-content) > - [🗒️ Notes](#️-notes) > - [📚 References](#-references) > - [🗣️ Paraphrase](#️-paraphrase) > - [📰 Newsletter](#-newsletter) > - [✅ Action Items](#-action-items) > - [🧪 Hypotheses](#-hypotheses) > - [📊 Methodology](#-methodology) > - [❓ Questions](#-questions) > - [🔮 Future Research](#-future-research) > - [💡 Implications](#-implications) > - [🧠 Learning Styles Assessment](#-learning-styles-assessment) > - [📊 Accessibility Assessment](#-accessibility-assessment) > - [🌍 DEIB Assessment](#-deib-assessment) > - [✅ Logical Validity](#-logical-validity) > - [🛡️ DARVO Analysis](#-darvo-analysis) > - [🎯 Conclusion](#-conclusion) > ### 🔗 References > - [Agile2](https://agile2.net/) > - [The Habit of Excellence, Lt Col. Langley Sharp MBE](https://www.army.mod.uk/support-and-training/our-schools-and-colleges/centre-for-army-leadership/the-habit-of-excellence/) > ## 📝 Summary > - Dave, a Lead Developer at Scott Logic, argues that leadership and agility are not separate concerns but inseparably intertwined — agility is a mindset that cannot succeed without leaders willing to empower teams. > - The essay uses the British Army's post-WWII shift toward Mission Command (empowering subordinate commanders via intent-based orders rather than tight top-down control) as an analogy for what agile software leadership should look like. > - Key stakeholders: engineering leaders/managers who set direction and delegate; individual contributors/teams who need trust and context to make autonomous decisions; senior stakeholders who need visibility without micromanaging. > - Risk/tradeoff named directly: too little upward/downward communication of intent either causes stakeholders to clamp down and restrict team autonomy, or leaves teams unable to make good independent decisions and reflexively escalating everything upward — both outcomes erode the agility the leadership style is meant to produce. > - Bottom line: agile frameworks and ceremonies are insufficient on their own; agility is enabled and bounded by how much leaders trust, delegate to, and communicate intent with their teams. > ## 📖 Main Content > - The essay opens from a talk on "Agile2," a movement that repositions leadership as central to agility (versus the original Agile Manifesto's team/process focus). > - Central analogy: the British Army's Mission Command doctrine, developed because post-WWII conflicts (Northern Ireland, Iraq, Afghanistan) demanded rapid, unpredictable, decentralized decisions that couldn't wait for orders to travel up and back down the chain of command. > - Mission Command mechanics: commanders set intent and boundaries; junior leaders fill in execution details and can even deviate from direct orders if it serves the broader mission — a decentralization pattern the author maps directly onto agile software delegation. > - Trust is framed as multi-directional and multi-layered: leader-to-team (empowering without abandoning), team-to-leader (confidence that direction is sound and mistakes won't be punished), and peer-to-peer (trusting teammates to act in the team's interest). > - Communication of intent must flow both ways: "two levels up, two levels down" per the Army's own framing — applied to software as senior stakeholders needing visibility into direction, and developers needing sprint/project work framed in larger context. > - Two named failure modes when intent isn't propagated: (1) stakeholders kept out of the loop tighten control and restrict team freedom; (2) individuals lacking context escalate every decision upward, reinforcing leader-dependency and undermining the whole model. > ### 🗒️ Notes > - The article is a single continuous essay (no timestamps) — dense notes are provided in place of transcript segmentation. > - Frames the debate as a real open question the author is working through, not a settled thesis stated up front: "Can agility help to prop up or even be a substitute for poor leadership, or is it instead the case that poor leadership restricts how agile you can be?" > - Positions Mission Command as historically "hard won through experience and situational requirements" — i.e., not a top-down design choice but an adaptation forced by battlefield conditions, paralleling how agile software practices emerged from the failure of rigid, plan-driven delivery. > - The essay's structural arc: define the tension (leadership vs. agility as separate or fused) → introduce Mission Command as a worked example → extract the trust/communication mechanics that make it function → restate the thesis as a settled conclusion. > - Notably absent: no discussion of what happens when leaders delegate intent but the team lacks the skill or judgment to execute autonomously — the essay assumes competent teams and focuses entirely on the leadership side of the equation. > ## 📚 References > - [Agile2](https://agile2.net/) — the "next iteration of agile" project that foregrounds leadership > - [The Habit of Excellence, Lt Col. Langley Sharp MBE](https://www.army.mod.uk/support-and-training/our-schools-and-colleges/centre-for-army-leadership/the-habit-of-excellence/) — primary source for the Mission Command analogy > ## 🗣️ Paraphrase > - Opening: Leadership and agility get discussed as if separate, but a team can adopt every agile practice and still fail without leaders brave enough to actually empower it. > - Agile2 background: A talk on Agile2 (a leadership-centric successor to the original Agile Manifesto) prompted the author to question whether the original manifesto really "dismissed" leadership, or simply treated it as a separate topic. > - Mission Command origin: The British Army's post-WWII shift to counter-insurgency and peacekeeping made rigid top-down command impractical, so it moved to an intent-and-boundaries model that trusts junior leaders to act — even against direct orders — in service of the mission. > - Software parallel: Agile development exists for the same reason Mission Command exists — situations evolve too fast for centralized decision-making, so leaders must empower people closest to the work. > - Trust and communication: Multi-directional trust (leader↔team, peer↔peer) and two-way communication of intent are what make decentralized authority safe; breaking either link causes stakeholders to re-tighten control or teams to become escalation-dependent. > - Conclusion: Agility isn't just following agile practices — it's a mindset that leadership either enables or forecloses. Leadership is the foundation, not a parallel track. > ## 📰 Newsletter > Scott Logic's Dave (Lead Developer, Edinburgh) makes the case that your standups and sprints don't matter if leaders won't let go of the wheel. Borrowing from the British Army's Mission Command doctrine — forged in Northern Ireland, Iraq, and Afghanistan, where waiting for orders from HQ got people killed — he argues agile software teams need the same deal: clear intent, real boundaries, and trust to act without a permission slip for every call. Worth a read for anyone in The WPOCC or WordPress core teams thinking about how contributor autonomy and maintainer trust actually scale. Full post: [Agile Leadership](https://blog.scottlogic.com/2026/08/10/agile-leadership.html). > ## ✅ Action Items > #### DevRel > - Developer advocacy: n/a — this source is a leadership essay, not developer-facing content; no advocacy asset to build from it directly. > - Education: could inform a DevRel/community-lead training session on delegation and "intent-based" enablement of community contributors and moderators, mirroring Mission Command's two-levels-up/two-levels-down communication pattern. > - Developer experience: n/a — n Often, leadership and agility are discussed as separate concerns. In this post, I argue that they are not merely related but inseparably intertwined. Agility is a mindset rather than a process, and while teams may adopt agile frameworks, follow principles and genuinely want to work in an agile way, they will never truly succeed unless leaders have the appetite and courage to empower them. detail scale #### Leadership and Agility Some time back I gave a short talk on [Agile2](https://agile2.net/) to the Scott Logic Agile Community of Practice. It’s a concept that I came across by accident, which bills itself as “the next iteration of agile”. Agile2 seeks to, in their own words: > [make] a fresh start … not an incremental one: a start that is informed by the first Agile experiment, but that does not hesitate to make major departures: a new beginning. > > One of the things that struck me while researching the topic was the huge focus on leadership; indeed, a whole section of the documentation is devoted to it. The authors claimed that the original manifesto “dismissed the importance of leadership” the first time round and by making it such a major focus they seemed to be implicitly including leadership as part of their definition of what it means to be agile. I remember thinking at the time that I didn’t wholly agree that leadership was necessarily “dismissed” as not important; rather, it felt like a separate topic to the concerns of the manifesto and its principles, which focus more on process and teams than on the nuances of leadership. This, however, raises the question of whether leadership is indeed a separate concern from agility. Leadership is always a factor in a team’s success or failure, but does it exist independently of that team’s ability to be agile? We often talk of agility as something that, while of course augmented or facilitated by good leadership, is nonetheless independent of it. Can agility help to prop up or even be a substitute for poor leadership, or is it instead the case that poor leadership restricts how agile you can be? Likewise, can we substitute agility with good leadership? Is our ability to be agile less important if we have good leadership overall? #### Mission Command In his book [The Habit of Excellence](https://www.army.mod.uk/support-and-training/our-schools-and-colleges/centre-for-army-leadership/the-habit-of-excellence/), Lt Col. Langley Sharp (MBE) describes the British Army’s approach to leadership, how it has evolved, and why it works. He draws parallels between the Army’s changing approach to leadership in the years following the Second World War and agile software development in industry. A topic I found especially interesting was his description of the introduction to the British Army of the Mission Command philosophy: > … this is an approach which empowers subordinate commanders and promotes initiative as well as freedom and speed of action. Critically, it focuses on achievement of higher intent through mission-type orders. It empowers leaders at every level and is intended to generate agility and tempo. > > The goals of this approach — agility and tempo — are exactly the same goals that many software teams strive for, and, as in software, this approach has been hard won through experience and situational requirements. detail scale In the years following the Second World War, the conflicts in which the British Army has been engaged have changed notably. Rather than fighting wars against nation-states, the British Army has increasingly been involved in non-standard engagements such as counter-insurgency and peace-keeping operations, examples of which include conflicts in Northern Ireland, Iraq and Afghanistan. One of the common themes of these engagements has been the tendency for situations on the ground to escalate rapidly and without warning, and often to just as quickly dissipate. This rapid change in the situation on the ground has meant it is rarely practical or even possible for communications to be sent back to senior commanders and for orders to be relayed quickly enough to keep up with changes. Ultimately, this means that junior leaders are often left to make critical leadership decisions under their own initiative as the situation evolves. This has led to a change in leadership style overall, moving away from commanders keeping tight control over the execution of a plan and towards an approach where commanders instead lay out the mission and the boundaries to operate within, leaving the implementation up to more junior leaders. This approach gives those junior leaders the flexibility and freedom to make decisions as they see fit within the confines of the parameters set out and in line with the mission, even contravening direct orders should they feel it necessary in the wider context of the mission. While the context is of course different, similar problems exist in software development. The requirement to facilitate quick decision-making in order to respond quickly and effectively to ever-evolving, and often ill-defined, situations has driven what we know today as agile development. Central to this approach is the need to empower leaders on the ground to make decisions based on the current situation without the need to involve senior management directly in each case and without fear of reprisal or reprimand for making autonomous decisions. Agile development is about moving quickly and responding to change, to do that effectively, leadership needs to support this goal. In the same way we struggle to be agile within rigid processes, we also struggle to be agile if the leaders at the top do not empower subordinates via delegation of command. #### Trust and Communication A crucial facet of this, in both military and civilian contexts, is trust. Leaders must trust their people — not blindly, but by setting out the intent and facilitating the mission, empowering them to make decisions and ask questions as needed. Followers, in turn, need confidence that their leaders are setting the right direction and that they will be given the freedom to make decisions and inevitably mistakes without blame. At a peer-to-peer level, team members must also trust each other to get the job done and to work in the best interests of the team. This deep and multi-layered application of trust can be challenging to build but is essential to a Mission Command style of leadership and also to an agile team. detail scale No conversation on teams, trust and leadership is complete without considering communication. Communication is, as in many areas, essential to this approach. A leader’s ability to enable a Mission Command style of leadership requires clear lines of communication both up and down the chain of command: > [Leaders] are expected to work within the intent of superiors at least two levels above them, and to ensure their directions are resourced and understood at least two levels below. > > For a team to function efficiently, it is just as important in software that senior stakeholders are aware of the direction and goals of a team at a high level as it is for the more junior developers to understand what the aims of a project or sprint are in a larger context than the particular piece of work they are currently developing. Stakeholders need to know where a project is heading and to trust that direction is aligned with their intent. Where stakeholders are kept out of the loop it causes tensions and loss of trust meaning stakeholders feel the need to take a tighter control and restrict the teams freedoms to act independently. It can also waste time if the project drifts significantly away from the intended direction and needs work to bring it back in-line or even to undo changes that have been made entirely. At the other end, team members cannot make good decisions when faced with problems or choices in their work without an understanding of the wider context. If intent is not propagated down the chain, individuals are discouraged from making independent decisions and more likely to routinely run any decisions they encounter through those above them, this in turn encourages a culture where leaders are used to being directly involved in every decision and can cripple the overall goals of mission command style leadership and agility in general. #### Final thoughts Rather than being separate concerns, I believe that leadership and agility are fundamentally intertwined. Leadership may be a broader discipline than agility, but agility itself depends upon effective leadership. It is enabled by it, shaped by it, and I would go as far as to say that it cannot truly exist without it. An agile team is not simply one that follows agile practices, but a team that has an agile mindset and way of working which is ultimately enabled by leadership. The Mission Command approach is an example of what this looks like in practice: leaders communicate intent, establish clear boundaries, and trust those closest to the work to make decisions in pursuit of the wider mission. The same principle applies in software development. Teams become more adaptable, responsive and effective when leaders create an environment built on trust, delegation and shared understanding, rather than control. If agility is the goal, then leadership is not merely a supporting factor; it is the foundation that makes it possible. Hi, I'm Dave, a Lead Developer here at Scott Logic, based in Edinburgh. I have particular interests in cloud computing, frontend frameworks and agile development. Outside of software I enjoy Jazz, Star Trek and single malt whiskeys, not necessarily in that order., Agile Leadership, blog.scottlogic.com, 01kzp1fgrawrv8hz3wjxsp9qxj.