Corporate business agility - beyond scrum (Part 1 - Draft)

How to utilize Disciplined Agile to transform your organization.

How to develop corporate business agility and strength beyond scrum.

Agile Beyond Scrum


There is an ancestral dichotomy in business and in project management. It relates to the question how to determine work tasks and how to get them done. Whereas certain project contexts require pedantic specialized planning in advance, other ask for creativity and informal collaboration to incubate new ideas and products successfully.

Scientific management, developed by Frederick Winslow Taylor in 1911, pursued the idea to optimize each single manual movement to achieve highest efficiency. Implemented rigorously in the slaughterhouses of Chicago, this «Erfindung des Schlachtplans» («invention of the plan of action») led the foundation to modern project management. As all beefs have the same structure you can create and implement rigid standard operation procedures for all employees in advance.

This kind of anticipating project planning empowered people even to list and assemble all parts of a rocket to hover to the moon in 1969. Such «bill of materials» (abbreviated as BOM and also well known as «SAP Stücklisten») are still the solid backbone of industrial manufacturing processes and their controlling ERP-programs (Enterprise Resource Planning Programs like SAP). And they are used as Standard Numbering Systems, which embrace the whole documentation of an aircraft in a highly standardized way (cf. ATA iSpec, S1000D).

However, this successful rigidness faces an increasing open, decentralized, globalized and connected world, which is often described as VUCA, as volatile, uncertain, chaotic and ambiguity – a term which was brought up first in the military context. Top management loses its power for control and the command chain whereas more and more erratic network influences ask for local and context related governance and reaction. Our environment unfolds from simple via complex to complicated and even to chaotic behavior.

Dave Snowden demonstrates with the Cynefin framework that we miss to catch up with reality if our concept about reality is too narrow. Reality might run through rigor methods like sand cripples through our fingers. The reason is, according to Ashby's law, that you need more intelligence (respectively variety) to control something than object, project or system you want to control.

In this case estimation, planning and reporting which guided us previously timely on track, lead to red tape and dead ends instead. Stepping up efforts through increasing the rigidness worsens the problem, as John Boyd revealed with adventurous references to Goedel, Heisenberg and the 2nd law of thermodynamics that we cannot escape this vicious circle because it's inherent to nature respectively to human beings.

We can see the effect of these insights in particular in large corporations, whose customer faced interfaces increase only linear where the internal mass and burden of internal organization grows exponentially (to paraphrase Peter Drucker), leading to failure of managerial rigidness and centralized heroic leadership approaches. We need more sophisticated frameworks for decision making (like Cynefin) and to collaborate and act effectively.

The human side

Already in 1960 Douglas McGregor emphasized the “Human side of enterprise”: Humans have ambitions and engage performant in their job, even if they are not continuously scrutinized. If you put your team under rigid control and strict observation, without authority to act, you might even undermine any common sense and work morale. The father of quality management, Edward William Deming proofed in 1982 with his legendary read beads experiment how this can degrade human moral and motivation.

The famous quote, attributed to Peter Drucker, «If you can’t measure it, you can’t improve it.» was put under severe pressure through the development of Linux. Linux was released first in 1991 without top-down planning, without organiz atonial force and strict governance. This proved that, tough rigid control and measurement is no cause or precondition of improvement and of growth. Instead things can emerge around a given goal even in distributed teams, where the participants are even strangers to each other!

One could paraphrase:

That you can measure it, does not ensure it grows.

The Linux development succeeded also on its own, i.e. without a legal, a research & development and without a marketing department: Can it be that we can even get rid of specialized departments, who move activities and tasks back and forth and countersink relevant information away in silos.

The agile manifesto

The Agile Manifesto, published in 2001, got to the heart of it:

Build projects around motivated individuals! Mixed teams instead of expert silos! Communication over Documentation! Interval triggered feedback from the customer by functionable results, instead of long delivery lists and late assembly of the parts!

In 2006 the same year Scrum was released as agile framework, initially developed for product development, was founded in 2006, offering education and certification options.

Scrum's triumphal march was breathtaking: First in it's originated software domain, then reaching out to project management in general. There is probably no serious software company in the world which does not utilize Scrum, often in combination with Kanban concepts, and no other company ogling to become more agile. Mixed interfunctional teams collaborating closely with the customer at a short heartbeat are the core of Scrum and it's power.

Agile works!

Though Jeff and J.J. Sutherland exaggerate when they describe Scrum as «The Art of Doing Twice the Work in Half the Time» Scrum is verifiably proven to increase productivity about 7 to 12% on average.

However, the same study reveals that attempts to scale this up to the whole company only resulted in productivity increases of 3 to 5%. A result which could easily be reduced to the heightened awareness the implementation of such a framework involves temporary.

The approaches to scale Scrum, however, failed to deliver the same convincing effect as Scrum did itself.

But how to scale?

There is no lack of elaborated concepts to scale agile like «SAFe».

Already a first glance at the graphical conceptual overview – with all the levels, hierarchies and feedback loops – reminds one exactly of conventional organizational efforts and well-known red tape in huge corporations.

From an organizational design viewpoint, one could simply install a traditional portfolio and program management layer and get a similar structure. Or the approach aims to be more minimalistic, like «LeSS», but cannot quieten the question whether it really does make sense to use Scrum exclusively throughout an organization:

  • Is Scrum really the hammer to all nails we have in each organizational context and business situation?
  • Does it, in all contexts, really make sense to wait for the end of a sprint before releasing an artefact?
  • Wouldn't it be beneficial to have a certain predefined order, when building a house and casting the foundation?
  • Wouldn't it be soothing to take hard architectural or compliance regulated requirements intro consideration upfront instead of risking to delay them, because they cannot be made visible to the customer so easily as the surfaces?
  • How would it feel if the team can choose its own way of collaboration and coworking and omit a daily and disturbing standup meeting?
  • Wouldn't it be nice to have the complete end-to-end course of operations in mind instead of hovering from one to the next sprint and review what has been achieved so far in retrospect only?

Tool triggered agile?

Many organizations shyd away from introducing agile seriously and simply deployed cool collaboration software to get into the “agile groove” – without the procedural hassles.

This boosted the product line of companies like Atlassian (maker of Jira, Confluence, Trello, Bitbucket, et cetera) and brought the benefits of agile indirectly in many contexts which otherwise would not have been able to discover it. Despite these benefits it also enforces work organization in a way which might not neatly fit the contextual demands given.

Many companies also mixed up agile with “introducing these fancy software packages to each workplace” and turned the concept upside down while sticking with established policies. The same applies when teams and employees are forced to change their communication channels cogently and to use alternate software tools instead of establishing optimized ways of work with the affected team members.

Martin Fowler, an expert for agile software development, has described this as “Agile in name only” (AINO), another appropriate term is “Lipstick agile”.

How can we introduce sustainable business agility in corporations?

As Paul Graham notes, if you are a creative maker digging deep into your concepts and details which longer periods of time, a single meeting can affect the whole day, even if it's an agile standup. The same way an annoying «agile» software package does not cogently make your team productive, even it's often used in agile contexts.

How can we overcome these nagging limitations of agile and of Scrum in corporate environments? How can we make several teams productive, each with its own profile and it's specific goals and customer requirements? How can we build an agile organization without getting trapped by agile bureaucracy?

Disciplined Agile is a possible and powerful answer I will introduce in the next part of this series.