Traditional vs Agile: why change?

For some time now, I have been leading introductory sessions on Agility, in which I focus particularly on the “why”: why agility? why do we want to change? Why do we use this practice? Comparing what is called the “Traditional Approach” to the “Agile Approach” has therefore become a recurring subject, which in my opinion is essential to a good understanding of the change caused.

It was when I had to support a colleague in her skills development that I decided to review my way of doing things. Indeed, even if the animation was mainly participative – thanks to the questioning – the fact remained that a large part was top-down, especially at the beginning of the training. I then wondered how, through a workshop, I could bring out from the participants all the information that I gave them on a plate before.

Here is the result 🙂

Instructions

After having formed sub-groups, I tell the participants that they will have a list of words, in which they will have to form pairs. The latter will have to oppose a word corresponding to the Traditional approach and the other the Agile approach.

Here is the proposed list of words:

• Predictive
• We
• Learning
• Plan
• Deployment
• Uncertainties
• Complicated
• We <-> Them
• Value
• Empirical
• certainties
• Complex

Note: Most of the time, I invite participants to note each word on a Post-it in order to be able to collaborate more effectively.

I insist on the fact that what matters is the arguments justifying the choice rather than the answer itself; we will see together why later. Between 10 and 15 minutes are generally sufficient to have a result in the teams. The idea is not to seek perfection, but to allow participants to think together in order to initiate discussions.

Debriefing

The debriefing takes place informally by going through the responses of the participants. Each team will justify their choices in relation to their understanding of the proposed words.

Note: Indeed, depending on the interpretation, a word can switch to one side or the other (while remaining completely coherent) which generates particularly interesting exchanges! 😉

I share with you below my answers as well as my elements of justification in the form: (T) Traditional Approach vs (A) Agile Approach.

I will also give you the arguments presented by the participants (P) when their results did not agree with mine! You will see that we are in agreement on the substance, it is simply our positioning that is different: while I place myself most of the time at the entrance, they can place themselves at the exit! 🙂

Predictive vs Empirical

(T) Predictive for Predictive approach

The Traditional approach is based on prediction. We also make a certain effort to make it as precise as possible: the most obvious example is the famous Gantt chart that takes weeks or even months to build and which turns out to be wrong as soon as the first days of implementation.

(A) Empirical for Empirical approach

The Agile approach is based on experimentation. As in the scientific approach, we start from hypotheses that we will check as we go along in order to accumulate reliable information from the field.

Deployment vs Learning

(T) Deployment for Deployment of methods

The principle of method deployment assumes that if it works in one team, doing the same thing in another will also produce the same result. We often speak of the " deployment of agility » in companies, as if it were a simple generic method to apply and replicate in teams, which turns out to be much more difficult in the field.

Indeed, what could be potentially applicable everywhere is the set of values and principles described in the Agile Manifesto. Now, that is not enough because each context is different, with specific constraints and challenges: the work of agile coaches is, in my opinion, essentially a work of contextualization.

The Agile approach is therefore both generic in spirit and specific in practice.

(A) Learning for Learning strategy

The implementation of experiments requires defining a strategy to validate our hypotheses. So going from a conditioned hypothesis (something we assume) to verified information (something we know) is learning!

Starting from hypotheses also implies that we accept to be wrong: the room for error is therefore essential!

(P) Participating Arguments

The term Deployment can be associated with the notion of Continuous Deployment dear to DevOps and Agility in general. The fact of deploying continuously makes it possible to have a concrete result, available to users, on which to quickly check their hypotheses, which is typically what you want to do in Agile.

The term Learning is sometimes described as the set of (static) learnings that we have acquired in the past and which lock us into a predictive thought model.

Certainties vs Uncertainties

(T) Certainties for Management of certainties

The Traditional approach being predictive assumes that it can know everything that is going to happen. It therefore starts from a set of certainties that only need to be implemented. It is therefore enough simply to deploy the necessary actions to achieve the result.

If we take the example of software projects, today it seems very difficult to be able to think of everything, especially when a large number of elements are interconnected and interdependent with each other. Thus, despite this impression of certainty, we only accumulate uncertainty, at the same time increasing the risk, until the final delivery.

(A) Uncertainties for Management of uncertainties

The Agile approach starts from the premise that we don't know everything and that what we think we know is only a hypothesis. By accepting uncertainty, we set up experiments to learn and to accumulate validated information that will become our certainties of the moment. This reduces the probability of unpleasant surprises and their impacts if they nevertheless occur.

(P) Participating Arguments

In Agile, we set up experiments in order to accumulate certainties. The objective is therefore to manage certainties to limit the risks and thus increase our chances of hitting the right target at the right time.

In Traditional, we believe we manage certainties but which are in fact only uncertainties. We therefore manage a number of uncertainties which at one time or another risk jeopardizing the project.

We <-> Them vs Us

To understand the change in thinking model brought about by Agility, you have to understand where you are starting from. I then describe the Traditional approach through the Cascade model then the V-Cycle, not always known to the participants.

(T) We <-> Them: Local Responsibility

The Cascade model comes from the building world where the roof is not built before the foundations. It is characterized by long stages, carried out sequentially and by teams that are usually specialized. The fundamental problem lies in the lack of responsiveness of the approach when there is a change or a problem because it has to go through all the steps again.

To reduce the impact of this problem in the IT world – where it is possible to build the roof before the foundations – the V-cycle has been implemented where the stages of the rising phase are placed next to the stages of the descending phase by faster feedbacks.

However, it did inherit the same characteristics as the waterfall model: long, sequential stages and specialized teams. The problem that arises is that the development phase can start a few months after the upstream specification phases, which means that knowledgeable people may already have committed to other projects or may simply have left.

There is therefore no choice: you must write down everything you know in an exhaustive manner to ensure that the information will be transmitted in the following phases! A little sympathy for the documentation therefore, it is an effect induced by the cycle in V! 😉

Now, what happens when a problem is detected, in the Test phase for example? What can testers say about the upstream phases? And the others ?

• " It's the fault of the developers, they provided poor quality code!" 
• " It's the fault of the specifiers, the documentation is imprecise!" 
• " It's the customer's fault, he doesn't know what he wants!" 

It's here finding the culprit : everyone is or feels responsible only for a specific phase of the project rather than what will be produced as a whole. So there is a “We” and a “Them”! 😛

(A) We: Global Responsibility

In Agile approach, we belong to the same team, we are focused on the same common goal. Even if we may have specialties and/or specific skills, our effort is continuous until the end of the project. Indeed, if there is a problem, it is that of the team as a whole and everyone is likely to bring a solution.

The responsibility is therefore common and shared between all the members of the team, which can contribute to having better quality interactions:

• more confidence because we know we can count on each other,
• more cooperation because we know that we are all going in the same direction,
• more commitment Because we'll be together from start to finish.

(P) Participating Arguments

In the interpretation of We <-> Them, by the presence of the two-way arrows, we can consider that the exchanges are going well outside our silo. We are then more attentive to the other parties in order to be able to achieve our common objective, which is rather Agile.

In the interpretation of We, we can believe that the focus remains locally, “at home”, rather than opening outwards and sharing our constraints and problems with others. It then looks more like Traditional.

Plan vs. Value

To explain this part, I go through the notion of the Iron Triangle, another version of the triangle (Quality, Cost, Time). It is characterized by 2 types of criteria: fixed and variable (or estimated).

(T) Plan for Plan Driven

In the Traditional approach, the requested content is fixed (“ I want it all!“). The people (Workload) and the time (Calendar) will then act as adjustment variables: people are added and/or the date is moved to be able to deliver all the content.

However, it sometimes happens that all these parameters are fixed: “ I want everything I asked for, on the given date, with the people scheduled“. And as we know that projects don't often go as planned, we still have to play on a variable to be able to meet demand. It is often the quality that then becomes the adjustment variable: Let's reduce the tests to deliver on the right date, at worst it will come back" 

The importance is therefore placed on the date, to the detriment of the quality of what is produced: we speak of piloting by plan.

(A) Value for Value Driven

Based on the previous observation, we understand why projects could tend to exceed their budget and deliver content that will not necessarily be used (cf. Chaos Report 1995).

It is therefore interesting to observe that the criteria that we allow to vary are those over which we have the least control: people may not be competent individually or collectively, they may fall ill... which will naturally impact the time of delivery of expected content.

Pragmatically, how can an unpredictable variable be made predictable? By fixing it! We then reverse the triangle by setting the workload and the schedule: “we have this number of people and this deadline”. And over what criteria did we have control from the start? The contents ! We can then allow ourselves to let it vary by optimizing the value of what will be produced: we are talking here about piloting by value.

In the Agile approach, we start from a basic premise: quality is non-negotiable. Thus, we prefer to deliver less (in quantity) but deliver well (in quality)!

Complicated vs Complex

This part is generally the one that closes the workshop. Indeed, it deserves some explanations especially in the terminology used: the terms " complicated " And " complex are sometimes used interchangeably or have a slightly different meaning to different people. It is nevertheless interesting to see that the term " complicated " tends to have a negative connotation unlike the term " complex“.

The objective of this part is mainly to describe where the Agile approach makes the most sense, to open the field of perspectives of the participants by showing them that there are different areas, each with their own characteristics.

To lay a common ground of understanding, I go through a model called the Cynefin Framework – on which I had already written a series of articles:

This model is particularly powerful because for each domain, it describes the recommended decision-making model. I will not go into the full description (if you are interested, I invite you to read This article) but would simply make the main messages explicit. We will see that this consistently incorporates all the characteristics seen previously.

Note: Other colleagues prefer to go through the Stacey matrix to describe the notions of "complex" and "complicated".

(T) Complicated

The domain Complicated is part of the family of ordered systems, that is to say that we know that a causal link exists between a trigger and its result, a need and a solution. The big difference with the domain Obvious is that this link is precisely not directly visible, so we need time to analyze the situation to determine it: hence the decision-making model described as Feel – Analyze – Respond.

The postulate that a causal link exists, that everything can therefore be controlled, typically corresponds to the traditional approach in its predictive nature, management of certainties and deployment of solutions. Indeed, in this area, we make a great effort to analyze the situation in order to be able to describe the ideal progress of our project: this therefore explains the major planning upstream.

Complicated etymologically means "linked together", "composed of several things". A complicated system is therefore a system that can be disassembled and reassembled in its initial state.

(A) Complex

The domain Complex is part of the family of unordered systems, meaning that there is no causal link between a trigger and its result, a need and a solution. If an event happens again, it can be considered a coincidence. It is therefore the domain of Test and Learn and experimentation hence the decision-making model described as Probe (we implement an experiment) - Feel (we observe what is happening) - Respond (we react according to the concordance of the results with our hypotheses).

The Agile approach is therefore ideal for problems in the complex domain due to its empirical nature, management of uncertainties and learning: this also explains the iterative and incremental components of this type of approach.

Complex etymologically means "intertwined", "intertwined". A complex system is therefore a system that is “impossible” to reproduce the original due to the multiplicity of interactions that make it up.

But then, Scrum is in the complex domain?

Well not quite! Let's analyze a little bit what happens in a Scrum process:

• Sprint planning : I'm hypothesizing what has the most value for my next Sprint, so my starting point is well in the field complex.
• Daily Scrum : every day, I make a decision on what I will achieve during the day in relation to my learning the day before, so I stay in the field complex.
• Sprint review : I collect my potentially deliverable product increment, I analyze it with all the stakeholders in order to determine what will be the next priority, in other words the next hypothesis. So I just switched to the complicated.
• Sprint retrospective : I base myself on the objective (results) and subjective (felt) data from the Sprint, I analyze the situation and decide on the improvement actions to be implemented with my team. I'm good in the business complicated.

Scrum is therefore a Complex-Complicated transition mechanism, described as one of the Cynefin cadences. This is why it is often said that what is important in Scrum is not synchronization but rather rhythm!

The Agile approach therefore brings a notion of permanent dynamism unlike the traditional approach which is intrinsically much more static. Maybe a new pair of words to test? 😉

Conclusion

This workshop allowed me to be able to lend a hand to the participants in the construction of content that came from them, while injecting theory into it as the discussions progressed. A participant told me that for this activity, I started from the premise that they were not starting from 0 and I think that is fundamentally true. We hear the term agile everywhere today and we also give it the meaning we want. The idea is therefore rather to align oneself with what we are talking about rather than to impose a static vision on the subject by leaving room for constructive and argued exchange.

Following this workshop, I hope that the participants will understand that there is a fundamental difference in the models of thought between the Traditional approach and the Agile approach, hence the difficulty of change in organizations.