Scaling With Speed: Growing a Team Overnight

Introduction

WWT recently partnered with a company that engaged WWT with a request to become their preferred partner for completely rebuilding the foundation of their SaaS platform. 

The initial discovery phase generated an extremely deep and broad story map of potential work. Unfortunately, this — along with pressure to move quickly — led to scope misalignment. As a result of that misalignment, the customer inferred that the WWT team would complete more work than was realistically possible. On top of that, the customer's requirement for the team to deliver the "minimum marketable product (MMP)" by a specific deadline created a triple constraint: a fixed scope, timeline and budget. 

After a month of the team working as hard as they could but not making as much progress as needed to make the deadline, WWT presented the customer with three options: 

1. Radically reduce the amount of work associated with the definition of MMP.
2. Sacrifice quality.
3. Significantly increase the team's size to ramp up velocity.

After several executive-level discussions, we decided that the best path forward was option #3: scale the team-up.

The challenge

Scaling the team was laced with its own challenges and obstacles. 

First, it is widely accepted that the negative implications of increasing team size greatly outweigh the positives in the short term. This is largely due to the ramp-up time for the existing team and the new team members to adjust to the new working environment, including system access, meeting and other cadences, organizational dynamics, team culture, learning curves, etc. 

Second, the customer and WWT were already working through closing a handful of skill gaps that existed.

Third, most team members were new to WWT, resulting in unfamiliarity with WWT's standard processes, escalations and ways of working.

How we made it work

Organizational design 

Before anyone was officially onboarded, WWT leadership mapped out a project organization design consisting of two parallel Feature Delivery Teams and a separate dedicated Systems Team. The two Feature Delivery Teams each had a Tech Lead, Agile Business Analyst, Quality Advocate (QA), Front End Engineer (FEE) and multiple pairs of developers having both front-end and back-end skillsets. In comparison, the dedicated Systems Team consisted of a Delivery Lead, Tech Lead, Solutions Architect, Security Engineer and multiple DevOps Consultant/Delivery Engineers to work alongside the Cloud Application Architects and Azure Platform Architects.

Staffing skill gaps

Customer PO: The customer Product Owner (PO) was brand new to the role, and a large portion of the effort was focused on upskilling them on how to determine what was needed for the MMP, as well as the importance of frequent value delivery and fast feedback loops. Eventually, their mindset shifted from "I need it all by the deadline" to "this is what the team can achieve by the deadline," enabling a more productive discussion and eventual decisions regarding priority and messaging to the broader stakeholders. This change was essential for allowing the team to be more agile in their communication with the customer and led to the team's current messaging: effective communications each week that are clearly understood by the customer.

DevOps/FEE/solution architecture: In addition, the WWT Delivery Engineer was working in an unfamiliar technology and methodology, which resulted in a significant delay in standing up environments for the initial deployment, and two other roles (Front End Engineer and Solution Architect) had only recently been identified as necessary components. Up to this point in the project, the DevOps piece of the puzzle was incomplete. By dedicating ample resources, DevOps helped ensure the architecture was sound and that environments were stood up, allowing for the successful delivery of the application to a production environment while also keeping an eye out for potential needs and impacts to feature work. 

Leadership bandwidth: Additionally, the project's leadership team included the Delivery Lead, Product Owner, Agile Coach, Solution Architect, two Feature Team Tech Leads, and a Systems Team Delivery Lead and Tech Lead, all of whom worked to promote coordination, communication and visibility amongst all teams and the customer.

Onboarding

As the original 15-person team was preparing to scale, the 20 new team members were "read in" on the state of the project and encouraged to be mindful, empathetic and kind to a team that was clearly struggling. The new team members created a temporary "backup" communication channel for asking questions that the existing team wasn't ready or able to answer, which gave them an outlet for their concerns, getting higher quality information and not feeling lost.

Shortly thereafter, a full day was dedicated to rapidly bringing the new team members up to speed, including:

• The Tech Lead led training on the extensive documentation prepared by the existing team.
• The WWT Product Owner presented the business overview, product vision, outcomes to be achieved and the roadmap.
• The existing delivery team reviewed the work completed to date.
• Expedited access requests to customer IT systems.

And most importantly, everyone came in with the right mindset and attitude, including the customer, which was partly due to our core values, but it was also cultivated and nurtured in the early days. It takes a complete team effort to have a well-coordinated and successful onboarding process. Everyone must put their egos aside and be ready and willing to roll up their sleeves and help wherever needed.

Communication

Daily leadership sync: Once the 35-person team was up and running, the leadership team established a series of Leadership Standups using a Trello board to track the highest priority items, make decisions and keep in sync on the daily happenings across the three teams. Constantly staying in sync with one another allowed us to identify dependencies and blockers across teams, to course-correct quickly and to maintain internal alignment. Externally, this alignment helped us to communicate with the customer more effectively during Weekly Status meetings and Sprint Reviews and allowed our messaging to stay on point week over week. 

Feature review: In addition, keeping everyone focused on building the right thing using a Feature Review meeting provided the right amount of value to the delivery team. The process included in-depth requirements gathering, usability testing, full-team attendance, mockups or prototypes that we had previously tested with end-users, and a business overview explaining why the feature is important and how it fits into the bigger picture, business process flows (when applicable). Once all those items were covered, the team had plenty of time to discuss complexities, dependencies and how they think the work will be broken down into stories. Feature Reviews increased team efficiency by providing a shared understanding of the feature's acceptance criteria and scope, level of complexity of the work involved, and a much smoother time kicking off story writing because everyone had the needed context for understanding.

Project scope/managing client expectations

Scope refinement: Our approach was focused more on outcomes than features, enabling us to negotiate what would be considered "enough" to satisfy each outcome for the MMP. Asking the customer PO questions like, "what is the minimum amount of functionality we need to build to release and get feedback?" helped reduce how deep we would go in planning and development. Repeatedly asking questions like, "does building this thing help achieve the outcome we are working towards?" allowed us to keep reducing scope but, more importantly, allowed us to keep working through the highest priority items at the right depth of development. 

Delivery of working software: With the release of the MMP, the team successfully delivered on time and in full, which started getting the customer excited about selling the application. From there, we were able to settle into a steady routine of setting monthly milestones driven completely from a prioritized product roadmap.

Conclusion

While there have been many lessons learned along the way, here are a few to take away from this project's success:

1. Be prepared to find creative ways to solve staffing and skill gaps, adjust the team structure to fit the project, and over-communicate.
2. Dramatic team scaling, while not easy or ideal, is possible with the right people, attitude and communication.
3. Iteratively delivering working software is one of the easiest tools for managing client expectations, and it helps ensure alignment to the outcomes the customer is trying to achieve.