Feature Team Cross Dependencies

Question

We in the midst of a conversion to Agile/Scrum, using Agile Software Requirements as a general manual.

We've traditionally broken our teams up into component teams. One team does API/Service work while another does UI implementation. Mix in a team of testers and after quite a few years of this, a bit of a rift has grown between the teams.

We've organized into back office and front office teams. One team being in charge of building from top to bottom the customer facing part, while the other handles the back office billing/sales systems.

The problem is twofold. We have certain services that are consumed by both of the teams. So, we also formed a component group that's in charge of maintaining these global services. This creates inter-team dependencies, kind of contrary to the concept of a feature team.

The other problem is that the front office applications have to call into the back office applications to see if a customer has purchased a subscription to Product X. Again, another cross team dependency. It's impossible for us to bring Product Y to market without backoffice billing support and the management of the product in our customer facing portal.

To solve the dilemma, we changed who the component group considers as a customer. Instead of a fully end user testable feature with a UI, the APIs themselves have to be approved of by the teams that consume them. Thus, kind of making them a feature team as well, just without a UI. The back/front office teams become the customer/stakeholders.

Is this logic sound? Can I get a sanity check on this?

Answer 1

This makes a lot of sense when I compare it to what our organization is doing as well. We've multiple layers of component teams with chained dependencies (they can't be one team given challenges due to the geographic spread, team size).

In other words:

Team A produces something consumed by team B which uses it to produce something for team C who eventually ends up selling the final solutions to an actual "pays the bill" customer.

So the planning approach we've taken is to stagger our sprints (for A, B and C) to allow for acceptance/feedback, testing and risk management. Each team treats whoever's receiving their deliverable as the "one and only" customer. The Product Owner for each team liaisons with the upper layer and ensures that a "tagged" child story (for A, B, C) groups together to actually deliver the complete "vertical cake slice" user story that the actual customer wants.

As an earlier post indicated, a Scrum of Scrums where the Scrum Masters huddle together once a week is critical to making this work smoothly (we've already seen situations where we don't track each other's updates on Rally all that well and sometimes get blocked on a dependency-related task)

Not quite what Agile might have in mind ... but we're trying to work with what we've got and add more improvements as we go along.

Answer 2

Your approach makes sense. Considering that Feature Teams work on shippable increments to deliver business value to a customer, your back-office teams have to also have a client to whom they deliver value, making your front-office teams their customers. Your challenge then becomes to align all scrum teams from the point of view of planning. Check out Scrum of Scrums: Running Agile on Large Projects (an archived version of a user submitted article that was on the Scrum Alliance site) for some ideas.