Coder Legion - Recent posts tagged extreme-programming

It may not be Picasso, but it is Brunel

Tue, 31 Mar 2026 09:28:04 +0000

You want to paint a wall. The fastest way to start is to open the paint tin and start rolling out the color. Except that’s not the quickest way to paint a wall, as expert painters know. If you give a professional this job, they won’t touch the paint until the surface has been prepared.

This involves removing previous wall coverings, filling holes and divots in the wall, and carefully sanding to achieve a perfect surface. When you apply paint to a prepared wall, it goes on smoothly, it looks great when it dries, and you need fewer coats (we amateur painters tend to use additional coats in attempts to disguise all the problems we left when we didn’t prepare).

The preparation checklist:

Fill holes and cracks
Sand the walls
Clean the walls
Let the walls dry
Apply paint

You may need to add additional tasks to the list, such as removing mildew or priming the surface, if these are required in your expert judgment. This is the model professional decorators have refined over decades. It’s not glamorous, but it works.

So far, so good.

Enter the robot

No matter what you do for a living, someone wants you to do more of it in less time. In the software industry, we have scrummy marketing to blame for the overwhelming presence of demanding “twice the work in half the time.”

So what happens when we decide we want to paint faster? Someone buys a great big paint-spraying robot.

The paint-spraying robot is 10x faster than a human at painting. It can cover 100 square meters per hour, while a human can only do 10 square meters an hour. It completes projects 60% faster, and it can run 24/7, unlike those pesky humans who want to see their family and sleep. Of course, you need to input floor plans and designate non-paintable areas. Additionally, there’s a 20-minute setup time, as well as a 30-minute post-painting clean cycle.

Side panel: There are clues in the claims for the robot that tell us things are more complicated than they first appear. The robot is 10x faster, but projects complete only 2–3x faster. Something outside of blasting paint onto the wall is at play here. I’ve worked in enough organizations who purchase based on the 10x claim and then tripped and fell down the stairs of their own excitement.

Oh, and there’s one more thing. It doesn’t prepare your walls.
If you’ve ever painted walls without preparing them, you’re familiar with the kinds of problems it causes. The finish doesn’t look good, it’s not long-lasting, and your modern lighting turns the wall into a three-dimensional topology map of past picture hook holes. Over time an odd dark patch emerges. A reminder of the time little Lily missed her mouth with the Calpol and made an impromptu purple Rorschach test across the wall.

Painting, it turns out, is a complex process. We may long for a reality where painting is easy, but we live in one where it’s not.

Rediscovering the wheel, one bruise at a time

And that’s why the robot-first painting team is currently providing a fountain of incredible insights as they try to maximize their return on investment.

They’re discovering that asking people what color they want to paint their walls results in happier customers. An idea about setting windows to be non-paintable is emerging. Some bright spark has worked out that filling cracks before painting achieves a better end result.

Of course, they haven’t discovered everything on the simple checklist used by every professional decorator. It will take time for them to work it all out. It took professionals time to work it out in the first place, and these pioneers have decided to start from scratch instead of building on existing knowledge.

Eventually, they’ll have a pre-robot preparation checklist that looks something like the one we had in the first place:

Fill holes and cracks
Sand the walls
Clean the walls
Let the walls dry
Apply paint

We’ve seen this movie before

Of course, this isn’t about painting at all. It’s about software delivery.

We spent decades refining the best way to build software. It’s called Continuous Delivery. We have even expanded this into the DevOps model, which combines practices and capabilities that work well with Continuous Delivery, such as generative workplace culture, lean product management, and transformational leadership.

We literally have diagrams that show how all these things come together to improve software delivery. That’s right, “software delivery”. Not feature development time. Not coding speed. The whole darn thing.

And right now, I’m witnessing the most surreal déjà vu of my career.

Many people using AI are discovering Continuous Delivery practices through bruising experiences. The barrage of social posts from AI-first developers who are finding out from scratch why version control is a good idea, or why they ought to work in small batches with changes frequently integrated with the main branch, or why their builds shouldn’t take an hour.

It’s funny, while also being not at all funny.

In the 2000s, as I was first finding my way through Agile, Extreme Programming, and Lean, we drew on books and articles to inform our continuous improvement process. I worked on a team that ditched Scrum and developed a method that made sense for our work. We rapidly went from 6-month cycles to having always-shippable code, with a new version deploying every 3 hours or so.

Therefore, there’s a whole generation of lean/agile software developers for whom AI doesn’t provide a significant boost. To us, AI is just another tool, like auto-complete or a compiler. Helpful; not transformational.

We refined the elements of high-performance software delivery through numerous iterations and adjustments.

The paint dries on this one

Continuous Delivery remains the best-known way to deliver software.

A team using only Continuous Delivery will beat a team using only AI, because any benefit you get from AI will be lost to the first bottleneck it encounters on its way to production. Teams that start with Continuous Delivery will be more successful with AI, because they are already more successful than other teams. They have fast builds, automated deployment pipelines, and solid technical practices to enable the fast flow of work.

Essentially, AI has enabled low-performing development teams to experience some of the speed that comes with Continuous Delivery, but without the enabling practices. They’re getting paint on the wall, but they skipped all the prep work. So far, this hasn’t led them back to Continuous Delivery, but if they want to succeed, that’s where they need to start.

If you’re looking at seriously improving your productivity, it’s likely the answers that are proving so elusive with AI have been waiting for us all along in Continuous Delivery.

You can buy the robot if you want. Just don’t be surprised to find your windows painted over and your wall covered in lumps, bumps, and cat-shaped silhouettes.

Comparing Lean, Agile, and Continuous Delivery

Wed, 08 Oct 2025 14:46:30 +0000

With DevOps and Continuous Delivery gaining traction, are the principles behind Lean and Agile still relevant? How do they compare to the 5 Continuous Delivery principles, and what do any differences mean for software development teams?

The beginnings of lightweight software delivery

Throughout the 1990s, a revolution was brewing in the software development industry. The early phased models divided the delivery process into skill-based steps, with designs and documents used to run approval processes to control a project.

The process for delivering software was heavyweight and slow, with little indication that the overheads reduced the risks they tried to mitigate.

A collection of lightweight methods emerged, designed to generate fast feedback and iteratively adapt the plan based on new information. Rather than controls and approvals, developers used small batches to manage the risk and provide frequent opportunities to change direction.

The Agile Manifesto emerged from this adaptive and lightweight methods community in 2001, with Lean Software Development arriving a couple of years later.

Agile and Lean provided a values and principles based approach to software development. You could test whether an approach was Agile or Lean by testing it against a set of core statements defining each method’s philosophy.

Continuous Delivery emerged from the Lean and Agile communities, providing the most concrete practices and capabilities to achieve frequent and safe software delivery. Apart from Extreme Programming, most software development methods deal with requirements management and communication structures. Continuous Delivery takes on the rest of the value stream and provides a pathway to an efficient and reliable delivery pipeline.

InfoQ publishes an annual report on software development culture and methods. They style the report after Geoffrey Moore’s Crossing the Chasm concept. Moore famously visualizes a technology adoption lifecycle as a bell curve spread across 3 standard deviations.

The chart is divided into 5 groups with different attitudes to new technology:

Innovators (-3)
Early adopters (-2)
Early majority (-1)
Late majority (+1)
Laggards (+3)

The early majority and late majority represent two-thirds of the adoption lifecycle. Still, for new technology (or, in the case of InfoQ, a new idea) to move into the majority, it must cross the chasm from the early adopters to the mainstream majorities.

Source: InfoQ Software Development Culture and Methods 2022

While adaptive modes of software delivery are embedded in the late majority, the capabilities needed for continuous modes of delivery are still making their way across the chasm. Some practices (such as DevSecOps) have made the leap, while other key elements, like team topologies and empowered teams, remain at the early adopter stage.

So, with DevOps and Continuous Delivery gaining traction, it’s a great time to compare the 5 principles of Continuous Delivery with the 12 Agile principles and the 7 Lean principles.

Comparing Agile, Lean, and Continuous Delivery principles

Agile, Lean, and Continuous Delivery each provide a set of principles. This helps us compare their fundamental structures.

There are other techniques and capabilities in Lean and Continuous Delivery that don’t have comparable elements in Agile. The Agile Manifesto was intended to be a broad litmus test of the agility of other specific methods, such as Extreme Programming, Scrum, and Disciplined Agile, so it didn’t define further details.

Lean expands on its principles by describing techniques covering the whole software development process with advice on planning, design, testing, and maintenance.

Continuous Delivery uses the deployment pipeline to focus efforts on improving the flow of change, from the code commit to the software running in production. Specific technical capabilities are described in detail to enable the early and continuous delivery of valuable software.

The principles are the only directly comparable elements of these 3 approaches.

Continuous Delivery principles

There are 5 principles of Continuous Delivery:

Build quality in
Work in small batches
Computers perform repetitive tasks, and people solve problems
Relentlessly pursue continuous improvement
Everyone is responsible

The principles can be arranged into a reinforcing relationship, where the first 3 principles act as drivers of continuous improvement, for which everyone involved is responsible.

Agile principles comparison

In general, Continuous Delivery principles are consistent with The Agile Manifesto.

For example, working in small batches is widely understood to help achieve several of the Agile principles:

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
Working software is the primary measure of progress.
Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
Simplicity — the art of maximizing the amount of work not done — is essential.

The phrasing of the principle “work in small batches” is concise and easy to follow in practice. This Continuous Delivery principle contributes to the attainment of half of the Agile principles.

There is also an amplification effect when you combine the 5 principles. To “deliver working software frequently”, you need to work in small batches, increase automation, and build quality in.

Two Agile principles are not covered by Continuous Delivery:

Business people and developers must work together daily throughout the project.
The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

Continuous Delivery is centered on the delivery pipeline, which means the process of identification, inception, and initiation aren’t a direct concern of Continuous Delivery. Additionally, in the front matter of the Continuous Delivery book, the authors highlight that the book was created according to the ideas it contained. The contributors and editors worked using different tools and from separate locations. They used version control and automated builds to form a delivery pipeline for the book. They didn’t work together daily or convey information face-to-face.

As an industry, many organizations who hadn’t attempted to work remotely are now ready to experiment with distributed working. This will further challenge the need for real-time face-to-face coordination as asynchronous communication becomes more common and familiar.

Regarding word counts, Continuous Delivery principles are conveyed in 21 words, rather than 180 words for Agile principles. A combination of hindsight and incisive editing has given us a compass to check our direction, with the detail provided in the specific practices of Continuous Delivery.

"It’s easy to get bogged down in the details of implementing Continuous Delivery — CD tools, architecture, practices, politics — if you find yourself lost, try revisiting these principles and you may find it helps you re-focus on what’s important.” — Jez Humble

You don’t have to throw out The Agile Manifesto to move forwards; it’s part of the geography that Continuous Delivery and DevOps are building on. The industry will continue to discover new and better ways of developing software. It’s increasingly evident that technical practices and cultural capabilities are vital.

Lean principles comparison

The Lean principles are already brief and actionable. There’s complete alignment between Lean and Continuous Delivery, with no un-mapped areas.

With Agile, Continuous Delivery offered a concise alternative to 10 Agile principles. In the case of Lean, Continuous Delivery aligns entirely with the principles. Each approach provides a different perspective that applies to various organization segments.

In an organization that has fully adopted both Lean and Continuous Delivery, the respective principles are helpful to different groups. Lean principles and techniques are leadership tools, while Continuous Delivery provides an approach specific to the individual contributors’ delivery efforts.

For example, automation is a practical attack vector for eliminating waste, delivering quickly, and building integrity into the system with Continuous Delivery.

Conclusion

Continuous Delivery provides a concise set of principles that align with 10 of the 12 Agile principles and complement Lean, providing a different perspective on achieving similar goals.

All 3 sets of principles are consistent with modern management philosophy and provide different ways to review and re-focus your software delivery efforts.

You can use the Continuous Delivery principles to guide your software delivery efforts and refer back to Agile and Lean principles to find further inspiration for your improvement efforts.