We’re doing Scrum. Why does everything take so long to finish?
For many teams, delivery bogs down because of the way individuals approach the work itself.
Most teams are still working in a sequence: one person finishes their part, hands it off, and then the next person begins. Designers wait for analysis to finish. Developers wait for designs. Testers wait for the code to be done. Everyone’s optimizing for their own efficiency — but the team as a whole slows down.
That might feel to individuals like the “right” way to work, but it comes with real costs:
 

• Mistakes go unnoticed until late in the process — and keep happening until then.
• Too much work is started toward the end of the sprint, creating bottlenecks and delays, which means features take longer to reach your users, and feedback takes longer to reach the team.
• Time to market, or time to value, is extended.

Even when teams are doing “agile” on the surface, these large handoffs are the opposite of how an agile team works.
To deliver value quickly, team members have to learn to stop waiting for someone else to finish before they start–in other words, they need to overlap work.
When one type of task looks like it’s dependent on another type of task, teams accustomed to overlapping work find ways to begin the second task before the first is completed. Coders start coding while the designer is still designing. Testers start creating tests even while the coder is coding.

Why do teams cling to this outdated way of working?
When teams first try working this way, many team members resist it. They’re used to holding on to their work until it’s perfect and “ready.” They might find the idea of overlapping work to be too messy and inefficient.
Consider, for example, a tester. To be as efficient as possible, this tester would like to begin testing only after coding is complete. To test any earlier risks repeating work by re-running, or even re-designing, tests.
What these team members need to realize is that optimizing for the efficiency of any one role prolongs the amount of time it takes to complete each new feature.
 
Overlapping work is key to working in an agile way.
For example, imagine that a developer is building a search results page for an eCommerce site. The page allows users to filter results by product attributes such as size, color, and more. Results can also be sorted by price, popularity, rating, and so on. If a programmer develops all of that before handing it over to a tester then no work has overlapped.
If, however, the programmer handed it to the tester in pieces then testing could overlap with programming. The programmer could, for example, provide the tester with a version of the page without filtering or sorting. While a tester checks that, the developer adds filtering by size. Then color. Then sorting. The work overlaps — and everything moves faster.
Two simple ways to encourage this way of working:
Ask teams to shrink task size. Breaking big tasks into bite-sized pieces makes it easier for roles to overlap and collaborate. As handoffs get smaller, collaboration gets easier.
Try swarming. Swarming is an extreme form of overlapping work that helps teams learn to let go of a “my work, your work” mindset and sequential “finish-to-start” mentality. When a team swarms, the whole team focuses on just one (or maybe two) items at a time.
I’m not suggesting swarming as a long-term solution or the optimal way to work. It’s a temporary, artificial constraint on work in process designed to force teams to find new ways to collaborate and move faster together. The goal is to remove the limit later, and have team members continue to apply the lessons they learned when they were forced to over-collaborate.

How to connect with AgileDad:

- [website] ⁠https://www.agiledad.com/⁠

- [instagram] ⁠https://www.instagram.com/agile_coach/⁠

- [facebook] ⁠https://www.facebook.com/RealAgileDad/⁠

- [Linkedin] ⁠https://www.linkedin.com/in/leehenson/