WHY DO ALL DEVELOPMENT CYCLES LOOK SO SIMILAR?
WHY DO ALL DEVELOPMENT CYCLES LOOK SO SIMILAR

INTRODUCTION

The Agile world loves creating new models, diagrams, and cycles. Scrum has its own cycle of events, Lean Startup talks about Build-Measure-Learn, Lean UX uses Think-Make-Check, and Deming introduced PDSA. At first glance, these appear to be different approaches with different terminology and different areas of application. However, when we look at them more closely, we discover that they all describe a surprisingly similar idea. Whether we are developing software, designing a new product, improving a manufacturing process, or making tactical decisions, we always follow the same pattern:

  • we move a step forward,
  • check the real world response,
  • learn something and
  • adjust further action in the light of new information.

This pattern is significantly older than Scrum, Kanban, or any modern Agile framework. It represents one of the fundamental principles of operating successfully in complex and uncertain environments: Humans are not very good at predicting the future, so we must continuously test our plans in practice and adapt them whenever necessary.

In the following sections, we will examine the most well-known development cycles and show that behind their different names lie the same fundamental pattern and purpose.

DEVELOPMENT CYCLES

PDCA (Plan-Do-Check-Act)

The Shewhart Cycle, as a fundamental concept in quality management, is a systematic, iterative process designed to improve and control quality in a variety of organisational processes.

The basic principles of the PDCA cycle are based on four key phases:

  • Plan is about identifying a problem or an opportunity for improvement and developing a strategy to address it.
  • The purpose of the Do is to implement the Plan to the minimum extent necessary to verify its effectiveness.
  • Check: the results (Do) are measured and analysed to see if the solution is working as expected.
  • Act is action based on results. We decide either to standardise the validated (Check) strategy organisationally, or to return to the Plan phase for further improvements.

This cyclical process encourages continuous improvement and adaptability of organisational processes. The value of the PDCA process was recognised early on by Toyota, which implemented it in a minimally modified form as part of its Toyota Production System (TPS). The PDCA cycle manifests itself in at least two TPM loops:

  • Jidoka (Detect – Stop – Fix – Prevent recurrence)
  • Andon cord (Signal – Investigate – Resolve – Learn)
Razvojni cikli

PDSA (Plan-Do-Study-Act)

Deming’s PDSA cycle is the successor to PDCA. The difference between the two is largely semantic, but if we want to be precise, we could say that:

  • PDSA places greater emphasis on analysis (the Study phase) and understanding causality. This is intended to be more useful in environments where we want to avoid superficial analysis and generic solutions.
  • IPDCA Check phase is intended to measure concrete results before moving on to the next phase. It is therefore more execution-oriented.
Razvojni cikli

Lean Startup (Build-Measure-Learn)

The Build-Measure-Learn (BML) cycle is probably the most influential concept in modern product development, popularised by Eric Ries in his 2011 book The Lean Startup. The BML loop emphasises learning from collected data in order to develop better products. For product managers, following this approach is essential as it moves product success from the domain of guesswork into the domain of empirically validated hypotheses.

Razvojni cikli

Lean UX (Think-Make-Check)

Lean Startup is a business framework for figuring out what to develop in order to offer some useful value to the market. On the other hand, Lean UX is a design framework for figuring out how to realise the identified functionalities in the most user-friendly and functionally intuitive way.

  • Think phase is designed to define the problem, formulate assumptions, hypothesise solutions and better understand the users.
  • Make phase is designed to turn ideas into real solutions. This includes wireframes, low-fidelity (usually) prototypes and alternatives. The aim is to test as many hypotheses as possible in a short time.
  • In the Check phase, we test our hypotheses on real users. This can be done using qualitative methods (user testing, interviews, surveys) or quantitative methods (A/B testing, Wizard-Of-Oz prototype, Fake door prototype, in-app analytics, etc.).
Razvojni cikli

Design Thinking (Empathize-Define-Ideate-Prototype-Test)

This cycle has been developed independently of the Agile or Lean community. Design Thinking is a problem-solving approach that places particular emphasis on understanding users and their needs. Although it is often presented as a sequence of five steps, in practice it is an iterative process, where new insights can lead back to any previous phase.

The stages are:

  • Empathize is designed to understand users and their environment.
  • Define helps to formulate the problem we want to solve.
  • Ideate encourages the generation of different possible solutions.
  • Prototype turns ideas into tangible artefacts.
  • Test verifies solutions on real users.
Razvojni cikli

Scrum

Unlike many other Agile and Lean approaches, Scrum does not define its own development cycle. It has no equivalent of PDSA, Build-Measure-Learn or Think-Make-Check. Instead, it emphasizes empiricism, the pillars of which are Transparency, Inspection and Adaptation. Scrum puts these principles into practice in Sprint through events such as:

  • Sprint Planning
  • Daily Scrum
  • Sprint Review
  • Sprint Retrospective

Although Scrum does not name its cycle, the basic idea is the same as in other approaches: regularly checking the results of work and adjusting further development based on the information obtained.

Razvojni cikli

OODA loop (Observe-Orient-Decide-Act)

The OODA is a decision-making framework consisting of four phases:

  • Observe,
  • Orient,
  • Decide,
  • Act.

This iterative process was developed by military strategist John Boyd. By continuously cycling through these phases, the concept helps individuals and organisations make effective decisions in rapidly changing environments.

Due to its military origin, the use of the OODA loop is based on two assumptions.

  • The first is that there is always an opponent. In business, it is the competitor we are trying to overtake.
  • The second assumption is that speed is an advantage. If we make a good decision faster than our opponent, we are likely to win.

Many agile practitioners unknowingly use the OODA loop.

Razvojni cikli

SUMMARY

Let us group the described cycles according to the predominant fields of application:

  • Quality ⇒ PDCA/PDSA
  • Production ⇒ TPS
  • Software ⇒ Scrum
  • Startups ⇒ Lean Startup
  • UX ⇒ Lean UX
  • Product Design ⇒ Design Thinking
  • Military Strategy ⇒ OODA

Seven different fields, seven different terminologies, all arriving at practically the same learning loop:

Assumption – Action – Feedback – Learning – Adaptation

Only the terminology changes. It just depends on whether the focus is on quality, user experience (UX), product discovery, software development or organisational optimisation.

Whether one uses PDCA, PDSA, OODA… or any framework that has not yet been invented, the basic message of product cycles is the same:

  • We can’t know everything in advance (we are not clairvoyant).
  • Reality is a better teacher than plans.
  • Learning requires contact with real users, customers and environments.
  • Development must therefore proceed through a sequence of learning loops (iterations).
  • New information must be able to influence what we develop next (adaptation).

This is one of the reasons why many practitioners of Agile and Lean approaches become sceptical of methodologies that focus mainly on process mechanics and not enough on feedback processing (SAFe, RUP, PRINCE2).

Events, artefacts and role names may vary, but the underlying issue is always the same:

How quickly are we able to determine whether we are building the right product?

I do not think this article requires an explicit recommendation for development practice. Humans are bad at predicting the future, so successful systems are designed to learn from reality faster than their competitors.

Other Posts

AI integrator
Advanced approaches
admin

AI INTEGRATOR AS A TRANSITIONAL STRATEGIC ROLE

Continuing in the spirit of the previous article. AI has redistributed workloads within the development process. These have shifted from programming toward prototype verification. Companies are slowly adapting to this, but the process has proven to be much more complex

Article »
Agile - But still
Advanced approaches
admin

AGILE WORKS FOR US. BUT STILL…

INTRODUCTION This article is inspired by my own observations, a somewhat prophetic warning in the book The Lean Startup, and the confusion that artificial intelligence has brought to the development cycle. The article has two messages that are mutually independent

Article »
Tuckman model of team development
Working with the Team
admin

TUCKMAN’S TEAM DEVELOPMENT MODEL

Development teams are often expected to be effective “right out of the box.” Management: “After all, our they are all experts (and well-paid ones at that)!” It is often overlooked that development teams do not achieve working synergy overnight; rather,

Article »
Shopping Cart
Scroll to Top