Gain Control by Breaking Dependencies: Task Level Pt. 2a

Stop starting, and start finishing.

There are two 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.

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 third post in the series continues the analysis of breaking task-level dependencies on a Scrum team. The key is to stop starting and start finishing.

---

Stop Starting and Start Finishing – The Anti-patterns

Even with cross-functional feature teams as described in the prior post, dependencies can creep into the Scrum team. This happens primarily due to a team not finishing what it starts. This typically takes the form of three anti-patterns—“Done” Apathy, Scrum-fall, and Horizontal Story Slicing. These anti-patterns are described below.

Anti-pattern 1: “Done” Apathy

In this anti-pattern, the team does not apply discipline to get to “done” in the Sprint time box. “Done” is defined as potentially shippable working software. Sometimes a team decides that it can come back later to finish up the code. To name a few, defects commonly carry over as well as manual testing.

As a result, the sprint ends with unfinished features. The teams must perform additional tasks to produce potentially shippable working software. This results in “undone” work. The stories remain open. The feedback loop remains open. Velocity is not realized. This requires dependency on a hardening activity to truly get to “done.” The hardening activity usually takes the form of one or more hardening sprints before release as depicted in Figure A.

Hardening sprints delay feedback and hide defects. Defects found during hardening take many times longer to resolve since the originating context has shifted and has been forgotten. Additionally, defects have likely spread into other areas of the code and the complicated mess must be unwound.

An even worse outcome of this anti-pattern is the desire to hand off the hardening activity to a separate “Hardening” team. Teams typically gravitate to this mechanism as protection from the messy work of the hardening sprint so that they can start new feature work. This causes many additional wastes, such as branching and merging and a lack of care by the scrum teams on the downstream impact of their delivered work.

All of this adds up to significant dependencies and waste in the system.

Anti-pattern 2: Scrum-fall

This anti-pattern emerges when the team demonstrates waterfall behavior inside of the sprint despite having a cross-functional feature team. In its worst form, the team treats the sprint backlog as one large batch that moves serially through requirements, design development, and testing as shown in Figure B.

Team members typically focus on the stage where they have deep functional specialization. Analysts focus on requirements, experienced developers focus on design, less experienced developers focus on development, and testers focus on testing.

This results in the same dependencies and waste experienced by the Single-Phase Team anti-pattern in the prior post, albeit at a smaller scale.

A variant but equally wasteful version of this anti-pattern focuses on serialized flow by story in the sprint as depicted in Figure C.

Traditional management favors this method as it appears productive to keep all team members independently utilized at all times. Teams typically misinterpret this as a continuous flow. However, this disjointed approach results in:

• Multiple stories in flight at once
• Decreased teamwork
• Delayed feedback
• Unnecessary intra-team dependencies
• Significant context switching or waiting when team members need help

Both of these scrum-fall anti-pattern examples focus on the workers and keeping them busy in their functional specialty. This does not complete the work as quickly as possible in priority order. Neither pattern takes advantage of the power of teamwork and a single focus to get work completed. Furthermore, task dependencies abound in both approaches.

Anti-Pattern 3: Horizontal Story Slicing

A common pitfall, to which many teams fall victim, is to decompose large features into “smaller” layer stories as shown in Figure D. This is commonly referred to as horizontal story slicing.

Horizontally slicing stories by layer creates, within the scrum team, similar dependencies and waste present in the Layer Teams anti-pattern of the prior post. In fact, due to this additional waste, it typically takes significantly longer to complete the feature if horizontally sliced.

The dependency waste results because developers who have a deep specialty in a layer tend to work on stories of their layer only. This results in hand-offs, coordination issues, delayed integration, and hidden defects. As a result, horizontal layer stories tend to batch up to the end of the sprint before integrating into working features. In this mode, sprint backlog completion is at significant risk.

In summary, horizontal slicing proliferates task dependencies, takes longer to complete the features, and adds significant risk to completing the sprint backlog.

---

Conclusion

There are many ways to work inside of a sprint. When trying to break dependencies at the task level, a team should stop starting and start finishing. This post describes three sprint-level anti-pattern behaviors that work contrary to finishing work fast—having “Done” apathy, delivering features in a Scrum-fall fashion, and slicing stories horizontally across architectural layers. These three anti-patterns add dependencies rather than remove dependencies at the task level and inhibit teamwork.

The next post in the series will describe two corrective patterns that instantly allow the team to stop starting and start finishing—Vertical Story Slicing and Swarming. These two patterns encourage teamwork and focus on getting individual features “Done” as soon as possible.

---

Other Posts in the Series

• Introduction
• Task Level Part 1
• Task Level Part 2b
• Feature Level
• Organizational Entities

---

Also published on Medium.