The Agile organizations: Eighteen years ago, the software community revolutionized the world of work with an idea of being… Agile.
As the philosophy and ideology has unfolded, expanding its influence and reach, we see how the Manifesto guides and shapes Agile organizations future well beyond software development.
How can the priorities set forth in the Agile Manifesto translate across functions, roles, and industries to benefit the world? In episode I we explored the first tenet prioritizing individuals and interactions over processes and tools, here we discover the priorities set forth in the second:
“Working Software over Comprehensive Documentation.”
Any software developer (and her or his customers!) can understand the value of this statement to the letter of the law. As we think about unleashing the Agile organizations truth to the world, we focus on the spirit of the law. Abiding by the spirit of the law is about living up to its intent and purpose.
Let’s explore!
“User-centric Goods or Services over Comprehensive Documentation.”
For the sake of our work, take “working software” to mean “user-centric goods or services.” This helps us see the foundational intent and purpose beneath this priority, apply this principle to ANY gemba, and demonstrate how
An Agile flow of value undercuts bureaucracy and prioritizes fluidity that is necessary in a dynamic reality.
Then:
Consider the merits and demerits of comprehensive documentation.
First- what do we mean by documentation? Whether you are in software development or hard goods manufacturing, there are, more or less:
Customer needs, requirements, and limitations.
Internal work guidelines, policies and standards.
Industry or regulatory standards.
Transactional agreements.
Why? Why do we use documentation?
Instructions/ guidance
Context troubleshooting
Tracking
Knowledge transfer
The notion of having a set of “instructions” is a contingency to guide your work so that when you are inevitably working in isolation, disconnected from the user (customer) or supplier and maybe even the team, you have some notion of what is needed.
The number of different projects and/or complexity of components may seem to necessitate detailed specifications and drawings. I wonder if the level of “comprehensiveness” needed is in equal measure to the distance in time, space and understanding from one another and the customer/ user.
The guidance offered by the manifesto is not to dismiss comprehensive documentation, but to subordinate it to the value of working software (or in our view, ‘user-centric goods and services’).
When we emphasize the value of individuals and interactions over processes and tools, the interactions (not the processes or documentation) for the purpose of delivering user-centric goods or services then guide the way.
By way of example,
here’s a recent situation with one of my customers:
We were in an OKR weekly alignment at Gemba with the self-organized team called “COMPASSers”. COMPASSers shared Objectives and Key Results documentation with a second self-organized team called “DELIVERers”.
At the gemba, COMPASSers were complaining about how DELIVERers were incapable of following the guidelines and instructions prepared for them to make fast and effective customer tests before deployment. Simultaneously, DELIVERers blamed the bureaucratic documentation requirements from the COMPASSers for delays in getting the testing done.
Seeing the discrepancy, leadership sent a message out via Slack to both teams after the huddle:
The following week at Gemba again, the CEO met with the DELIVERers first, and was delighted to see COMPASSers’ members involved there too!
After hearing the report, and before she could even ask about any obstacles where she could help, the DELIVERers preempted, “NO help needed, we DELIVERers and COMPASSers are very happy about it.” Seeing the change of heart from the week prior, the CEO asked:
— “Why?”
The cross-functional team’s response: “Because our collaboration is working really well making us capable to perform customer tests in half the time with 100% confidence in the results.”
— “Why?”
“Because we sat together to understand what we needed from each other.”
—“Why?”
“Because we realized that we were basing our collaboration before on a bunch of papers and documents.”
—“Why?”
“Because we put comprehensive documentation over interactions with a user-centric mindset.”
—“Why?”
“Because we forgot that when we prioritize processes, instructions, and procedures over our genuine and human interactions, we and the end-user always lose.”
To make Agile really agile:
There is agile, the word (able to move quickly and easily) and Agile, the philosophy:
Continuous Delivery and Continuous Deployment is the challenge to make Agile really agile.
The essential idea has nothing to do with shortening cycle times, but with changing the development process so that “user-centric goods or services” are not the output of a series of independent and sequential phases of development. Instead, functionality develops every step of the way so that every touch adds value and improves the state of the deliverable in an iterative way.
The product is not launched continuously, but all progress is developed such that it could be delivered and functional at any time with very little extra effort.
Flow in value creation becomes a reality when synchronizing all the functions within a team, making continuous delivery possible.
Instead of having people focused on solving continuous problems in production, everyone on the team is focused on finding the work system that allows continuous delivery.
Let me give you another example:
outside of software development that depicts a team practicing this discipline of prioritizing {user-centric good and services} over comprehensive documentation, flowing practical value in 20 minutes when it previously took +20 days.
This example is set in the front end of a manufacturing facility during order intake. The scope includes order entry and processing through planning, proofing to delivery of a work-order onto the shop floor for manufacture.
In this organization, the lead time for this process was typically a month, and depending upon complexity of the product, the order could receive input and some level of attention from up to 55 different people along the way.
Before experimentation:
Independent operations and operators, working in siloed departments, at various levels of system, product, and customer understanding, prioritizing work based on their own criteria, each with varying levels of backlog, no visual management nor feedback loops, working sequentially through the process, each step necessitating 2-4 comprehensive documents= average 11 documents in a complete job jacket.
- Order entry (1-2 days)
- Possible clarifications needed from customer
- Art proof (3-5 days)
- Possible kick-back to order entry with questions
- Customer for review (1-2 days)
- Possible “unapproved” for
- Complete order entry (2 days)
- (Possible reiteration of the above loop)
- Planning (3-5 days)
- Possible kick-back to proofing or order entry
- Scheduling (2-4 days)
- possible kick back to order entry
- Deliver to shop floor (typical lead time= 20 days)
Any possible questions that would arise during the proofing, planning or scheduling phase kicked the job out of queue and back to the service person’s desk where it would resurface for resolution, and then be routed back into the process, at the end of the line.
This seems extreme, but I’ve seen this model play out time and time again since then. No value could flow to the customer for at least 20 days until the entry process was complete.
After experimentation:
- Order entry, planning, art proofing happens concurrently, at the same time in the same place. Three team members work simultaneously on their operations to surface and resolve questions as a team, fully completing the work and flowing full value (an entered, planned, proofed job order) in twenty minutes.
This experimental team worked as one to face the problems inherent in the development of this work order with anticipation and solved them continuously. They did not accumulate the issues, pass them back and forth and correct them in hind-sight.
The value of this approach was not only a reduced lead-time to completion, but a transfer of knowledge and context that no static document could promise to achieve.
Agile organizations are about creating, together on time, in time and making sure that everything you create is ready to make the customer smile without the need of further inspection.
Our interpretation of Agile
Continuous Delivery offers the best interpretation of Agile organizations capable for wide-scale adoption. This approach accomplishes the powerful creative tension we see between Just-In-Time and Jidoka, learning from the wisdom of Toyota from practices built over 7 decades of incubation and iteration (since 1948 to present) developing TPS.
The work of departmental operations (QA, Operations, Sales) is not to review the comprehensive documentation or code that developers have created, but rather to actively shape and form a dynamic system so that team members can create product/ service (with self-checks or automated checks) that is always in a state ready to deliver and delight.
As my friend, partner, teacher and mentor David Hanna put it in 1988, while he was pioneering at Procter&Gamble the development of high-performance organizations based on self-sufficient teams:
‘High-Performance Organizations are characterized by structures that reinforce the qualities of living systems.’
David Hanna
Although, this seems natural, is not. Centuries of organizing work based on machine theory have influenced our thinking about how to divide work.
How to focus on Agile Performance
‘The principles of organizing living systems have been helpful to many high-performers by allowing them to harness the natural energy of their people against the tasks to be completed.’
David Hanna
Their focus of high-performers is on getting work done right in the first place rather than detecting or controlling errors after they have been made.
‘The high-performers have learned to design for results and self-sufficiency rather than for form and elaborate supervisory control.’
David Hanna
As David Hanna demonstrated to all of us already in the 80s, two decades before the agile manifesto was explicitly written:
The Agile organizations truth is about creating a 1to1 flow of value, and about letting the value creators work to form and develop the system and team needed to make the value flow in the simplest, most complete way possible.
Value creators in Agile include all skills and experience needed to get the product or service into the customers’ hands.
And this means, for instance, Product, QA, UX, Data, Brand, Legal, Sales, etc.
Allegiance to process orientation, working through a preconceived system to build the value sequentially step by step is an antiquated way that forces delays and reinforces the need for bureaucracy and ‘documentation.’
The examples of the power of teamwork, leveraging individual contributors fueled by a shared desire to output a fully ready finished product, versus a component or comprehensive documentation, is one way to unleash the power of this concept, beyond the technical application and understanding of today.
This approach,
To prioritize “products and services that make the customer instantly smile” over comprehensive documentation is valid for everything in agile organizations.
Because that’s pure Agile.
CONTACT OUR EXPERTS
Have a video call when it suits you best.
CONTACT
