Just-in-Time Project Team Right-Sizing
How a microservice architecture can save you time and money on project staffing
Oftentimes, monolithic software development programs will staff many, many resources from the start or bring on only specific roles. For example, analysts first, then months later when specs are finished, engineers; then months later when code is finished, testers, and so on. Even for many scaled Agile delivery programs (SAFe is an example of scaled Agile methodology), some organizations approach the work with a big bang attitude. However, this doesn’t always work efficiently and cost-effectively. A better way to staff projects is to bring on cross-functional teams, assigned to specific domains or features, only when needed.
In practice, using a just-in-time approach, you might ramp up an initial team responsible for high-level analysis and design (which we call Discovery at Slalom Build) made up of a Solution Owner (or Technical Program/Project Manager), an Architect, an Experience Designer, a QE Lead, a DevOps Lead, etc. These people collaborate to own and understand the work with a client. Then, as domains for the work are determined and prioritized, we’ll bring on cross-functional teams for each of those domains.
In modern software development projects, one of the major advantages of using a microservice architecture is that it facilitates bringing on teams when they are needed to deliver on those domains. A happy consequence of this approach is that it not only increases team satisfaction and ownership, but also lowers costs for clients in that it reduces the possibility of paying for resources who aren’t ready to do the work.
A real case study
This case study describes how a microservice architecture can allow you to flex your staffing as needed to support different domains and client needs.
In a large, complex, longer-term program with a client that provides middleware between restaurants’ Point of Sale (POS) systems and food delivery aggregators, Slalom Build identified that the core Catalog and Order domains needed to start their work first because other domains or features would be dependent upon work done on these first two. This allowed the team to focus and establish working patterns and practices. Over time we ramped up teams for Menu Publishing, Identity & Access, and others.
It was an intentional choice to spin up small, cross-functional teams rather than bring everyone on all at once, so that teams were less likely to be blocked by each other and the right work was being done at the right time. Lines of communication were open and maximized while the initial teams were in start up mode, relieving a lot of the drag and bottlenecks that can happen when you try to start up something large all at once.
As new milestones, increments, or initiatives are needed, teams can be pivoted to start the next thing without having to ramp up from scratch on everything. And it allows more latitude for shifting skill sets as needed. For instance, at the beginning of this program we might need backend specialists only, but later milestones might need more frontend or full stack engineers. A microservices architecture better allows for the right skill set at the right time. Team domains were also flexible, for instance when the Identity & Access team completed their initial efforts, they were re-assigned to tackle the Administrative UI API Layer.
This kind of approach allowed planning and development to progress more smoothly and reduced dependencies between domains. The Menu Publishing team was not constantly waiting on the Catalog team because the Catalog team had gotten a head start. In addition, each team felt a greater sense of ownership and accountability for the full lifecycle of work, from initial design to production code, because there were not the usual silos between functions. All team members were involved in the process from story development through release, minimizing hand-offs. This goes a long way towards building trust within and across domains, increasing the number of high-functioning teams.
What’s more, Slalom Build plans for our own eventual departure from day one with a strong desire to ensure the client deeply understands the product we’ve built together and how to operationalize or run it. On a program like the one described in this article, we integrated client team members with our teams at the beginning. The plan was always to ramp down Slalom teams over time while simultaneously ramping up client teams. And because of the nature of the microservice architecture, we were able to shift responsibility in discrete sections to our client teams instead of all at once. Our domain-driven architecture allowed client team members to take ownership of domains in smaller pieces, rather than a full handover of everything at the end of our engagement.
Another benefit was that as individual resources needed to leave the program for whatever reason, we didn’t lose as much domain knowledge. That one resource could be backfilled (usually with some overlap with whomever they were replacing) while the rest of the team was still present to provide continuity in domain knowledge and ownership. Working in domain-driven, cross-functional teams where each team had client resources and Slalom Build resources partnered meant greater continuity in the event one single resource left the program.
The graph below shows the real staffing levels for the program. The top grey line reflects the total program resources (combined Slalom Build and Client) each week, the middle blue line represents the count of Slalom resources, and the bottom red line represents the client resources. You can see where selecting a staggered, team-based ramp up over the first couple of weeks achieved two primary goals:
- Saving the client money by not having them pay for prematurely allocated resources.
- Reducing low productivity and team frustration by ensuring the program was ready with work in the backlog as each team came on board.
The same fundamental goals were met by the way we approached Slalom ramp down and client ramp up over time.
Lessons learned
In any project there are impactful learnings, and this was no different. Below are some of the major lessons learned:
- Do bring on teams (not individual resources) based on domains when needed. Working on everything all at once can cause frequent traffic jams that are avoidable.
- Do not bring on all possible teams or resources at once.
- Do determine initial domains as early as possible and then prioritize based on what you think are the technical dependencies.
- Do break up work into the smallest possible chunks.
- Do make teams cross functional.
- Do plan for controlled ramp up and ramp down.
- As work on a specific domain winds down, do look for and plan for opportunities to repurpose that whole domain team — rather than rolling them all off and having to roll on completely new resources later.
- Do plan for some transition to operational teams from day one.
- Do not bring on resources only from one role or function first, and then another, and then another — bring them on in cross-functional teams.
- Do not bring on delivery resources until you have a good sense of the domains to be delivered and their technical dependencies at a high level.
In the end, using a microservices architecture better supported this kind of program staffing, which saved the client time in the sense of having project teams productive rather than churning or waiting unnecessarily as well as money in the sense of having resources allocated to the program too soon or too long. A microservices architecture allowed for a right-sized staffing model throughout the life of the engagement.
