Scaled scrum tactic

A scaled scrum tactic – Team of Teams, A real life example

A program team of over 40 people decided to move to Agile from their traditional development practices. The program was old and had been in existence for over 6 years. In these 6 years they had released multiple versions of their software product to their customers. In the rush to satisfy the customers they had ignored the basic hygiene of following the good engineering best practices. So, along with their move to Agile they had also inherited a considerably poorly maintained legacy code. There was tight coupling between the various software components in the entire system; The majority of  the code files had 10000+ lines of code with plenty of code duplication; there was poor technical documentation on how the overall system interacted; the entire testing effort was manual. There were certain components which when modified, in most instances, introduced regressions in the existing system.  Even though the teams spent significant time testing the entire end-to-end system, the overall confidence on the quality of the deliverable was considerably low.

The program formed 4 cross-functional Scrum Teams and started sprinting. The dysfunctions from the poorly maintained legacy code started surfacing and becoming more evident.The teams struggled to meet their planned sprint forecast. The development team’s time spent testing the new features was exponentially higher than it took to build those features. In addition, most of the times the development teams kept busy fixing unplanned production defects to maintain the business continuity. The deliveries of new business features were at an all time low which made the sponsors very anxious. The scrum teams collaborated, brainstormed and came to a common conclusion that to accelerate product delivery, one of the first steps was to reduce the manual test effort spent by the development teams. They decided to write end-to-end automated service level tests to cut down the time teams spent on manual testing as well as to gain enough confidence in their deliveries. The product owner helped by ordering the PBIs for the service level automated tests higher in the product backlog. The skill-sets required to develop the service level tests were spread across multiple scrum teams. Something different had to be thought of to overcome the above challenge without having a major impact on the business continuity. A new scaled scrum tactic of “Team of Teams” was introduced: “Team of Teams” is a concept where members with the right skill-set from the existing scrum teams participate to form a new Scrum team for a short duration of a sprint or 2 to solve a very focused problem. The 4 Scrum Teams self-organized and quickly identified 2 development engineers from each team with the correct skill-set to participate in the new “Team of Teams”.

One of the Scrum Masters from the existing teams volunteered to help with Scrum Master duties for the newly formed Scrum team. The new “Team of Teams” decided to operate in “Boot Camp” mode and they co-located themselves in a conference room to allow maximum collaboration. In the first few days of the sprint, the team carved out a homegrown test framework and added a couple of end-to-end tests to validate the framework. A quick review of the framework with the original 4 scrum teams and the Product owner validated their hypothesis. The newly formed team of teams worked through their sprint backlog and carved out 17 rich test scenarios in that sprint. The “Team of Teams” had accomplished their mission of writing sufficient automated test scenarios to reduce the manual testing effort thereby accelerating the product delivery. The team members from the newly formed team of teams then returned back to their original scrum team where they continued to build additional test scenarios. Having led many Agile adoptions across multiple organizations, I have found scaling tactic like “team of teams” to be very helpful when a very focused problem has to be addressed.  The “Team of Teams” tactic has also been explored for strategizing the product vision and the product backlog refinement with multiple scrum teams and overall the outcome has been quite rewarding. I would be happy to hear some scaling tactics you have used and learn from your experiences.

Redwood trees in Muir woods

A Collaboration Lesson from the Redwood Trees

The Redwood trees in Muir woods, San Francisco, are some of the tallest and widest trees on planet earth. Some trees are so wide, that it takes 40 grown up adults to make one circle around it! These trees are known to live for thousands of years and each year they grow bigger and bigger.  Most tall trees have roots that go deep down to keep them stable. For example, the roots of the palm tree are as deep as the height of the tree. However, research tells us that though the Redwood trees are the tallest trees on earth, their roots are not deep at all. California has gone through a tremendous number of hurricanes, cyclones, windstorms, tornadoes and earthquakes in the past 2000 years. Any normal tree would have been crushed instantly, but not the Redwood trees. They’ve been standing tall and strong ever since. So, what is the secret behind these trees?

It seems the Redwood trees have some special mystical power. The roots grow outwards instead of deep under the ground. And when these roots come in contact with roots of the another Redwood tree, they wrap around each other multiple times and form a strong bond. Each tree shares a bond with another tree through its roots, and eventually, every single Redwood tree is connected to each other. The roots hold on to one another through the harshest of weather, and keep the family of trees standing tall and strong, together.

The roots of older and wiser trees hold on to the roots of trees just beginning to grow. They’re basically telling them —“You’ll grow big and strong. Reach for the sky and we’ll help you get there. You have the strength of hundreds of trees in the forest because we’re all connected. Our strength is shared together, and it grows together.”


If we dig deeper and try to understand self-organization, a principle very much needed for being Agile, we will realize that collaboration and co-operation are the basic attributes needed to self-organize. Similar to the Redwood trees, Agile team members need to collaborate so that the entire team rises higher and higher. This interconnection helps each individual to grow, inspire and motivate each other. It builds trust and transparency, and at the same time a feeling of safety to explore new hypothesis, innovate and produce a quality deliverable to the customer, with a feeling of satisfaction. 
The Redwood tree example was shared in one of the spiritual  discourses and I found this example so very relevant to some of the Agile values and principles.