The Wraparound Anti-Pattern (and How to Fix It)

Experienced Agilists will recognize this anti-pattern immediately. It will look something like this:

  1. Teams will make a very ambitious plan either quite close to or even exceeding capacity because work had not been completed last iteration.
  2. Teams will not manage risk or create contingency for unexpected demand or other interruptions due to delivery pressure.
  3. Teams will execute an iteration and not complete their committed stories to varying levels of “doneness.”
  4. Teams will push work to the next iteration and go back to step one.

This pattern, which has its basis in over-commitment, practically ensures that actually committed work is never completed without extending work hours. Work continually leaks into the next iteration, which causes over-commitment to the following iteration, ad infinitum. I have named this the “Wraparound” anti-pattern, and is one of the more recognizable anti-patterns that appear in transforming and maturing teams. It also notably occurs in scaled enterprises at all levels.

The primary effects of the Wraparound are these:

  1. Team increments of business value (user stories) cannot be completed within an operational iteration. This makes planning awkward and unconvincing and dissipates team energy.
  2. Team commitments come under doubt after multiple iterations where commitments were not complete and can disrupt trust within and among teams.
  3. Flow of value through operational teams become “start-stop-start-stop” instead of continuous because the capability for QA to pull work is not possible because of what ends up being team overload.
  4. Abilities for teams to pivot and re-plan are hampered when cycle times of story development are too long to get work done within the planned increment. This problem is exacerbated by waterfall artifacts such as “approvals” and “reviews” appearing in the work flow.
  5. Longer-term estimation of larger value increments become increasingly error-prone.

“The more detailed we made our plans, the longer our cycle times became.”

— Donald G. Reinertsen, “The Principles of Product Development Flow”

How does Wraparound Emerge?

One of the trickier notions of agility is learning a good sense of how much work can be done. Who is best to determine this? Usually it is the team, but teams that are newly minted or going through additional translation or just emerging from training are usually not comfortable enough with their own capabilities to predict the amount of work they can accomplish with any level of accuracy.

1 – Underestimation, immaturity

Part of this equation is determining how much work a team can take on legitimately. Regrettably (and fortunately), there is hardly enough space in a single blog post to cover such a rich and complex subject such as estimating, which has so many techniques as well as so many proponents or detractors that it will detract from the core of this post. Suffice to say, underestimating is exceptionally common, given the perception of teams that they are always “under the gun” to produce more and more value with less time and cost.

When teams underestimate work, they have difficulty mapping the work into a plan because the probability that a team can conceive of a way of getting their work done becomes harder as the iteration rolls on. All of a sudden, tasks that we expected would take hours seem to take days, and end up on disappointed on demo days and scrambling to re-work completion strategies on planning days.

Underestimation also comes from failure to account for “handoffs” and other inefficiencies within a development value stream. The knack of leaning out a value stream is to identify internal processes that hamper completing tasks and eliminating them. Although we all agree that fully cross-functional teams are ideal, these rarely exist. The best we can hope for is to focus on minimizing the amount of time spent not delivering value.

2 – Teams not protected from late demand or rapid priority changes

Although the fundamental tenet of agility is to embrace and welcome change, it is very difficult for the formula of “reciprocal commitment” to be operable on a team force. Although change is welcomed, it is better off to have strong ScrumMasters and other operation personnel protecting a team’s committed plan. The temptation for external forces to influence the behavior of a team in flight is very tempting, and we must strike a balance between continuity and predictability.

If teams spend much effort planning, all while continually deflecting additional demand, enough time and energy can be sapped from a team to cause disruption in value delivery. Agile leaders MUST understand the difference between “EMERGENT” and “URGENT” and only disrupt teams when emergent conditions or matters of sufficient urgency to cause a team to have to re-plan in flight occur.

If leaders get into a habit of changing priorities or business value in flight, teams will never be comfortable enough to settle into good patterns and improve their performance dramatically.

“[…] If your goal is to deliver a valuable product to a customer within some targeted boundaries, when change and deadlines are significant factors, then reliable Agile processes work better.”

― Jim Highsmith, Agile Project Management: Creating Innovative Products

3 – Too rigorous definition of “Ready”

In order to engage stories for planning, they must be in a state where they are complete enough to plan with some degree of accuracy. We are expected to use the INVEST mnemonic to show us where a value story is in its journey to be engaged as work. Frequently these definitions become far too large to be pragmatic, and delay the ability to estimate and plan work. Here are some examples of “readiness” that are contrary to the spirit of leanness and agility:

  • “Story content and estimate must be agreed upon by all members of the team” – Not so. It is a fallacy that there must be agreement by all members of a team about every aspect of every story. The Product Owner’s responsibility is to decide the truth about business value, not the team.
  • “Acceptance Criteria need 100% understanding” – Also not theoretically possible. Scientific studies have shown that we can achieve somewhere in the 75%-80% range of understanding, and that efforts to achieve more than that detract from ability to do work efficiently.
  • “Performance Criteria are defined” – This might be true for overall performance levels of an application, but if the functionality is only understood at 75%-80%, how can the performance be understood any better?
  • “Stories must cover a vertical slice of a full deployment stack” – This is a common misconception about the breadth of user functionality in a thick stack. It is simply infeasible to built discrete separate units of executable functionality across an entire stack during the short time of a team iteration. This needs to be re-interpreted and re-discovered by teams. It is far more efficient to build sub-slices of a full stack and verify them independently than try to build unit and integration tests for a full-stack dive into business functionality.
  • “All applicable test cases must be identified” – Another impossible hurdle due to the uncertainty of user story business value. These should become clear as the story is engaged by the team.
  • “All dependencies must be identified” – We do try to think as far ahead as we can to foresee dependencies, but – again – until we are fully engaged in a story, we cannot know with certainty that all dependencies are identified.

Generally speaking, a story should be considered ready if two things are true:

  1. The Product Owner believes the truth about the story to be MOSTLY correct, to the best of their knowledge at the time.
  2. The team agrees that the story can be completed in some iteration based on their understanding of the Product Owner’s communication of value.

The INVEST mnemonic insures that both of these are true, and serves in itself as a good guideline for a workable “definition of ready.”

4 – Too ponderous definition of “Done”

As with the definition of “Ready,” this definition can prove elusive. To succeed as an Agile team, we must focus on rigorous quality, but balance this with time-to-market and predictability. Many organizations have definitions that are too meticulous and prevent value from being completed and moved along the value stream to integration and deployment.

The true definition of “Done” is rather simple: was the customer/consumer’s need satisfied? We use the Product Owner as a high-availability proxy to answer this question on behalf of the customer/consumer.

Here are some examples of “doneness” that seem also to be contrary to the spirit of Agile:

  • “Code has to be reviewed” – In the age of XP development practices, it is hard to believe that we still have this appearing in definitions. The obvious way to eliminate this is to take advantage of pair programming and mentoring, which provides a sort of continuous review of code being woven into team operations. Given the proven techniques of test-driven/behavior-driven development, automated testing and continuous integration, this step becomes a bottleneck.
  • “Documentation [X] needs to be produced” – Refer to the first value of the Agile Manifesto. Working code should be the source of truth for how a system functions.
  • “Unit tests pass” – This should not be included for teams that have embraced CI/CD as it is redundant. If teams are not in CI/CD, TDD and BDD lose much of their value.
  • “Story approved by UX/UI or Architecture” – This should be done as part of the story definition, not as an approval process after the work has been completed. This sets up an additional potential bottleneck to getting stories across the Kanban within an iteration and adds unnecessary dependencies on workers outside the team proper.
  • “Refactoring Completed” – This is very nebulous and speaks to the same issues as code reviews. Refactoring is a technical technique that should be in continuous practice, so the idea that it is “completed” is paradoxical.
  • “Compatibility Passed” – This usually refers to integration of code developed by teams and should be brought out by automated regression testing. Imagine having to test your code manually against every compatible version of code? Yuck! Compatibility is an integration, not a development issue.

5 – Understaffed Teams

Although we hate to bring it up, the Wraparound can be a sign that the development teams are taking on more work than they can produce or more complex work than they can produce in a given period of time. If teams always feel that they are under the gun, when a real emergency happens, there may be no reserve of team energy to tap into. Once we start making teams work more than a reasonable work week, productivity goes down immediately. Management should take a serious and continuous look at teams and their structure and look for these issues, which can lead to deficiencies in value stream delivery.

Also, and perhaps more insidiously, there are insufficient cross-functional skills within organizations to get work done within an execution team context. If teams are over-staffed with developers and analysts, we can expect the ability to drive through QA to be significantly hampered. This is why the ideal team is not divided into execution roles and should be able to do any tasks that are needed to get a story fully complete and ready to integrate.

How Do We Fix the Wraparound?

It is not possible to understand every team’s context and composition, but here are some steps an organization might undertake to eliminate this phenomenon without putting the brakes on development and re-tooling the value stream:

  • Slow down and catch up – We don’t want to stop the train, but if we are behind, there is something to be said for reducing capacity dramatically until teams can get out of the Wraparound phenomena. Reduce capacity until your teams are succeeding, then increase as they mature.
  • Review development value stream and reorganize – Use value stream mapping on a small scale to uncover all of the steps that work has to take to get out the door. Identify obvious bottlenecks and correct them! Eliminate approvals and reviews wherever possible!
  • Staff teams properly – Make sure your teams have enough talent, skills and time to do the work that is expected of them. If not – FIX IT. We should not be afraid to re-align teams that are nor organized for maximal efficiency. Add headcount or reduce workload!
  • Narrow definitions of “ready” and “done” – If your team is struggling with getting work onto, across or off the Kanban, think about simplifying these definitions. Sometimes they include unreasonable requirements that slow delivery and do not add value or assure quality.
  • Keep your work small – Smaller work items move across a Kanban more quickly, contain fewer tests and test cases, have fewer integration points and have smaller regression scope.
  • Eliminate WIP limits – WIP limits exist to speed work up. If your WIP limits are slowing you down, you are not using them correctly. Eliminate them until you can ensure they are helping and not hurting your team.

Agile is still a new way of looking at the world, and even though it is being slowly embraced, we still have a long way to go before its principles and values are fully integrated into our value-producing cultures. By identifying anti-patterns like this, teams can put themselves on a legitimate path to improvement and emerging as high-performing value creators.

The problem isn’t change, per se, because change is going to happen; the problem, rather, is the inability to cope with change when it comes. ― Kent Beck

Originally posted in LinkedIn Pulse here.