Let's explore how to achieve this by adjusting processes to move efficiently and confidently.
Speed and Direction: It’s Not Just About Developing Faster
Being more efficient is not about building more (see The Building Fallacy) or always staying busy (resource efficiency, see The Resource Utilization Trap). Speed, in physical terms, has a direction, and moving fast in the wrong direction is the greatest waste we can have (see Eliminating Waste in Development). To move in the right direction, we need:
- Continuous Deployment: To obtain frequent feedback.
- Humility: To accept that we do not always know what the customer needs or what the best technical solution is.
- Adaptation: Constantly adjusting our technical and product direction based on the feedback we receive.
How Fast is Fast?
From a practical perspective, moving fast means:
- Taking very small steps in development and delivery (see Developing Software: Postponing Decisions and Working in Small Steps).
- Ensuring that these steps last between a few hours (technical segmentation) and a day or a day and a half (product increments).
This allows us to deploy multiple times a day. Deploying this frequently requires doing so on demand, safely, and quickly. In an ideal world, these deliveries would be directly to the end customer. However, depending on the context, direct deployment to customers may not always be possible, or it may only be feasible for certain users (e.g., in embedded systems development or operating system components). These cases should be the exception (see Jocelyn Goldfein’s Model).
About 15 years ago, at Alea Soluciones, we deployed to production between three and five times per week, which was reasonable considering we were working with systems installed in our customers' data centers. Later, at companies like The Motion, Nextail, and ClarityAI—cloud-based multi-tenant environments—the teams I worked with achieved multiple deployments per day.
In all these cases, we reached this delivery speed using Trunk-Based Development, TDD, Continuous Integration, and pairing/mob programming, applying practices from eXtreme Programming (XP).
Control and Speed: The Right Balance
As Canadian Formula 1 driver Gilles Villeneuve said: "If everything seems under control, you’re not going fast enough." ;)
Having everything under control may seem ideal, but in reality, it’s a sign that you could be moving faster. How much faster? Until you start noticing some failures. This idea is key when developing software at high speed.
In my experience, when working with TBD, TDD, and Continuous Delivery, confidence in the process grows, and you start accelerating—delivering faster and faster. Inevitably, a mistake will happen. However, by working in small increments, the risk is low, and fixing the issue is usually quick. After correcting the error, it’s common for the team to slightly reduce speed.
This cycle of accelerating, learning, and adjusting is normal and, in my opinion, is a sign of a healthy team that continuously improves while maintaining a high delivery pace.
The Need for Robust Deployment Pipelines
In Lean, the flow of value begins with an idea or experiment we want to implement or validate and ends when we have delivered the increment, obtained feedback, and are ready to evaluate and decide on the next steps.
While Lean Manufacturing promotes reducing variability to standardize and optimize flow, in Lean Product Development or Lean Software Development, not all phases require low variability. For example:
- At the beginning of the value stream, experimentation and creativity are needed to generate diverse ideas and approaches.
- At the end of the cycle, we analyze feedback to decide what adjustments to make.
However, in the systematic process of deploying to production, we must minimize variability. This phase should be fast, solid, and reliable—something we can trust completely.
The goal is for deployments to be boring, a routine task that runs on autopilot.
To achieve this, deployment pipelines should have the following characteristics:
- Fast (<10 minutes) and reliable.
- Provide a high level of confidence in the solution through good automated tests.
- No flaky tests—unstable tests should not exist.
This is only possible if we treat deployment pipelines as first-class citizens in our system, developing and maintaining them with the same level of quality as the rest of the system.
Continuous Deployment: The Most Efficient Method
Ideally, the changes we make should be deployed to production individually, one after another. This allows us to obtain feedback quickly and deliver continuous value increments. As mentioned in this article and previous ones, this way of working provides major benefits:
- We continuously adjust course based on feedback.
- Mistakes have a low impact since they involve small changes and are easy to roll back.
- Understanding errors is simpler because the changes causing them are more limited in scope.
However, deploying is not free—it has an associated cost. It requires investment in:
- Developing automated deployment pipelines.
- Wait time every time we run the pipeline.
This cost is called the “transaction cost,” and when it is high, it limits how fast we can deliver.
Keeping Transaction Costs Low
Lean Software Development recommends keeping transaction costs as low as possible. To achieve this, it is essential to:
- Invest in automated deployment pipelines.
- Use automated tests that allow us to go directly to production if they pass.
This provides the confidence needed to deploy without manual intervention and ensures quality in every production release.
In the teams I have worked with, our default approach is Continuous Deployment. This means that any change committed to the main branch goes directly to production. To achieve this, we separate deployment from release using feature toggles, allowing us to roll out new features in a controlled manner, without making them immediately visible to end users.
Additionally, we have kept our deployment pipeline execution times between 10 and 15 minutes, ensuring that the delivery cycle remains agile and does not disrupt the workflow. If something fails, we typically implement an automatic rollback when post-deployment smoke tests detect an issue. This minimizes impact and ensures we can quickly regain control.
As Jez Humble, Joanne Molesky, and Barry O'Reilly highlight in Lean Enterprise:
"The goal of continuous delivery is to make it safe and economic to work in small batches. This in turn leads to shorter lead times, higher quality, and lower costs."
This approach allows us to confidently make small changes, accelerate delivery times, and reduce risk and error costs.
Conclusions
To deliver value quickly in Lean Software Development, it is crucial to optimize the workflow without compromising quality. Speed does not mean working faster without control but rather continuously adjusting based on feedback, allowing for constant adaptation. Teams following this philosophy achieve continuous and secure deliveries, minimizing risks and maximizing value.
Key Principles:
- Small, frequent steps: Delivering in small increments reduces risk and makes error correction easier.
- Low transaction costs: Investing in fast, reliable deployment pipelines maintains speed without affecting quality.
- Continuous feedback: Rapid delivery enables constant feedback, improving and adapting the product.
- Confidence in quality: With automated testing and a solid delivery flow, teams can be sure that each iteration releases a robust product.
In summary, this approach not only optimizes value delivery but also allows teams to operate sustainably, with fast adjustments and minimal error impact.
No comments:
Post a Comment