Many organizations won’t survive the next decade. Of those that survive, even they are likely to be extinct before century’s end — especially the largest of contemporary organizations.
I was thinking today of a few essential adaptations that enterprises must make immediately in order to stave off their own almost-inevitable death.
With Regard to Business Strategy
Measure value delivered and make decisions empirically based on those data.
Strive toward a single profit-and-loss statement. Understand which value streams contribute to profit, yes, but minimize fine-grained inspection of cost.
Direct-to-consumer, small-batch delivery is winning. It will continue to win.
With Regard to People
Heed Conway’s Law. Understand that patterns of communication between workers directly effect the design and structure of their results. Organize staff flexibly and in a way which resembles future states or ‘desired next-states’ so those people produce the future or desired next-architectures. This implies that functional business units and structures based on shared services must be disassembled; instead, organize people around products and then finance the work as long-term initiatives instead of finite projects.
Distribute all decision-making to people closest to the market and assess their effectiveness by their results; ensure they interact directly with end users and measure (primarily) trailing indicators of value delivered. Influence decision-making with guiding principles, not policies.
The words ‘manager’ and ‘management’ are derogatory terms and not to be used anymore.
Teams are the performance unit, not individuals. Get over it.
With Regard to Technology
Technical excellence must be known by all to be the enabler of agility.
Technical excellence cannot be purchased — it is an aspect of organizational culture.
For example, in the realm of software delivery, extremely high levels of quality are found in organizations with the shortest median times-to-market and the most code deployments per minute. The topic of Continuous Delivery is so important currently because reports show a direct correlation between (a) the frequency of deployment and (b) quality.
That is, as teams learn to deploy more frequently, their time-to-market (lead time), recovery rates, and success rates all change for the better — dramatically!
I have a theory which is exemplified in the following graph.
Sabine’s Principle of Cumulative Quality Advantage Explained
As the intervals between deployments decrease (blue/descending line)
…quality increases (gold/ascending line)
…and the amount & cost of technical debt decreases (red area)
OpenAgile is similar to Scrum in many respects. Both are systems for delivering value to stakeholders. Both are agile methods. Both are frameworks that deliberately avoid giving all the answers. So why would we choose OpenAgile over Scrum?
The most important difference is in applicability: Scrum is designed to help organizations optimize new software product development, whereas OpenAgile is designed to help anyone learn to deliver value effectively.
OpenAgile is an improvement over Scrum in the following ways:
More effective teamwork and team practices, in particular the Consultative Method of Decision Making, and
applicability over a larger range of team sizes from a single individual on up.
Recognition of the individual capacities required for effective learning, namely Truthfulness, Detachment,
Search, Love and Courage. Scrum acknowledges a separate set of qualities, but does not show how they systematically connect with the requirements of a Scrum environment.
Systematic handling of more types of work beyond just “new artifacts” and “obstacles”. In particular, OpenAgile includes calendar items, repetitive items and quality items and acknowledges their unique qualities in a work
environment. OpenAgile also provides a framework to include additional types of work beyond these five.
Improved role definitions based on extensive experience.
There is only one role defined in OpenAgile (Team Member) vs. three defined in Scrum (Team Member, ScrumMaster, Product Owner).
There are multiple paths of service that allow Team Members and Stakeholders to engage with an OpenAgile team or community in different ways. There are five paths of service: Process Facilitation, Growth Facilitation, Tutoring, Mentoring, and Catalyst.
The Process Facilitator path of service is similar to the ScrumMaster role with the following major differences:
is not responsible for team development
is not necessarily a single person, nor is it a required role
The Growth Facilitator path of service is similar to the Product Owner role with the following major differences:
is responsible for all aspects of growth including value (like the Product Owner), and individual and team capacity building.
is not necessarily a single person, nor is it a required role
Integration of principles and practices from other methods. Two examples suffice:
From Crystal: creating a safe work/learning environment.
From Lean: build quality in, value stream mapping, root cause analysis, standard work.
OpenAgile allows interruptions during the Cycle. Scrum has the concept of Sprint Safety. This makes Scrum
unsuitable for operational work and general management.
The distinction between Commitment Velocity and other uses of the term “velocity” used in Scrum. Commitment Velocity is the historical minimum slope of a team’s Cycle burndown charts and determines how much work a team plans in its Engagement Meeting.
Flexibility in the length a Cycle. Scrum requires that Sprints (Cycles) be one month in duration or less.
OpenAgile allows a Cycle to be longer than that and instead provides a guideline that there should be a minimum number of Cycles planned in the time expected to reach the overall goal.
The Progress Meeting in OpenAgile does not require people to take turns or directly answer specific questions.
Avoiding conflict-oriented models of staff and management (Chickens and Pigs in Scrum).
Terminology changes to be more clear in meaning and applicable beyond software. A comparative glossary is
Another major difference between OpenAgile and Scrum is how the community operates. OpenAgile is an open-source
method that has a specific structure for community involvement that allows for continuous improvement of the system. Scrum is closed. It is closely managed by it’s founders and this has led to challenges with the method becoming dogmatic. OpenAgile is meant to constantly evolve and grow.