Guessing is not a strategy: How to build decision velocity with AI and real-time data
June 10, 2026 | Live Webinar
Categories: Lean
Big projects have a lot of moving parts. Lots of individual teams and systems that need to interface with each other in the final product.
Many organizations have addressed this complexity and sheer number of interfacing systems by creating ‘levels’ of testing whereby subsystems get integrated into larger systems, which then get integrated with even larger systems.
The standard hierarchical way of thinking about people and systems is a big part of the problem.
This approach carries with it tremendous coordination costs and waste due to the process overhead and gap in time between a feature is originally implemented until it is fully verified and validated as being correct.
These coordination costs tend to make the releases larger and larger, because much of the release costs are fixed and so more releases means a nearly linear amount of extra coordination costs. That’s how we end up with releases 6-12 months or longer in duration.
Waiting for an integration milestone increases the risk of rework as teams interpret interface specifications differently, customer needs change over time, etc.
Another funny (and sad) side-effect that occurs with this model is the lag between testing at the level of actually writing code versus the ‘higher-level’ tests. I’ve seen delays of as much as 6 months. Many times, the “lower-level’ development team has produced their next release before their previous release is integrated into the system. This is highly confusing for testers and end users, and when problems are discovered at ‘higher-level’ testing you are usually forced to distract the developers from their current release with the bureaucracy involved at those high level tests. Minor bug fixes that take about an hour to investigate, fix, and test end up consuming tens or even hundreds of hours collectively in meetings and reports due to the level of formality and attendees at meetings. (20 people in a meeting for 15 minutes talking about a minor bug is 5 man-hours, and usually the managers and senior engineers involved are at a much higher pay rate than the developer who fixed the bug in an hour. Scary, huh?)
Continuous integration means that the focus of a release is a single feature (or perhaps a few) and that item of focus is what the whole team is concentrating on. The entire system from beginning to end is rebuilt and tested. Testing is as automated and streamlined as possible, and this is only feasible if your configuration management and build processes are also lean and mean.
The best configuration management systems I’ve seen are capable of easy updates after approval with automated rebuilds. They allow you to make releases as small and frequent as possible, which is exactly what you want for continuous integration and making your projects as lean as possible.
Feedback is nearly instantaneous. Bugs are fixed faster because developers don’t have to go back and read through their code to figure out what it’s doing. It’s hot off the presses and still fresh in their minds.
Rework is avoided. End-users and testers get to try to break the system right away and see it for themselves. This decreases the amount of assumptions project teams have to make about the product from everything to major functionality of the system to minor user interface tweaks that make it easier to use.
Many organizations have addressed this complexity and sheer number of interfacing systems by creating ‘levels’ of testing whereby subsystems get integrated into larger systems, which then get integrated with even larger systems.
It’s The Hierarchy
The standard hierarchical way of thinking about people and systems is a big part of the problem.
This approach carries with it tremendous coordination costs and waste due to the process overhead and gap in time between a feature is originally implemented until it is fully verified and validated as being correct.
These coordination costs tend to make the releases larger and larger, because much of the release costs are fixed and so more releases means a nearly linear amount of extra coordination costs. That’s how we end up with releases 6-12 months or longer in duration.
Waiting for an integration milestone increases the risk of rework as teams interpret interface specifications differently, customer needs change over time, etc.
Another funny (and sad) side-effect that occurs with this model is the lag between testing at the level of actually writing code versus the ‘higher-level’ tests. I’ve seen delays of as much as 6 months. Many times, the “lower-level’ development team has produced their next release before their previous release is integrated into the system. This is highly confusing for testers and end users, and when problems are discovered at ‘higher-level’ testing you are usually forced to distract the developers from their current release with the bureaucracy involved at those high level tests. Minor bug fixes that take about an hour to investigate, fix, and test end up consuming tens or even hundreds of hours collectively in meetings and reports due to the level of formality and attendees at meetings. (20 people in a meeting for 15 minutes talking about a minor bug is 5 man-hours, and usually the managers and senior engineers involved are at a much higher pay rate than the developer who fixed the bug in an hour. Scary, huh?)
Make The World Flat
Discard the hierarchy.Continuous integration means that the focus of a release is a single feature (or perhaps a few) and that item of focus is what the whole team is concentrating on. The entire system from beginning to end is rebuilt and tested. Testing is as automated and streamlined as possible, and this is only feasible if your configuration management and build processes are also lean and mean.
The best configuration management systems I’ve seen are capable of easy updates after approval with automated rebuilds. They allow you to make releases as small and frequent as possible, which is exactly what you want for continuous integration and making your projects as lean as possible.
Feedback is nearly instantaneous. Bugs are fixed faster because developers don’t have to go back and read through their code to figure out what it’s doing. It’s hot off the presses and still fresh in their minds.
Rework is avoided. End-users and testers get to try to break the system right away and see it for themselves. This decreases the amount of assumptions project teams have to make about the product from everything to major functionality of the system to minor user interface tweaks that make it easier to use.
Imagine
Imagine if you could full integrate and test each feature developed before moving on to the next feature. How much focus would that create for your project teams? How much stress would it save from team members who now only have to worry about 1 major focus at a time and no competing priorities? How much confidence would it give your sponsor, customer, and end users when they see the system evolving in front of their eyes, in a way they can play with it and have their concerns and feedback addressed immediately instead of just hoping they’ll be able to actually use what ‘those teams over there’ are developing?
In This Series:
Posted on: December 29, 2011 04:48 PM |
Permalink