1990–2010s: Agile Management in 5 minutes

This article continues the exploration of management methodologies begun in “1900–1980s: Classical Management in 5 minutes”, with a specific focus on Agile. We will briefly touch on several key Agile frameworks to highlight the fundamental concepts behind Agile methods, and the real novelty of them. Importantly, Agile is not an ultimate replacement for the Classical methods. Both Agile and Classical approaches have their own areas of applicability, using a method appropriate to your situation you will likely get better results. For instance, the superiority of Scrum over Lean, or vice versa, depends on the problem you are solving. But before getting into these differences, let’s start from the initial Agile concepts.

2001: Agile Manifesto

In 2001, a group of seventeen software developers gathered in Utah to discuss lightweight development methods. Their collective insights led to the creation of the Agile Manifesto, a concise set of priorities aimed at improving software development practices. This manifesto initiated a significant paradigm shift in the software development industry. It is worth to repeat them:

― Individuals and interactions over processes and tools.
― Working software over comprehensive documentation.
― Customer collaboration over contract negotiation.
― Responding to change over following a plan.

While these original Agile principles were transformative, understanding their essence and novelty can be challenging. They describe particular situations rather than introducing new ideas, and not all of the implied ideas were completely novel. But one of them definitely was.

The innovation that solely belongs to Agile can be distilled to the following concepts:

― Sense: Observe the situation to capture important inputs that might affect your work.

― Adapt: Upon receiving new inputs, adjust your goals, plans, processes, and other aspects of your work.

― Iterate: Repeat the Sense/Adapt cycle at fixed intervals or whenever the situation significantly changes.

Now, let’s explore how these concepts are applied in popular Agile frameworks, such as Scrum and OKRs.

1995: Scrum ― Ken Schwaber, Jeff Sutherland

Introduced in 1995 by Ken Schwaber and Jeff Sutherland, Scrum is an Agile framework that significantly transformed the landscape of team-level project management. The Scrum methodology introduced several practices that embody the Agile concepts of Sense, Adapt, and Iterate:

― Review and Retrospective: These two events represent the Sense concept. The Review aims to gather information from external stakeholders, while the Retrospective focuses on internal feedback from the team.

― Planning: This embodies the Adapt concept, as new information gathered during the Review and Retrospective is considered and incorporated here.

― Sprint: Representing the Iterate concept, a Sprint combines Review, Retrospective, Planning, and Execution into a fixed cadence.

Scrum embraces complexity of software projects. Instead of persisting in the futile attempt to plan complex projects in full detail from the start (a ‘waterfall’ approach), Scrum accepted the ever-changing nature of such projects and incorporated this reality into its methodology through the concept of Sprints.

While Scrum might have some flaws, it is indeed an effective framework for managing complex software projects within small teams. Now, let’s turn our attention to the opposite side and explore Objectives and Key Results, a framework designed for larger organisations.

1999: Objectives and Key Results (OKRs) ― Andrew Grove, John Doerr

The concept of OKRs originated at Intel, and was presented by Andrew Grove in his book “High Output Management” in 1983. This methodology was later brought to the broader tech industry by John Doerr in 1999, initially at Google, and subsequently globally.

Here is how OKRs reflect key agile concepts:

― Sense: OKRs inherently involve gathering information, as both Objectives and Key Results are metrics that provide insights.

― Adapt: OKRs accommodate changes, with objectives that can be discontinued if they become obsolete, and the outcomes of current OKRs influencing the next set.

― Iterate: OKRs are fundamentally an iterative method, typically following a cadence of a quarter and a year.

In the Agile landscape, Scrum and OKRs represent two ends of the spectrum, each effectively addressing the needs of small teams and large organisations, respectively. However, these two approaches do not naturally align, creating a gap between them. If an organisation applies OKRs at the top and utilizes multiple Scrum Teams at the bottom, these strategies won’t necessarily mesh seamlessly. This gap prompted exploration into methods of scaling Agile in the 2010s.

2010s: Attempts to Scale Agile

Throughout the 2010s, there were continuous efforts to bridge the gap between team-level management (Scrum, Kanban) and enterprise-wide management (OKRs). This led to the development of numerous frameworks such as Scrum of Scrums, Large-Scale Scrum (LeSS), Scaled Agile Framework (SAFe), Nexus, and many more.

However, it seems that history is repeating itself with these attempts to scale Agile, similar to past attempts to run complex projects with Waterfall-like methods, making the same fundamental mistake.

Waterfall methods make a fundamental assumption that projects are predictable and can be planned upfront with enough effort, analysis, and expertise. While this approach works for simple, repeatable projects like marketing campaigns, it falls short when applied to complex projects. This is because the fundamental assumption of predictability does not apply to complex projects.

Similarly, current attempts to scale Agile seem to be falling into the same trap. For instance, frameworks like SAFe rely heavily on comprehensive instructions (SAFe Distilled, 320 pages), extensive analysis, and deployment procedures performed by experts to roll out SAFe across an entire organisation at once. This approach, which is fundamentally based on the assumption that businesses are predictable and that their internal design can be planned and improved upfront, mirrors the fallacy of Waterfall methods.

In essence, many of the contemporary frameworks that attempt to scale Agile are turning out to be the Waterfalls of the 21st century.

Summary

The Agile methodology introduced a novel approach to management, centering on the embrace of complexity and the incorporation of the concepts of Sense, Adapt, and Iterate.

While Agile methods are newer than classical ones, they are not necessarily superior. In a predictable environment, classical methods like Lean can be more efficient. This is why many adaptations of Lean concepts have been adopted under the Agile umbrella, including Lean Software Development, Kanban, Lean Startup, and others.

However, current attempts to scale Agile are fundamentally flawed, as they are based on the wrong assumption that organisations (businesses) are inherently simple and their functioning can be analysed and planned in advance.

Instead of trying to apply an analyse (waterfall) approach to entire business organisations, we should embrace their inherent complexity and apply the Sense, Adapt, and Iterate concepts to the way we evolve business operations.

In essence, it is impossible to design a business upfront.

In conclusion, each environment requires a tailored approach: predictable environments thrive under classical methods like Lean, while complex environments benefit from Agile methods based on Sense, Adapt, and Iterate concepts. By applying the appropriate methods in the right environments, we can achieve optimal results. However, the landscape of management has one more element. There exists another category―unpredictable environments―which we will explore in the next article.