Aligning Scrum Teams - Part 1: - The Challenges

Let me start this blog with an example - The goal of the next sprint is to deliver integrated functionality of features f1, f2, and f3 by scrum teams s1, s2 and s3.

If scrums teams are organized as Feature Teams (i.e. Scrum team formed with experienced members from UI, DB, Server, Testing components), it is very easy to divide the work as each team is contained and self sufficient to deliver the needed functionality. Each scrum team can be assigned one feature and they can accomplish end to end functionality independently. In the above example the possible assignment could be Scrum team s1 works on feature f1, Scrum team s2 works on feature f2 and Scrum team s3 works on feature f3.

However if organizations have large distributed teams, forming Feature Teams might not be practical due to lack of site affinity.  And most likely scrum teams will end up being Component Teams or specialized teams (e.g. UI team, Database team, Server team, etc.). In the above example the work division might look like this -

The UI team s1 works on UI components for feature f1, f2 and f3 i.e. f1.UI, f2.UI and f3.UI

Similarly, the Database team s2 = f1.Database, f2.Database and f3.Database

And the Server team s3 = f1.Server, f2.Server and f3.Server

Developing a product using Component Teams presents its own set of challenges. Some possible issues these teams might have if they aren't aligned correctly are:

1.            Interpreting the exact requirements for each features and prioritizing them correctly could be challenging. E.g. Team s3 must correctly interpret what is needed for feature f1, f2 and f3. They should also determine the priority order for each feature and deliver them accordingly.

2.            Coordinating delivery of functionality so dependent parties’ code is not broken. E.g. for Feature f1, teams s1, s2 and s3 have to coordinate well on their deliveries. If s3 misses on its f1.Server delivery it would miss on meeting end to end f1 functionality.

3.            Just in time development i.e. developing just enough to meet the needed functionality might not happen. E.g. Team s1 might develop too little or too much UI component for f1.

4.            There can be integration issues. E.g Feature f1, f2 and f3 are working independently without issues, but when they are integrated nothing works.

5.            End to end testing of the entire system can be challenging as QA engineers will test functionality within their Scrum only. E.g. QA engineers from Scrum s2 will only test DataBase functionality for f1, f2 and f3. QA engineers for other Scrums will do the same within their scrums.

6.            In the example I listed we are just considering 3 Component Scrum Teams developing 3 features. Most likely for an enterprise product there will be lot many more teams and features under development and thus the complexity increases exponentially.

7.            And Many more...

For global teams pre-planning becomes a must. A lot of details need to be ironed out upfront before the actual Sprint planning happens. Each team needs to work in proactive mode rather than reactive mode to build the right functionality. In the next blog I will list out some solid steps on how to align these distributed scrum teams.