Article summary
In a previous post, Tear Down the Walls! — Shattering Team Boundaries, I discussed the boundaries (or silos) that traditional teams often end up segregating into, especially when deadlines are looming.
The project I am on has many teams scattered across multiple physical locations (even continents), and teams are frequently under separate silos of management. Epic-level stories that cross these geographical and management boundaries are a bear to coordinate in the context of traditional/static teams.
One strategy that we have been using to break down boundaries is lending resources to other teams. This has helped the problem in some cases, although management of priorities and dependencies across team boundaries requires a high level of coordination and compromise, especially when key milestones are approaching. Local team needs too frequently get prioritized over efforts that cross team boundaries, even though they may have critical importance to the product being developed.
In this post, I propose a solution to this “people problem” that involves dynamically forming teams around epics. In order for this to work, buy-in from developers and (more importantly) the managers and home-team leads that own these resources is crucial.
Acknowledging the REAL Problem
Assaf Stone authored an excellent post, 10 Signs that Your Team Isn’t Really Agile, that I have been referring back to regularly to keep myself in check and to validate our own strategies against these guidelines. At the top of the list is one that has bothered me, because although it makes sense, our teams keep violating it time and time again.
You might not be truly agile if…
1. Your team is not responsible for the entire story – Perhaps the most important aspect of an agile team is that it is cross functional. This means that the team, as a whole, have all the skills required to deliver a valuable product increment. If a team has only client developers, then all server-side tasks are probably relegated to a different team. In this case, the team is not handling a story from end to end; when they complete their work, no value has been added to the product – not in the eyes of the customer! Teams that work like this resemble a factory where the product sits on the conveyor belt and different layers are added to it by different teams. At no moment till the last team does its thing is the feature (or product) done.
Having all the necessary skills and expertise to conquer a user story (or especially an epic) is indeed the ideal way to conquer a largely scoped story, but this is not a realistic expectation in a large organization with many diverse and/or distributed teams.
The Situation at Hand
A large epic story we have been working on, across many teams, has presented large problems for integration and measurable progress. A major pitfall we hit recently (and are still trying to recover from) happened because team A had piece X, and team B had piece Y. There were corresponding, yet separate, stories defined on each side of the fence for teams A and B. Team A “completed” their part of the story according to the requirements laid forth, and then the switch was flippped to roll these changes into the default working branch of the repository.
Unfortunately, team B, which consisted of… well… just me for this epic. When “the switch” was flipped, my half for this functionality was partially incomplete, and there were integration issues that brought down “the build” for a few days during a really critical time in the project where we were trying to deliver our first pre-production release.
Since then, we have been struggling, monkey-patching, and working way too many hours. And as a result, we are still in this dilemma and have built up significant technical debt in the meantime.
This problem would likely never have happened if we were all on the same team.
On our project, every team has their own team leads, scrum masters, and/or managers. Unfortunately, this usually leads to developers being being statically allocated and too frequently over/under-utilized.
When it comes time to meeting commitments at critical project junctures, and the deliverable is at risk, pressure from the upper levels increases. As this trend continues, week after week, developers tire and tend to claim their stories complete haphazardly, in order to show progress. As a result, defect rates increase, which leads to finger-pointing, more meetings… and frustration across the board.
Refactoring the Team
In order to eliminate this distorted concept of done-ness, a team-spanning epic is better tackled if all people needed to complete the epic were reorganized into a new team. This new team would have all domain representatives and do-ers, from the various teams, reintegrated into a force more able to conquer the challenge at hand. The team shares a formal backlog, user stories are refined, executed, and accepted… together.
Much thanks to Assaf Stone for making me fuss with this dilemma of common ownership, and the arriving at the same conclusion. Hopefully utilizing dynamically-formed teams can help my team — others reading this post — overcome this common hurdle of integration.
How does your organization deal with epic stories, or even user stories that cross and/or threaten team boundaries?