Scripture does not convert; good works do. By inference: getting the broader organization to act with agility requires linking agile principles to routine behaviors and outcomes throughout the organization. Anything less than concrete language conveys a hypothetical doctrine that can’t be implemented practically at the organizational level, because it dwells in a philosophical silo. The 12 principles of agility can be summed up in a simpler, more encompassing rule: Do what works. To maintain the religious analogy, “Love is the whole of the law.”
To demonstrate that, however, we are required to demonstrate what works. That’s why any statement of overall principles can only expect general adoption when those principles are demonstrated in tangible ways. The Apostles of Christ demonstrated love by feeding the poor, comforting the sick, visiting prisoners, defending those without means, and sheltering refugees. The agile practitioner who wants buy-in outside of the IT ghetto, where agile principles have typically remained, must step off the dais and evangelize through deeds. Show the business case for agility by demonstrating how a change outside the IT domain produces a better result.
These are my meager attempt to articulate the operative principles of agility in an operational context that is agnostic regarding IT in particular and religiously skeptical of concepts that aren’t paired with specific applications, in general. I’m a non-believer. This is what it takes to convert me. I’m betting there are some other heretics and infidels who will get onboard if they can see (and only if they can see) what works.
- PRODUCT: Repeatedly take the shortest and earliest path to added value for stakeholders and end-users: Deliver value early and continuously. Satisfaction of constituents and clients stems from receiving smaller increments of working deliverables at regular intervals rather than waiting extended for extended time periods between large functional upgrades. Give stakeholders added value every quarter, rather than all the value at the end of the year—new features and deliverables at multiple touchpoints in the project, rather than all at the end.
- CHANGE: Accommodate changing requirements throughout any initiative: Leave sufficient fluidity in timeline, cost, scope, and deliverable features, so that modest changes do not completely or frequently disrupt progress. Have a process in place to take on pivots within a given initiative, whether originating with business stakeholders, end-users, or implementation professionals, without needing to always unroll, revisit, and meet about the entire plan, project, or campaign.
- PROGRESS: Progress continuously by small, functional increments: Prioritize frequent completion of smaller, working deliverables over larger ‘phases’ that include every desirable feature. Steady progress and motivation are rooted not in large overly-planned stages, but in many small successes that add tangible business value. In a continuously improving organization that is continually improving its product, “done” is every increment that yields business value, not a theoretical “done” after all increments have been delivered.
- COLLABORATION: Foster strong collaboration across departmental boundaries: Promote ownership and individual decision making power, but reject silos (‘stay in your lane, we’ll stay in ours’). Alignment improves quality, silos limit it. Create alignment between business and implementation (e.g. Sales, Product, Marketing) without imposing added hierarchy. Mutually create a common vernacular and shared narrative. Do not impose it from above or outside. By contrast: collaboration does not mean committee. Value is not improved by increasing the number of people involved, slowing or centralizing the decision-making process.
- LEADERSHIP: Define leadership as trusting, supporting, and motivating your people: Command and control, compulsion and the whip do not generate consistently high quality work. Demand an atmosphere of happiness, learning, intrinsic motivation, and mutual regard. Reject an environment typified by compulsion, blame, personal criticism, and interrogation. Begin with you.
- INTERACTIONS: Enable face to face interactions: Information transmitted through multiple channels of body language, facial expression, and visible signs of attention or confusion, improves shared understanding of concrete information like goals and outcomes, and makes collaboration more efficient. Asynchronous communications (like email or slack) and single-channel communications like voice-only conference calls can sustain simple, day to day interactions, but their effectiveness is inversely correlated to the complexity of objectives.
- MEASUREMENT: Measure progress as outcomes, not outputs: Theoretical progress isn’t progress. Measure action based on delivered outcomes that represent tangible value, not finished tasks that theoretically lead to it. “Won a contract” is a relevant outcome. “Sent a proposal” is just an output. All real progress is tangible, not theoretical. A “step” on the way somewhere did not generate value until you get there.
- PACE AND FLOW: Prioritize sustainable flow over death marches: Achievement of long-term goals requires continuous sustainable velocity. A periodic “balls to the wall” push only achieves short term goals faster at the expense of long-term achievement. Honor the law of constraints over push, exhaust, recover, push again. Prioritize constant production of results over getting everything you want in each incremental milestone. Minimize emergencies, ultimatums, and disruptions to sustainable workflow.
- STANDARDS: Pay attention to technical detail and design. Maintain objective standards for work quality: Adhering to the normative/agreed best practices of a given practice area ensures efficient delivery of work without having to re-invent or continually revisit the standards. Where there are multiple possible frameworks, communicate and reinforce the framework during on-boarding. It’s a form of courtesy to define expectations even with highly experienced professionals. Details matter: demand work integrity from oneself and encourage it in others. Standards are objective. Reject nebulous, unexpressed standards or ‘pleasing’ someone’s personality as a basis for work quality.
- REVISIONS: At every step, deliver minimum viable product: Routine over-delivery creates punctuated under-delivery in an inefficient cycle. Related to this: Shipped/delivered end results that decently approximate the goal beat perfecting a thing before release. Live testing beats speculative perfection. You can’t know if it’s right until you get feedback in a LIVE environment. Commitment to achievement is inversely correlated to commitment to perfection.
- DECISIONS: Encourage and support self-organizing teams: Inspire ownership, not dependency in decision making. Feedback means stating what you want, not what you don’t (criticism creates dependency). Communicate opportunity, not disappointment. Debrief over what you want more of, not less of. Empower people to take ownership not by telling them to own it, but by eliminating blame and replacing it with learning and encouragement. Requiring approval contradicts self-leadership. Requiring permission contradicts self-organization.
- IMPROVEMENT: Continuously improve with debriefs: Continuous improvement requires debriefs at regular intervals over ‘done’ items. They’re not done until you ask 2 questions: “What worked well? (What was good for you?) What could have been done better?”
Full deference to the wider agile community which has more experience than I do, and to the various frameworks, tools, and systems that remain useful but which we acknowledge are denominations within and/or commentaries upon agility as a practice.
I’ve no yearning to become an author of agile materials per se. I am certain one can write whole chapters of examples for each principle, on a sliding scale of conceptuality to specificity and likewise that it has probably been tried more than once. I am not, however, intending to create something with initial mass appeal. I think doing so may necessarily bias the content against that outcome. I merely intend to test ideas I think will be compelling in the circles in which I operate, and iterate improvements as I gain insights. The language and examples will likely evolve and, if some iteration becomes consistently useful, I am content with that.
Due acknowledgement that this is not the fulness of agility or agile practice, and some things have likely fallen through the cracks in reframing the principles, not the least of which is styling them as ‘commandments’. The latter, I do because “Do what works.” likely IS a commandment already instinctively followed by anyone who will find these useful, and so this piece is merely one exposition on doing what works better.
I have sometimes heard, “management doesn’t believe in agile” or that it pays “lip service” to agility (same thing). In other words, their faith is weak, superficial, or nonexistent. That may well be. But to conclude “management doesn’t want agile” or is “not committed” to it would be unwarranted absent proof by disregarding practical examples. And the responsibility for generating those practical examples lies entirely with us, by which I mean agile practitioners. I merely contend that we need to speak to domains other than our own, with examples other than the ones we use for ourselves, to increase adoption outside our own practice areas.
Finally, granting this may not be the ‘highest expression’ of agility, and with unqualified respect for the Agile Manifesto, I have answered the question (hopefully adequately), “Why go beyond the broad, general principles of agile?” with this article’s opening paragraphs—I have no purpose other than to promote adoption of agility in organizations I work with and on teams with which I collaborate. I think the best way I to begin to do so is create a brief ‘tractate’ for agility that I can use immediately in lobbying for better outcomes. If it doesn’t help, I’ll modify it or do something different.