Aligning Scrum Teams - Part 3: - Pulling it all together

In the last 2 blogs I discussed the challenges with component based distributed teams and how to overcome those challenges with solid pre-planning. This is the final of the 3 part blogs where I want to discuss how to pull everything together.

Once a solid pre-plan is done, it's time to zero in on the iteration goal a.k.a. the 'Macro' goal (A common goal shared for the iteration by each scrum team) and execute to it.

Each Team should have a detailed planning meeting. I had covered the planning in one of my earlier blogs.

In addition to what I mentioned in the blog for multiple component teams, I would advocate the following suggestions be implemented during the detailed planning.

• The goal of detailed planning meeting is to ensure everyone within the team understands the Macro Goal shared by each team.
• Everyone in the team should clearly understand the stories for the Sprint and how they directly or indirectly help towards the Macro goal.
• Have white board sessions for detailed design, identify granular tasks, and assign names and hours to the assigned tasks as per the team's capacity.
• One important aspect is to identify a plan to resolve dependencies between various teams. For instance, you might have a producer team that serves multiple consuming teams. It is very important to lay out exactly what will be delivered and when it would be delivered, so that consuming parties can plan their iteration properly.
• Let's take an example, Team 'Infra' is an infrastructure team and is planning to deliver stories S1 for Team 'UI', S2 for Team 'Security', S3 for Team 'App' in the given iteration. Team 'Infra', based on their resources, can work on S1, S2 and S3 in parallel or in serial fashion. Whatever approach Team 'Infra' takes, it's their responsibility to inform the consuming teams on when they can expect the deliveries. This will help the other teams to put an accurate integration plan in place.

After each team is done with the detailed planning meeting, they should share the planning notes with the other teams. The notes should clearly identify risks and issues in achieving the 'Macro' goal. However, the notes itself are not enough in a large program with multiple scrum teams. There has to be an overseeing body a.k.a the "Scrum of Scrums" (SoS), where representatives from each team (Tech lead, Scrum Master) attend the meeting on a regular basis to provide their teams updates.

The goal of SoS is to understand what each team have achieved so far, what they are working on next, any issues/risks they might have, resolving dependencies, any new items identified after the planning meeting that might impact the Macro goal, etc. The frequency of how often the SoS should happen can be ironed out between teams, but I would recommend that teams meet at least 2 times a week.

The key for success in multiple geographically dispersed component teams is to have "Transparency" within and across teams and to create an environment of "Open Communication" for teams to self organize and start delivering Macro goal iteration after iteration.

Aligning Scrum Teams - Part 2: - The Pre-planning

The Part 1 blog discussed the challenges one might face with multiple component based scrum teams. In this blog let me discuss a solution to make these enterprise scrums deliver consistent results.

To start with, the team would need a solid pre-planning to put various dots in place before the actual planning happens. It's in fact more than that

1. Define goals - This is a big ticket item and you want to nail this accurately. Everyone should know where they are and where they are planning to go.
• The long term goal that defines the goal of the overall release.
• The short term goal, i.e. the incremental goal to all teams for the sprint. It should accurately define what teams will achieve in unison at the end of iteration.
2. Form a governing body that oversees the activities of each scrum team. The role of this governing body is to:
• Define short term and long term goals for the teams with help of stakeholders.
• Have regular weekly or bi-weekly meetings with participation of subject matter experts (SMEs) of various scrum teams. The function of this team is to discuss the short term goal and groom backlog for each team before the next planning session begins. All dependencies and exceptions should be clearly documented and monitored at regular intervals.
3. Make use of UI mocks where possible and educate the scrum teams on what you are trying to build. Knowing how the final product will look help teams put things into correct perspective. E.g. If the team knew how Amazon's website looks it would be easy to build the same.
4. Finally, each team should clearly understand objectives of the next iteration and ensure all stories planned directly or indirectly contribute ONLY to the above goals.

In the next blog, I will take this topic a step further and discuss how to gel this together and make certain teams are marching towards the common goal. 

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.