At one company, we worked to bring the development batch size down from multiple quarters across the whole organization to a few weeks of each team’s efforts. To enable this endeavor, I defined a batch as development work completed to an organizational-wide, agreed-upon definition of done and customer outcomes. The batch size was calculated by the time and effort required from start to finish of the agreed upon customer outcomes by people or teams involved.
Even with this simple definition of a batch, a number of the company’s leaders engaged in passive aggressive behaviors to undermine the movement to smaller batches. The executive sponsors focused on surfacing the passive aggressives’ reasoning and systematically addressed their concerns over time. In doing so, the development batch size was reduced, code quality increased, and predictability improved.
I found the passive aggressives’ reactions and thinking informative of the challenge facing organizations when moving from traditional, large batch development to agile, small batch development. Allow me to represent their thinking here.
There are two vastly different principle sets at work behind traditional, large batch development and agile, small batch development. The traditional development principles are based upon the efficiency gained in development by aligning partial work outcomes across all teams. For example, aligning key requirements by a requirements completion date, aligning designs by a design completion date, aligning implementation by a functional completion date, aligning testing by a test completion date, and aligning system delivery by a system test completion date.
The agile development principles are based upon the efficiency gained in development by always returning each small batch to a high quality of completeness and delivering the batch to final system testing or to the customer many times within a sprint.
Both are valid claims to efficiency yet diametrically opposed on how they gain efficiencies of development.
Changing an organization from traditional, large batch development to agile, small batch development requires a different level of thinking across roles/teams, processes, architecture, requirements, validation and delivery. At the root of the push back, was an element of the change in development principle sets.
Claim: that’s not how we do work. Response: Correct, small development batches cannot be achieved by doing what we did with large development batches. In Scrum and Scrum@Scale, the organization structures and individual/team roles are very different. We need to reset expectations of people’s roles and their metrics including the leaders’ roles.
Claim: We need to make design changes as we implement and test features. Response: We need to spend more ensuring that APIs are correctly designed, validated and backward/forward compatible so incremental changes can be made with each small batch. We have to design in perceived and conceptual integrity.
Claim: we lack the build and test speeds. Response: let’s prioritize time to speed up builds and test automation so we can reduce the development batch size over time. Otherwise, we’ll be wasting team members’ time waiting. The payback in increased velocity will offset the upfront costs.
Claim: Features take a lot of cross team communication. Response: The increased cross team communication is a potential sign that our APIs are poorly designed, documented and/or validated. Let’s spend time incrementally improving these where cross team communication is costly and can be significantly reduced by an improved API.
Claim: Features are bigger than a single sprint. Response: Yes, features are bigger than a sprint, and more importantly, than a batch when the batch size is smaller than a sprint. This means that our grooming has to take into account time for understanding overall customer outcomes, needed validation investments, good APIs and breaking up customer outcomes so they can be incrementally delivered.
Claim: We have too many bugs to fix prior to release so we’ll defer them and fix them in the next batch. Response: Let’s step back, why are we deferring defects? They are deferred because we poorly estimate how much work can be completed in a batch. The larger the development batch, the less confident we’re in our estimation. Shifting to small development batches, better APIs, better grooming and consistent definition of done, we increase our confidence and decrease our error margins. We won’t have to defer defect fixes. Equally, a batch is not finished until it meets the definition of done and accepted by the product owner per the agreed upon outcome.
Claim: Customer will never accept increased frequency of product delivery. Response: Why won’t they? Is it because our infrequent complex releases, labor/resource intensive updates and deferred defects create poor product update experiences? We’ll address these by prioritizing non-disruptive-update capabilities, use the improved update capabilities to speed up our validation automation, never defer defects, improve design integrity, and incrementally show improvement in customer update experiences.
As we worked through these claims, the responses and changes, the passive aggressives started to sign on to small batches, albeit, slowly. The best part was that customers noticed these improvements as the new releases came available.
Footnote for executives: note how investments in people, process, tools, methods and architecture are key to moving to an agile development principle set. These can be done incrementally, however, must be done with forethought and purpose. As noted in the answers, these investments are codependent with grooming the backlog, inspection of outcomes, and resolution of impediments. Transparency and inclusion of these investments helped this organization address the concerns and move forward together.
