When is it OK to treat a component as its own complete software system with its own customers and user stories, and when should it only be treated as a component? We try not to assign a team to a component because a component doesn’t deliver value to customers, yet sometimes the lines blur. So I thought it might be instructive to talk about the second-simplest kind of back-end software there is. I’m referring to the Server in the ubiquitous Client-Server architecture.
Teams that work on systems with a Client-Server architecture traditionally divide up into a Front End team and a Back End team. It seems pretty logical, doesn’t it? The developers that consider themselves front-end people, or GUI people, all get to concentrate on the user experience, while the back-end people aren’t burdened by those concerns. They are just the hardcore folks who wrangle the data. Often, they’re the ones ‘close to the iron’.
What happens when these teams adopt Scrum? In the best of all possible worlds, somebody on one of the teams notices that the Product Backlog of one or both teams doesn’t really contain items that deliver customer value. The Back-end team has items like “implement database connection pooling” or “archive audit logs”. The Front-End team has Product Backlog Items (PBIs) like “As a user, I can see my account balances” and “As a user, I can cancel my account if it has zero balance.” The teams are assigned to components and it is impossible for either team to work on a single Product Backlog item that cuts through both levels of the architecture (client and server) in order to deliver a complete feature. In that best of worlds, somebody notices it and sees a better way.
At Sprint Planning time, the teams realize that they must carefully choose PBIs that go together in order to deliver a sensible product increment. It takes a “front-end” PBI and a “back-end” PBI to deliver one customer-visible feature. During the sprint, the two teams find themselves slowed because they have to coordinate with each other. Often, they start to point fingers at one another as problems arise that transcend the ability of either team to address independently. Neither team can succeed (i.e., deliver a feature) without the other. Freedom of action, independence, ownership, and commitment start to fade as driving factors and we find ourselves back in the morass of complex, interconnected waterfall-style plans.
Dependencies! Integration! Oy, is there a better way? There is. This is a case where the back-end system is not delivering customer value.
Try this: reorganize the teams. If possible, make them into one single cross-functional scrum team. If there are too many people for a single scrum team, and if that many people are really needed, then create two cross-functional scrum teams. In this case, what I mean by “cross-functional team” is that each team will be able to develop front-end, back-end, and test software in order to deliver fully-formed, fully-tested customer features. They will not need to go outside of themselves in order to complete the PBIs.
With this organization, your single Product Backlog will consist of well-formed items that describe customer-visible value. Cross-team dependencies will go away, since the dependencies between the client and the server components are resolved within each team. No more finger-pointing. No more need for careful coordination. You can even move to separate sprint planning once the two teams have chosen items from the single, unified Product Backlog.
This is a great way to handle client-server architectures in Scrum. All development activity is focused on delivering completed features to the end user, and everything conforms to the best ideals of Agile software development.