avatarTodd Lankford

Free AI web copilot to create summaries, insights and extended knowledge, download it at here

4610

Abstract

off doing something alone, a new context is born. Requests for help between the team and the branched team member cause interruptions. And those interrupted feel the painful waste of the context switch like a heavy weight on their back.</p><p id="fa11">Now imagine every team member working alone on individual tasks for lengthy periods. The silos proliferate, and the unintegrated knowledge baggage amplifies. Flow can’t compete with low teamwork, disparate knowledge, and high context switching.</p><p id="a9de">Delays are inevitable with silos. They cause pain and hurt team morale in the long run.</p><h2 id="2cdf">Havoc №2: Increased inventory contributes to delays, which erodes team morale</h2><p id="d921">When you reduce integration, branches create an inventory of unfinished work. It does not matter how complete you make work in a branch. Branch work remains unfinished until integrated and combined with the trunk.</p><p id="6b79">Increasing work-in-progress leads to context switching. You end up with too many things running in parallel at once. This split focus feels like spinning many plates, trying to keep them from falling.</p><p id="2e27">As work-in-progress piles up, problems hide. You often don’t see problems until you integrate a branch. Hidden problems contribute to late learning and painful rework, which leads to delays.</p><p id="7ca0">All this context switching and late learning spawns an unsustainable pace. The resulting painful rework causes delays. As with silos, the delay whiplash creates a multi-threaded web of pain.</p><h2 id="3641">Havoc №3: Slow feedback leads to stagnation and painful rework</h2><p id="7af9">When you constrain integration, you reduce and slow the feedback cycle.</p><p id="45a6">Reducing feedback decreases the flow of findings and insights you can use to improve. This diminished learning tends to harden your status quo. And this can lead to stagnation — the opposite of Agile.</p><p id="8cd9">Slow feedback cycles hide problems. As a result, you learn about them too late. Acquiring knowledge late in the game is expensive, stressful, and painful to rectify.</p><h2 id="8a10">The unfortunate result: Integration pain amplifies the impulse to do it less often</h2><p id="e6cc">If integration is painful, many teams will do anything to avoid it. And the easiest, unfortunate choice is to delay what caused it — integration. Delaying it seems like the path of least resistance, and many teams fall victim to this illusion of ease.</p><p id="5cc6">The teams who choose to delay integration fail to realize this easy path increases pain. You can’t escape integration; it is core to a well-functioning product and team. When it finally comes time to integrate any long-lived branch, pain awaits.</p><p id="c60b">The presence of silos, increased inventory, and slow feedback feeds a downward cycle of integration avoidance. The ill effects amplify and work against any move to support frequent integration.</p><p id="f1fa">To break free of this downward spiral, teams must do something counter-intuitive. When integration is painful, they must <i>increase</i> its frequency, not reduce it.</p><h1 id="0deb">You can force frequent integration with 12 simple practices</h1><p id="3e5e">Many practices exist to help force more frequent integration. The Scrum framework itself encourages you to integrate more often. Finding various ways to force integration, even when painful, increases team cohesion.</p><p id="ba31">Here are 12 practices you can try to raise the integration rhythm and break free of late integration.</p><ol><li>Use shorter Sprints to increase feedback loops.</li><li>Reflect in the Daily Scrum on evidence from the prior day to inform the next step forward.</li><li>Examine the completed Sprint in the Retrospective and form improvements for the next Sprint.</li><li>Inspect done Increments in Sprint Reviews and choose the best product path forward.</li><li>Integrate learning during Sprint Planning to create the go-forward Sprint Backlog.</li><li>Keep User Stories whole so they result in working Increments of user value.</li><li>Use swarming, mob programming, and pair programming to increase team cohesion and focus on finishing one backlog item at a time.</li><li>Uphold a strong Definition of Done to help the team to work together to <i>finish</i> Increments.</li><li>Use “stop-the-line” to fix problems when they occur, so they don’t pile up.</li><li>Inspect feature adoption and factor these insights into plans.</li><li>Engage with customers before, during, and after the Sprint to adapt to changing needs.</li><li>Refin

Options

e the Product Backlog with <i>all</i> team members daily to keep plans fresh.</li></ol><h1 id="a1d0">Making integration frequent is within your control</h1><p id="8b02">Integration is not isolated to technology. Successful Scrum Teams need frequent integration of knowledge “branches” into the team “trunk.” Without continual learning integration, teams become disjointed and will fail.</p><p id="81f9">Delaying integration seems like an easy path to take. But it leads to the proliferation of silos, increased inventory, and slow feedback. These side effects wreak havoc and spawn an ongoing downward cycle of integration avoidance.</p><p id="9bbf">But there is an alternative. You can learn from teams who have found a way to reverse the cycle. These teams <i>increase</i> integration frequency when it is painful; they don’t reduce it. They use practices designed to help increase integration opportunities.</p><p id="717c" type="7">We are what we repeatedly do.</p><p id="7c83" type="7">Excellence, then, is not an act,</p><p id="8464" type="7">but a habit.</p><p id="5d80" type="7">— Aristotle</p><p id="ccff">So the next time you become tempted to delay integration, stop. Instead, form a frequent habit to slow down and take the time to keep your team whole.</p><p id="2d43">You too can keep your Scrum Team strong and sane by sidestepping the pitfalls of late integration.</p><h1 id="175b">THANK YOU!</h1><p id="83d2"><b><i>I hope this article helps.</i></b></p><p id="f285"><b><i>For more content on my pursuit of lean leverage delivered to your inbox, you can <a href="https://mailchi.mp/c0d8e9e1608b/dt12qs95i0">join my email list</a>.</i></b></p><h1 id="e88c">Related Posts</h1><p id="cedb">You can read posts related to this one below.</p><div id="889f" class="link-block"> <a href="https://readmedium.com/how-deadline-driven-behavior-sends-your-scrum-teams-spinning-out-of-control-c1c268fd6183"> <div> <div> <h2>How deadline-driven behavior sends your Scrum Teams spinning out of control</h2> <div><h3>And 17 things to try instead. #11: Improve your team’s learning velocity.</h3></div> <div><p>medium.com</p></div> </div> <div> <div style="background-image: url(https://miro.readmedium.com/v2/resize:fit:320/1*1O9cnU5TR3LSFLf_z5080w.jpeg)"></div> </div> </div> </a> </div><div id="7745" class="link-block"> <a href="https://readmedium.com/excellent-product-teams-have-these-five-daily-habits-b9304d98e742"> <div> <div> <h2>Excellent Product Teams Have These Five Daily Habits</h2> <div><h3>These daily rituals prevent piles that slow the system.</h3></div> <div><p>medium.com</p></div> </div> <div> <div style="background-image: url(https://miro.readmedium.com/v2/resize:fit:320/1*47GuOzUawGQxfBN2Cp3Xqg.jpeg)"></div> </div> </div> </a> </div><div id="2782" class="link-block"> <a href="https://readmedium.com/mistake-proofing-your-product-development-with-scrum-7d78f73b0da"> <div> <div> <h2>Mistake-proofing Your Product Development with Scrum</h2> <div><h3>Here is a hint: it is built into the Scrum framework.</h3></div> <div><p>medium.com</p></div> </div> <div> <div style="background-image: url(https://miro.readmedium.com/v2/resize:fit:320/1*mcHvPQd4Cy7HyDTRpiG1SQ.jpeg)"></div> </div> </div> </a> </div><div id="6ea2" class="link-block"> <a href="https://readmedium.com/we-need-one-complete-product-team-5d7508125505"> <div> <div> <h2>We Need One Complete Product Team</h2> <div><h3>Product discovery and delivery are better together.</h3></div> <div><p>medium.com</p></div> </div> <div> <div style="background-image: url(https://miro.readmedium.com/v2/resize:fit:320/1*H3V9LC_6Bs0X9WXA4wwQDQ.jpeg)"></div> </div> </div> </a> </div><figure id="f160"><img src="https://cdn-images-1.readmedium.com/v2/resize:fit:800/0*gBzlqt9INsZuIQMn.png"><figcaption><a href="http://seriousscrum.com/invite">Do you want to write for Serious Scrum or seriously discuss Scrum?</a></figcaption></figure></article></body>

How late integration inflicts wicked problems on your Scrum Teams

Long-lived “branches” create brittle, frustrated teams. Learn 12 ways to avoid them.

Integration to many in the software space refers to the act of making code parts work together. But integration on a Scrum Team goes far beyond this common technical reference.

Without frequent integration in many contexts outside of technology, Scrum Teams will fail. By expanding your lens on integration, you will see why it‘s a crucial ingredient for Scrum Teams.

A Brittle Branch — Photo by Zach Reiner on Unsplash

Software integration refers to merging, testing, and resolving issues with software component interoperability. But for a Scrum Team, integrating knowledge, learning, and team members are of equal importance:

  • Integration of the reality on the ground into go-forward plans.
  • Adapting your understanding of scope to meet new user needs and insights.
  • Merging ideas from each team member into a shared solution.
  • Adapting your game plan every day based on current conditions to meet Sprint Goals.
  • Cross-pollinating specialized knowledge across all team members or even across teams.
  • Integrating individual work and decisions into the collective team “mind.”
  • Reaching shared understanding through collaboration and conversation.
  • Reflecting on past results and adapting better methods into the team’s methods of collaborating and sharing knowledge.

Practicing Scrum requires continuous integration in all aspects of the team dynamic. For Scrum to be effective, you cannot let any knowledge “branch” live too long outside of the team “trunk.” Otherwise, the integration burden will be too high, causing us to resist or delay it.

Despite the benefits of tight team integration, I have seen many teams reduce its frequency. They do this due to anticipated or historical integration pain.

As a result, teams get stuck in a wicked loop, driving them to avoid integration. Infrequent integration leads to delayed learning and further pain. And many teams struggle to escape the grip of late integration’s cascading series of impacts.

But all is not lost. I have seen Scrum Teams break free from this out-of-control spiral.

Let’s become familiar with the wicked impacts of late integration. Then, I will share 12 practices I’ve seen Scrum Teams use to integrate more often and calm the chaos.

Late integration can wreak havoc

When integration is painful, many teams tend to reduce its frequency. They do this because they feel more productive when they don’t stop to integrate.

It’s fun and freeing to be in a branch, unburdened by the slow-down and difficulty of integration. But the longer the branch lives, the greater the pain of the integration back into the whole. A painful merge acts as a force to deter and delay integration.

But delaying integration is the worst thing you can do. Figure 1 illustrates the wicked impacts of late integration.

Figure 1 — The Wicked Impacts of Late Integration

Three disastrous impacts result from late integration.

Havoc №1: Silos break teams apart and cause delays

Branches do nothing to support the whole. They serve only the silo that results from the branch.

When a team member breaks off and works on something alone, a branch has formed and so has a silo. Silos tend to horde knowledge and build turfs, which erodes teamwork.

And the longer a silo lives, the worse the negative impacts become. Long-lived silos make it difficult to integrate branched knowledge into the team’s “mind.” A team often doesn’t have the patience or time for a lengthy merge of large batches of knowledge.

Silos also lead to context switching. When one team member is off doing something alone, a new context is born. Requests for help between the team and the branched team member cause interruptions. And those interrupted feel the painful waste of the context switch like a heavy weight on their back.

Now imagine every team member working alone on individual tasks for lengthy periods. The silos proliferate, and the unintegrated knowledge baggage amplifies. Flow can’t compete with low teamwork, disparate knowledge, and high context switching.

Delays are inevitable with silos. They cause pain and hurt team morale in the long run.

Havoc №2: Increased inventory contributes to delays, which erodes team morale

When you reduce integration, branches create an inventory of unfinished work. It does not matter how complete you make work in a branch. Branch work remains unfinished until integrated and combined with the trunk.

Increasing work-in-progress leads to context switching. You end up with too many things running in parallel at once. This split focus feels like spinning many plates, trying to keep them from falling.

As work-in-progress piles up, problems hide. You often don’t see problems until you integrate a branch. Hidden problems contribute to late learning and painful rework, which leads to delays.

All this context switching and late learning spawns an unsustainable pace. The resulting painful rework causes delays. As with silos, the delay whiplash creates a multi-threaded web of pain.

Havoc №3: Slow feedback leads to stagnation and painful rework

When you constrain integration, you reduce and slow the feedback cycle.

Reducing feedback decreases the flow of findings and insights you can use to improve. This diminished learning tends to harden your status quo. And this can lead to stagnation — the opposite of Agile.

Slow feedback cycles hide problems. As a result, you learn about them too late. Acquiring knowledge late in the game is expensive, stressful, and painful to rectify.

The unfortunate result: Integration pain amplifies the impulse to do it less often

If integration is painful, many teams will do anything to avoid it. And the easiest, unfortunate choice is to delay what caused it — integration. Delaying it seems like the path of least resistance, and many teams fall victim to this illusion of ease.

The teams who choose to delay integration fail to realize this easy path increases pain. You can’t escape integration; it is core to a well-functioning product and team. When it finally comes time to integrate any long-lived branch, pain awaits.

The presence of silos, increased inventory, and slow feedback feeds a downward cycle of integration avoidance. The ill effects amplify and work against any move to support frequent integration.

To break free of this downward spiral, teams must do something counter-intuitive. When integration is painful, they must increase its frequency, not reduce it.

You can force frequent integration with 12 simple practices

Many practices exist to help force more frequent integration. The Scrum framework itself encourages you to integrate more often. Finding various ways to force integration, even when painful, increases team cohesion.

Here are 12 practices you can try to raise the integration rhythm and break free of late integration.

  1. Use shorter Sprints to increase feedback loops.
  2. Reflect in the Daily Scrum on evidence from the prior day to inform the next step forward.
  3. Examine the completed Sprint in the Retrospective and form improvements for the next Sprint.
  4. Inspect done Increments in Sprint Reviews and choose the best product path forward.
  5. Integrate learning during Sprint Planning to create the go-forward Sprint Backlog.
  6. Keep User Stories whole so they result in working Increments of user value.
  7. Use swarming, mob programming, and pair programming to increase team cohesion and focus on finishing one backlog item at a time.
  8. Uphold a strong Definition of Done to help the team to work together to finish Increments.
  9. Use “stop-the-line” to fix problems when they occur, so they don’t pile up.
  10. Inspect feature adoption and factor these insights into plans.
  11. Engage with customers before, during, and after the Sprint to adapt to changing needs.
  12. Refine the Product Backlog with all team members daily to keep plans fresh.

Making integration frequent is within your control

Integration is not isolated to technology. Successful Scrum Teams need frequent integration of knowledge “branches” into the team “trunk.” Without continual learning integration, teams become disjointed and will fail.

Delaying integration seems like an easy path to take. But it leads to the proliferation of silos, increased inventory, and slow feedback. These side effects wreak havoc and spawn an ongoing downward cycle of integration avoidance.

But there is an alternative. You can learn from teams who have found a way to reverse the cycle. These teams increase integration frequency when it is painful; they don’t reduce it. They use practices designed to help increase integration opportunities.

We are what we repeatedly do.

Excellence, then, is not an act,

but a habit.

— Aristotle

So the next time you become tempted to delay integration, stop. Instead, form a frequent habit to slow down and take the time to keep your team whole.

You too can keep your Scrum Team strong and sane by sidestepping the pitfalls of late integration.

THANK YOU!

I hope this article helps.

For more content on my pursuit of lean leverage delivered to your inbox, you can join my email list.

Related Posts

You can read posts related to this one below.

Do you want to write for Serious Scrum or seriously discuss Scrum?
Agile
Leadership
Productivity
Product Development
Serious Scrum
Recommended from ReadMedium