Principia - meaning “collection of principles” was first used by Sir Isaac Newton in 1687 (one of the great heroes of the Enlightenment) as the title for his treatise on fundamental mathematics and physics.
Before We Start – a Quick Preamble
This blog may be viewed as a little controversial by some within the Agile community. However, my intent is simply to challenge some of the established norms, and maybe in doing so, rattle the proverbial cage a little. At the end of the day, and in the spirit of experimentation, this piece is meant to be a playful exploration of alternatives to the status quo. Hopefully, this will lead to a fresh perspective and stimulate some new dialogue on a somewhat stale subject - Process.
The Myth Surrounding Agile Documentation
Historically, during the great push for improved quality systems a couple of decades back, many organizations were guilty of over-engineering their documented processes. This resulted in bloated quality system binders that everyone ignored or tried to circumvent. Many of us (who have been around long enough) were left with some bruises, battle scars, and a bitter taste in our mouths.
Conventional wisdom asserts that documented process is anathema to Agile because it has the potential to:
- Inhibit innovation
- Lead to “mechanical” Agile practices
- Stifle self-organization and individual initiative
- Promote bureaucracy and red tape
- Perpetuate siloed organizational roles and mentality
Essentially, each of these prejudices against the old way of “doing” process have some legitimacy. But the common thread for each of them is the plain and simple fact that over-engineered process is typically a self-inflicted syndrome.
Agile and Documentation: It’s a Love/Hate Thing
When the Agile movement was in its infancy, our thought leaders sought to encapsulate the key elements of what it meant to aspire to true Agility within the “Agile Manifesto.” Elegant in its simplicity, this document codified the essence of what it means to be Agile in very succinct terms. Apart from some anachronistic language (it is a bit too software-centric), the intent of the document has generally stood the test of time.
The manifesto consists of four key values and twelve supporting principles. One of the key values of the manifesto emphasizes the importance of favoring:
“Individuals and interactions over processes and tools”
This is clearly an admirable goal that makes complete sense in most scenarios. But, like the other values and principles, it’s important to remind ourselves that the statement is clearly intended to be interpreted based upon local context, and not applied verbatim as a fixed and literal rule. In other words, this value statement seeks to ensure that there is an emphasis on the way we work – it is not looking to impose a constraint that seeks to eliminate process entirely.
Getting Started: Why You Need an Agile Playbook
For any intermediate, or large scale, organizational transformation to be successful, it has long been recognized that a model-based approach is better than a totally open and organic approach to process. Such a “free for all” will likely result in a chaotic set of practices and roles, which are open to the interpretive whims of each of the constituencies involved. Organizations that attempt process improvement without a model are also prone to “reinventing the wheel.” Currently, the need for a model is typically filled by a raft of Agile frameworks and methods that are adapted and tailored to local needs. On top of that, they can also provide the basis for assessing and measuring progress, and thereby act as a source of data for ongoing development of the Agile Roadmap.
In addition, we need a basis for driving relentless improvement. If used wisely (by ensuring that everyone has a voice in shaping those improvements) the playbook can provide a solid process foundation that supports cultural institutionalization and shared ownership.
Furthermore, many organizations are constrained by requirements to demonstrate alignment, or compliance, with internal/external regulations, policies, or standards. A playbook can provide an effective vehicle to proactively map specific practices and organizational roles to adhere to compliance requirements. This might be taken even further by also mapping local processes to the organization’s adopted Agile framework/method to ensure continued alignment with the target model. This may all culminate in a process environment that has significantly more chance of being relied upon by an auditing/compliance function than an ad hoc localized Working Agreement solution.
Ultimately then, we simply need a common frame of reference that is flexible, yet provides us with guide rails around what constitutes acceptable Agile processes. That way, when it comes to project execution and delivery, everyone will be speaking the same language, and singing from the same set of lyrics.
Now that we’ve addressed some of the key foundational principles, in part two, we will explore the precursors to successfully implementing a playbook… Please stay tuned!
You can also see where you are on the path to organizational agility with our Enterprise Agile Maturity Matrix, and learn more about Eliassen Group's approach to Agile consulting.
