Table of Contents
While scaling, Businesses and Startups face many difficulties in keeping business as usual and the increasing growth of demand in application improvements and new features. Usually it is addressed with scaling of capacity. At a first glance, larger teams are much faster, however, there is always a burden of coordinating efforts. In this article you will discover the efficient practices presented by Altamira expert – Alexandra Rostovtseva, telling how to successfully scale your team while maintaining your efficiency.
Keeping the circle of recruitment - off-boarding during the team scaling
Due to the high demand on software engineers, the lack of those at the nearshore and offshore market, and rising cost of the software development, a lot of companies start to re-evaluate the efficiency of the talents they already have and re-assess the way they approach the team scaling.
The problem becomes so huge that even Google development team, one of the top tech companies is cutting their in-house software development teams, and despite this, the efficiency and speed of production remains at the same level. The paradox is that the software developers and other experts, being part of the software team development infrastructure, agree with the statement that we need to switch from the approach of scaling through the increase of capacity to the approach of more vertical or efficient scaling. In Altamira, we get a lot of requests to add XX number of engineers to the team starting from tomorrow because the Scaling Business is so in a hurry to finally fix the release schedule, get the product to market or even to make a stable bug free release, that the only way to do this they see in ASAP team scaling.
The irony is that it leads to exactly the opposite result, Team Leads and existing team get overloaded even more, slowing the process down, new software engineers are not onboarded properly, which leads to low retention rates and necessity to again onboard more and more people, keeping the circle of recruitment to off-boarding. The working capital is burnt, and the product releases still do not reach their end users, which causes the business stalling.
The solution: Synchronization workshops for software development team
In order to find the solutions, in Altamira we have out together the framework that allows to answer two questions that help to build the plan of existing the business stalling and get to the “smart” scaling of the pods, squads and software teams. The questions are:
1. Why this happens?
2. How big the existing problem is?
By finding the answer to these two questions, you can form the reliable plan on what to do next and how to move forward. In Altamira we do the discovery of these two items by having the so called “TSPP Workshop” that helps to form the recovery plan. Below we are sharing some of our exclusive materials as well our experience and best practices in finding the way out of the circle of overload, growing overhead, and lack of product development progress.
TSPP Workshop: Discussing the critical points
The workshop itself consists of several meetings or as we call them sessions, each of them needs to be driven by a facilitator. It is aimed at a deeper understanding of the current situation inside the team, core processes and responsibilities, identification of critical points and processes to focus on and improve.
Who can be a facilitator during the team scaling workshop?
We recommend picking assertive person non-involved into the actual development process of the team but that is aware of the development cycle to the sufficient level to understand the conversation, keep it active and point out the missed point for conversation. By having someone non-involved into actual software development process or project that would be discussed allows to keep the neutral “cold” head in moderating the hot topic.
Who are participants of the workshop?
Very often teach leaders, management and executives think they know what the problem is, missing the whole hidden gold of the knowledge that actual teams hold. So for the sake of this workshop, it is recommended to have actual product development teams working on the project be the main core of participants in the workshop.
Other stakeholders such as marketing, product teams, business executives can also be invited at least for the first session to identify their goals and align with the development team.
Expert tip
For bigger team organization the framework can be scaled, where there are the workshops at the level of the development teams, development squads or development pods, and then the representative of each team (Team Lead or Project Managers, engineering managers, Human Resources Officers, etc.) takes part in the common workshop that accumulates all the problems gathered within the previous workshops.
However, the team composition needs to at least include stakeholders that cover the areas, based on which the full workshop is built, which is:
- Technology
- Scope
- People
- Processes
- Business goals representative
Apart of the existing team, we in Altamira, being the usual software development partner to our customers, take part too with a product owner or stakeholder representative mirroring the roles of the in-house team and adding the missing roles, if there are no such in the already working squad. This allows to get 360 view on all aspects of the project, enables to boost productivity, distribute core tasks and ensure efficient business strategy.
Session #1 – Where our ship needs to sail?
The team that is supposed to meet the goals that you put for it should not just understand what it’s doing but also be aligned in the approaches, methods it uses.
Our best customer relationships were built when we were able to align the values that a client’s team sticks to and those that we propagate. And this goes from company mission, vision, values and strategy and down to short term, middle term and long term goals.
In order to build the right culture in the software teams where each member is kept interested and involved, it is necessary to bring the missions and values from the paper to the actual work routine of a software developers. By communicating this down to the software development team and teaching the managers to apply those during the regular day-to-day work would allows to gain:
- More involved software development team
- Culturally aligned team
- Collaborative distributed team, in-house team or dedicated team
- Team working towards the company goals with their understanding and realization.
- Better retention team rates, since when team feels they are contributing to one mutual goal they are more willing to stay in such environment. And this is especially important in the growing race of demand for software developers.
Purpose of this session is to remind what exactly we are trying to reach aka what our “Mission, Vision, Goals” are as well as what methods we are ready to use to reach them aka “Values”. This allows to bring all distributed teams or dedicated teams to the same cultural environment around the goals they need to meet. But since the context can change over the period, we want to differentiate between “Now”, “Soon” and “Later” time scale, where Mission, Visions and Values will stay the same across time, but the actual software development team goals and Company Goals are going to change.
The outcome of this meeting should be a fully filled canvas concentrated around the goals and company’s mission that we have put for the outlined period of time and each scaling software team member should understand those.
Session #2 – Is our ship able to sail?
So once we know where our ship needs to sail, now we need to understand what the actual state of our ship is, which means to start talking about all the problems (the big elephant in the room) that everyone knows about but keeps unspoken due to deadlines, urgencies, lost revenues, psychological safety etc.
This is a very sensitive session, where facilitator plays a key role, cause needs to make sure the team focuses on naming the problems and not blaming. Usually, facilitator would address people to values that were aligned during the previous session and have them in front of the team.
If the development team is an external software engineering agency team, not the in –house one, this is a particularly challenging exercise. In this case you might just ask for the outcomes of this session and not participate at all, as a client, to make sure the software development agency gets transparent results. The problems that we need to outline are within the categories that we already mentioned above, which are:
- Technology
- Scope
- People
- Processes
Expert tip
Some of the projects also require adding Quality or Infrastructure categories, smaller ones can be covered within technologies section.
This is actually very similar to a scrum Retro session but where we do retro on the current state of the project rather than a sprint. Feel free to use the canvas below to fixate the outcomes:
Usually if the right environment was built, you get this canvas filled very quickly, since the development multiple teams are hungry to finally tell and get the overall view of troubles they see.
Expert tip
You can cover several projects at the same time, this will allow to spot the systematic problems that are repetitive across program or organization.
During the Retro session, talk to the team and make them feel comfortable talking about challenges and problems they face. E.g. it can be “lack of time for legacy code”, “no well-established processes” at tech level, or “no backlog vision for 6m”, or “overloaded people that keep working extra hours”, or “lack of regular releases”.
Expert tip
Canvas categories can be extended with the executives goals such as “problems from sales, marketing, etc” that have direct impact on software, which can be particularly useful for the tech bases scaling companies.
Since very often Altamira works as a contractor in distributed teams, we always have this workshop before the engagement with the client and their teams. This allows to build the proper level of cooperation and trust between the client’s in-house team and our team.
Session #3 – Now, Soon, Later plan for scaling team management
So now we know where our ship needs to sail and we know if our ship might sink as it goes there. So, the Session #3 should help you to put the plan in place. If you turn to some consultant company that is supposed to help with the software engineering practices, they will provide you with 100 pages long pdf file telling you that you need to invest thousands of dollars into rewriting whatever you have and then maybe in 6m you can get to quicker pace of releases and finally be up to speed with the market.
Eventually this never happens or business just doesn’t have the luxury to stop development for such a long time. The aim of Session #3 is to find a compromise between the best practice, the perfect state and the actual business needs.
What can we do NOW just enough to get to to Now goals and Fix the most urgent problems? Usually, the answers would be around releasing capacity of the current development team.
Then we focus on what can be done SOON? What actions do we need to take to get better to the “perfect” state as we see it that would allow us to meet the Soon goals and not have our ship sink.
And the same with the Later.
Exercise 1
By having the canvas from Session 2 in front of your eyes, fill in the solutions that your software development team suggests. At this stage do not let the scaling software teams argue much, healthy discussion is acceptable though, write down everything they come up with using the next canvas.
Exercise 2
When you have the possible solutions filled in, you need to validate them across the Goals, Mission, Vision and Values.
This should help to align on which problems it makes sense to concentrate now and which problems can wait till later or soon stage. So, on each of the problems within each section you need to answer the set of questions:
Does this suggested solution contribute to mission or vision completion? Or this solution contradicts those?
The answer to this question should help you to decrease the number of suggestions on the canvas, leaving the ones that really contribute the overall business goal. Name the problem and then with short discussion cross out those solutions that are not contributing to it, or even break those from the board.
Is the suggested solution within our values? Does it break any of our values?
This should allow to remove those suggested options that break the culture you want to build within the team and decrease the number of options even more. As you keep doing this workshop in your organization, the number of suggested solutions that break the values will get decreased because scaling software teams will learn not to even suggest such, building the right culture.
Does this problem/challenge keep us from reaching our NOW goals? Does this problem/challenge keep us from reaching our SOON goals? Does this problem/challenge keep us from reaching our LATER goals?
The answers to these questions should allow you to play with the solutions and revise their arrangement within Now, Soon, Later columns by properly prioritizing those across these three-time spans. You can shift solutions that resolve the later goals, to the later column, releasing the time of the scaling software teams to concentrate on more urgent Now things.
Outcomes
The outcome you are looking for is the clear Now, Soon, Later plan, which is a compromise between what scaling software teams feel should be done from tech perspective for ship not to sink and what business needs so that ship can keep sailing and reaching that goals. This plan is later put into the action plan and is tracked across the built timeline.
This framework allows to concentrate on fixing the problems and meeting the most immediate team growth goals, instead of procrastinating on the huge scope of problems & goals that different team put in front of you, and which are often contradictory and confusing. It also allows to release some of the team capacity from doing things that are not urgent right now but were assigned by mistake, misunderstanding, or other reasons.
In the end you will notice that you do not need to add more developers to meet the “Now” goals, but you would probably need them for Soon or Later stage, and by that time you will be able to set everything you need to have them successful in their jobs, like the right knowledge base, established communication channels, onboarding plans, clear scope to work on, Tech Leads and project management specialists that are happy they get to work with new team members instead of feeling the burden.
Altamira has successfully applied this framework on a number of projects. It works well with highly disciplined web and mobile development teams or with fast scaling startup teams that are at their 4th or 5th round of investment when they are looking towards showing the KPIs to investors and thus concentrated on fast results.
At the same time this framework is challenging with the Enterprise level clients, where cultural shift is required, and communication alignment is usually a challenge. However if you have the buy-in from the Business Executives, especially those that just came into the teams management and struggle in assessing and coordinating the current state of technology themselves, the framework is a big help and usually they are very supportive about it, which eventually leads to success and cultural shift.
This effort not only brings you to the actual alignment of the general vision of the state of your project, but also gives the environment in which scaling development team can talk free about the problems they experience during the work on software development, engages them into the product and as result teams become more collaborative, involved, which eventually leads to higher retention rates.
Easy and most importantly in-time recruitment of team members, release of capacity of current teams, higher retention rates, allow the efficient smart scaling with lower expenses rates versus the horizontal increase of capacities by throwing more talents to deal with the same problems.