Gain Control By Breaking Dependencies: Task Level Pt. 2b

Swarm on your work to finish fast.

Dependency Breaking - Task Level Part 2b

There are three prior posts in this series on dependency breaking:

Introduction: Presented the case for removing dependencies as a means of supporting the Agile mindset and driving control into the Agile team.
Task Level Part 1: Provided a simple pattern that keeps tasks within the team—the cross-functional feature team.
Task Level Part 2a: Gave context for common anti-patterns that impede a team from finishing what they start.

Breaking dependencies at the task level within a team removes unnecessary waste and creates the environment necessary for a hyper-productive, lean delivery team to emerge.

This fourth post in the series finishes the analysis on breaking task-level dependencies on a Scrum team. This post outlines the corrective patterns to the anti-patterns presented in the prior post. These corrective patterns allow a team to stop starting and start finishing.

Stop Starting and Start Finishing

A team gets into dependency trouble when they don’t finish what they start. These dependencies create waste in the system that reduces the team’s effectiveness in delivering value.

The related anti-patterns described in the prior post are—having “Done” apathy, delivering features in a Scrum-fall fashion, and slicing stories horizontally across architectural layers. In summary, these three anti-patterns add dependencies rather than remove dependencies at the task level and inhibit teamwork.

The sections below describe two corrective patterns that allow us to stop starting and start finishing—Vertical Story Slicing and Swarming.

Corrective pattern 1: Vertical Story Slicing

To minimize task dependencies, the way the team decomposes large stories for the sprint is critical. They should treat each split story as a complete feature. To accomplish this, the team vertically slices stories through all architecture layers as shown in Figure A.

Figure A - Vertical Slicing of Stories — Figure A – Vertical Slicing of Stories

Using this technique, decomposing a large story to make it smaller will always slice vertically through the layers to deliver a working portion of the feature. As an example, see Figure B for splitting a Delete Inventory feature.

Figure B - Delete Inventory Decomposition Using Vertical Slicing — Figure B – Delete Inventory Decomposition Using Vertical Slicing

In addition to vertically slicing the story, the team works together to fully analyze, design, develop, and test the feature to a “done” state as quickly as possible. The Swarming corrective pattern described next illustrates how this is accomplished.

Corrective pattern 2: Swarming

The swarming technique provides a simple, comprehensive method to stop starting and start finishing.

Swarming has many benefits and instantly eliminates numerous task-level dependencies inside the scrum team during sprint execution. By implementing swarming, you will see the following benefits:

Reduced feature cycle time / increased velocity
Greater teamwork
Increased happiness for the team, the user, and the business stakeholders
Enhanced team member T-Shapeness / learning
Greater quality
Increased feedback loop speed
Greater probability of delivering value amidst sprint impediments or a sprint failure

Technique

At its core, swarming lowers the story work-in-progress (WIP) limit to 1 story in progress at a time for the Scrum team.

A WIP limit of 1 requires all team members to work simultaneously to get the highest priority story on the sprint backlog done before anyone on the team moves on to the next story. This ensures that the work is finished incrementally throughout the sprint in priority order.

Swarming vs. Scrum-fall

As shown in Figure C, If a problem happens in the middle of the sprint, a team is more likely to finish high-priority work in this model versus the scrum-fall models.

Figure C - Swarming and Scrum-fall Differences for Mid-sprint Problems — Figure C – Swarming and Scrum-fall Differences for Mid-sprint Problems

All team members apply their unique talents to work concurrently on tasks to complete the story. If a team member has a deep specialty and completes his or her specialized tasks for the story ahead of other team members, the team member figures out how he or she can help other team members complete the work. This results in team members learning new skills and becoming more T-Shaped.

Focusing on one story at a time is in contrast to the team member moving on to the next story to stay busy as described in the Scrum-fall anti-pattern of the prior post. Slack in the team is required for optimal flow. Even if the team member is unable to help the other team members with their tasks, it is better to sit idle and wait for an opportunity to help than to move on to the next story. This way, the team member is available instantly if the team needs him or her to resolve an issue and no context switching is necessary. The team member might even refactor some code, brush up on some reading to gain new skills, or do other good housekeeping activities while waiting.

Putting Swarming Into Practice

For swarming to be most effective, small, vertically sliced stories and small teams are key. Teams should target to develop a working story in less than a day to three days at the high end. Striving for continuous integration and daily clean code with no defects are effective supportive patterns to use in a swarming model. A team size of 5 is optimal. See the post, Agile Leader Pattern 3 for Building Awesome Teams: Small is Big, for a description of effective small teams.

Small teams and small stories ensure that team members are utilized effectively to get a story done quickly. Additionally, this minimizes social loafing that can occur in large teams and allows teams to anticipate each other’s needs and operate concurrently to deliver the story to a “done” state. If bottlenecks do occur in swarming, they are relatively short-lived with small stories and have minimal impact with a small team.

The use case in Figure D exemplifies how small teams might swarm and work concurrently on a vertically sliced story.

Figure D - Swarming Use Case — Figure D – Swarming Use Case

Conclusion

We have to stop starting and start finishing.

There are many ways to work inside of a sprint. When trying to break dependencies at the task level and finish what we start, three behaviors are not recommended:

Having “Done” apathy
Delivering features in a Scrum-fall fashion
Slicing stories horizontally across architectural layers

These three anti-patterns add dependencies rather than remove dependencies at the task level and inhibit teamwork.

Instead, use Vertical Story Slicing and Swarming to enhance teamwork and focus on rapidly getting individual features to “Done”. These patterns encourage collaboration, accelerate value, and boost team morale. Both patterns instantly remove significant task-level dependency waste and counteract the anti-patterns.

Stay tuned for the next post in the series—breaking feature-level dependencies.

Blogs