What Does It Take?

Break down change requests into smaller chunks (aka reducing the batch size)

Full features can be accomplished by breaking them down into discrete increments of business or architectural value (aka user stories) that could be achieved by one Agile Team within one sprint (two weeks). This is why a Product Owner is crucial to the success of Agile. Only the PO knows what the business would consider valuable as evidence of progress. And, by being dedicated to one or two stable Agile Teams, the PO develops the experience necessary to anticipate how much work (batch size) can be achieved in a single sprint and how to break business features down to fit within the time box.

Work with the team's Product Owner to help them learn the level of granularity at which requests must be broken down to fit within the team's sprint capacity.

Be judicious about roadmap commitments and constraints.

Sometimes outside dependencies will force hard dates, especially if they are on or from waterfall-based projects or budgeting models; these can be treated as milestones and planned into the system. But early commitments do reduce agility and slow the overall value delivery process down.

Respect the cadence boundaries.

Fix on a cadence.

The cadence is the interval of time in which the entire work of a sprint is done. That means, say, every two weeks, an Agile Team designs, develops, tests, and demos units of business or architectural value. In order for a team to be effective in such short order, the scope of work for that sprint must not change. Changes in priorities can be addressed in the next sprint, which is fortunately only two weeks away. Cadence-based planning limits variability to a single interval, thereby converting unpredictable events into predictable ones. Note: If multiple teams are to contribute to a release train, they need to all agree to the same time box.

Support (demand!) IT's adoption of continuous integration tools on the products that support your business.

Adopt continuous integration tools.

The tools and practice of continuous integration provide automated, immediate feedback on quality every time a developer commits a change. Immediate feedback on small increments of work (aka short queues and small batch sizes) provide visible, frequent measurements of quality and reduce risk and cost.

Support (demand!) that your products be architected to reduce the cost of delays in delivery without compromising quality or architectural constraints.

Architect software systems to lower transaction cost.

Reduce the cost of software development by building systems designed to minimize delays in the process and the obstacles to integration.