Business Agility in the Age of AI

Do you think that Agile is a fad created only to sell books and courses? Well, you are terribly wrong. Agile principles heavily rely on science. During more than a decade of teaching Agile, I noticed that pointing to the bonds between science and Agile makes people more convinced. So, here go my favorite ten:

1. Complex Adaptive Systems (CAS)

CAS are systems that can learn and adapt to their environments. They are composed of multiple elements that interact with each other, leading to emergent behavior and self-organization. These systems are complex, meaning their future states cannot be predicted precisely.

An example would be a colony of ants. Each ant individually follows simple rules, but collectively, they create complex behavior like finding the shortest path to food.

Agile teams work like a CAS. Just like ants in a colony, team members interact, learn, adapt, and self-organize to solve complex problems. They follow Agile values and principles, but the ways they implement them can lead to unique, emergent practices that suit their context. They frequently inspect and adapt, improving their work processes and solutions, just like ants continuously adapt to find the best route to food.

2. Theory of Constraints

The Theory of Constraints, developed by Eliyahu M. Goldratt, posits that any manageable system is limited by a small number of constraints. Imagine a water hose. The amount of water that can flow through it is limited by its narrowest part. By widening this part, you can increase the water flow.

In Agile, particularly in Kanban, this theory is applied to workflow management. The team identifies the ‘bottleneck’ (the narrowest part of the hose) in their process where work gets piled up, and they focus on resolving that constraint to improve the overall workflow. The idea is to improve flow efficiency and thereby increase the value delivery, just like increasing the water flow in the hose.

3. PDCA cycle

The Plan-Do-Check-Act (PDCA) cycle, proposed by W. Edwards Deming, is a four-step model for continuous improvement. It’s like baking a cake for the first time. You plan the recipe, bake the cake (do), check if it’s tasty and properly cooked, and then act by tweaking the recipe based on the result before baking again.

In Scrum, PDCA is embodied in the inspect-and-adapt loops (Sprint Review and Retrospective). The team plans work for a Sprint, does (implements) the work, checks (reviews) the work’s outcome, and then acts (adapts) by planning the next Sprint’s work based on what they learned, just like improving the cake recipe.

4. Brooks’s Law

Brooks’s Law, named after Fred Brooks, author of “The Mythical Man-Month”, states that “adding manpower to a late software project makes it later.” It’s like trying to cook a meal faster by having more cooks in a small kitchen. Too many cooks will just get in each other’s way and slow down the cooking process.

In Agile, this law supports the idea of small, stable teams. Agile teams avoid “too many cooks” by maintaining a manageable team size, reducing communication overhead, and avoiding delays from onboarding new members. The idea is to optimize the existing team’s performance, similar to how one or two skilled cooks can efficiently prepare a meal in a kitchen.

5. Pareto Principle

The Pareto Principle, also known as the 80/20 rule, states that 80% of effects often come from 20% of causes. For instance, at a school fair, 80% of the donations might come from 20% of the visitors.

In Scrum, this principle guides backlog refinement and prioritization. Teams focus on the high-value tasks (the top 20%) that will yield the majority (80%) of the benefits, like focusing on those top donors at a school fair to maximize total donations.

6. Little’s Law

Little’s Law, from queueing theory, states that the average number of items within a system equals the average arrival rate of items into and out of the system multiplied by the average amount of time an item spends in the system

Consider a car wash service. The average number of cars being washed equals the average rate at which cars arrive multiplied by the average time how long each car spends being washed.

In Kanban, Little’s Law is applied through Work in Progress (WIP) limits. WIP limits control the number of items in the system, like limiting the number of people on a ride. If the WIP limit is too high (too many people on the ride), work piles up and things slow down, creating queues and longer cycle times. If the WIP limit is too low (too few people on the ride), there’s underutilization. So, teams find the right WIP limit to balance capacity and demand, ensuring a smooth flow of work, like having just the right number of people on a ride to keep it fun and efficient.

7. Weber-Fechner Law

The Weber-Fechner Law, in psychophysics, states that the perceived change in a stimulus is proportional to the initial intensity of the stimulus. For example, if you’re holding one pencil, adding another one will feel noticeable. But if you’re holding 20 pencils, adding one more won’t feel as different.

This law is applied in Agile estimation techniques, such as story points. Teams give relative sizes to user stories based on complexity. A story that’s assigned two points should feel twice as complex as a one-point story. The same goes for a story that’s ten points; it should feel five times as complex as a two-point story, just like the difference in the weight of pencils.

8. Parkinson’s Law

Parkinson’s Law, coined by Cyril Northcote Parkinson, states that “work expands so as to fill the time available for its completion.” If a child is given a week to clean their room, they will likely take the entire week to do it.

Agile addresses this by using time-boxing, where work is constrained to a fixed time interval (like a two-week Sprint in Scrum). This encourages focus and efficiency, helps manage scope, and provides predictability, as teams commit to completing certain work in a given timeframe, similar to asking the child to clean their room in one day instead of a week.

9. Servant Leadership

Servant Leadership, proposed by Robert K. Greenleaf, suggests that the leader’s primary role is to serve others. It’s like a teacher who focuses on students’ growth and development, prioritizing their needs and fostering a supportive, inclusive environment.

In Agile, especially Scrum, the Scrum Master embodies this role. They serve the team by removing impediments, facilitating processes, and helping the team become self-organizing, which leads to more productivity and engagement, just like a teacher focusing on students’ success.

10. Tuckman’s Stages of Group Development

Psychologist Bruce Tuckman proposed that teams go through stages of Forming, Storming, Norming, and Performing. It’s like a music band coming together. Initially, they’re polite but unsure (forming), then they may argue over music styles or roles (storming), next they find their groove and play well together (norming), and eventually, they perform in harmony (performing).

Agile teams often follow Tuckman’s stages. Understanding these stages helps Agile teams navigate team dynamics. It’s common practice in Agile to keep teams stable, as frequent changes can reset the team’s development back to the forming stage. This would be like changing band members often — the band would keep going back to figuring out how to play together. So, just like a stable band that stays together performs better over time, Agile teams also perform better when they are stable and allowed to progress through the stages of development together.

Use these to convince yourself. Or others.