Marek Ziółkowski
Chief Solutions Officer
Łukasz Szramko
Delivery Leader
Magdalena Jackiewicz
Editorial Expert
Magdalena Jackiewicz
Reviewed by a tech expert

10 rules CTOs should follow to succeed at building and leading Agile development teams

#Sales
#Sales
#Sales
#Sales
Read this articles in:
EN
PL

An effective approach to managing a growing Agile development team is crucial for releasing high-quality digital tools as well as the overall success of any project. However, when your team grows, keeping it under control may become more challenging.

I spoke to Łukasz Szramko, our Delivery Leader, and Marek Ziółkowski, Chief Solutions Officer, to find out what are the key management strategies employed at RST to manage rapidly scaling development teams. Our management team swears by these five rules:

Rule #1: Ensure a good onboarding mechanism

The first thing that must be ensured when a new employee joins your Agile team in is onboarding and the key to doing it right is to ensure everybody understands the product, technology and project goals inside out. Communicating the goals at the very outset is crucial for building an understanding of the overall objectives, which are crucial for efficient teamwork and ultimate project success.

At this point, tools like documentation will help deliver key information whenever you start managing a scaling Agile development team. Keeping an up-to-date documentation will also help to clarify the nomenclature, minimizing the risk of miscommunication issues.

Onboarding will definitely slow down the project to some extent, depending on the newcomers’ competencies and experience, so it has to be taken into account accordingly when planning and managing workloads. It will pay off in the long run: with a thorough knowledge of the product and the technology, the dev team will be able to deliver individual features faster later on.

Rule #2: Instill a sense of ownership

When managing a growing Agile team, many companies make the mistake of waiting to grant newcomers access to the backlog until e.g. they receive relevant permissions, only prolonging the onboarding process even further. In our experience, granting access to the backlog as well as all the existing project documentation not only builds trust between the company and the employee but also greatly increases their sense of ownership for their area of responsibility.

Meanwhile, instilling ownership is one of the best things managers can do to ensure teams work efficiently and effectively. This is especially important when you work on a robust product and your team is composed of several smaller units. Building a sense of responsibility and ownership within specific teams and their individual members will help to increase the quality of the code delivered, as well as ensuring that errors or bugs are swiftly fixed, because they won’t be repaired by another team.

One of our largest clients, Trans.eu, provides logistics solutions in Europe and Asia for cargo carriers and forwarders. If their application or one of its components fails, it can seriously impact the delivery and hence access to goods in specific areas. It’s just an example, but one that illustrates that instilling a solid sense of ownership among your team members is critical for building functional and stable apps.

Rule #3: Scale in accordance with business functions

When managing larger projects that require more than just one dedicated team, some managers can be tempted to organize their entire product team in accordance with technologies in use, or technical functions, dividing them into e.g. backend and frontend. We prefer a different solution, which worked for us in every project (and continues to work!).

We focus on assigning responsibility for a specific business area instead of having a team work on the entire backend, for instance. When a team (or teams) have to focus on multiple aspects of an application at once, they will eventually lose focus. That’s why we always divide our product team into units, where each unit deals with a specific business function, e.g. online payments.

Why? Because a multidisciplinary Agile development team with diverse competencies that takes full ownership for a specific business area is more likely to deliver good results rather than a team that is immersed in several chunks of different application functionalities. Also, it’s easier to manage such semi-independent units.

Rule #4: Embrace the API-first approach

The API-first approach has grown in popularity over the past few years and, in our opinion, it goes hand in hand when you work on an application in which individual teams work on specific business functions.

With the API-first approach, Agile teams have to spend time on defining how individual application components will work with each other before they start developing them. It then allows teams to work in parallel efficiently and increase the time to market individual features. 

At the same time, this approach helps to ensure positive developer experience by ensuring consistency and creating opportunities to reuse code and shortening the learning curve for newcomers. Once again, when managing a growing Agile development team, simplifying workflows will make the process a lot easier.

Rule #5: Scale by transforming your existing teams rather than adding new ones

It’s not advisable to have an Agile development team larger than 9 individuals – you probably know that already. What happens when you do need to bring new people on board and you have a complete team? Should you start building a new one? We strongly advise against it.

From our experience, it’s much better to split the existing team(s) and use them as a starting point for building new teams (responsible for a specific business function, as mentioned earlier). As a next step, you hire experts with the missing skills to complete these newly-formed Agile teams. In that way you ensure that whenever a new team is created, it includes experts with in-depth knowledge of the product, the organization and the culture rather than people who just came on board and don’t have any knowledge about them.

Rule #6: Build a solid work culture based on soft skills

At RST, we are convinced that soft skills are as important as the technical skills of dev team members. For that reason, we invest heavily in building a feedback culture that embraces two-way feedback. Not only do we assess the employee, but the employee also assesses our company and approach to projects. This is our way of ensuring we always find the best solutions to specific issues.

Quote - Marek Ziolkowski

This two-way feedback is not reserved solely for periodic assessments, but is interwoven into all of our working processes: retrospectives, daily planning, creating decision logs. This helps to ensure focusing on the best possible outcomes and maximizing the results. Above all, it makes the task of managing a growing Agile team a lot easier.

Rule #7: Ensure Agile team development

Every time a new member joins a project, the status quo is disrupted. A newcomer will bring new competencies and fill a new role, and the rest of the team will want to (and need to!) understand that role. Some people will naturally look to lead the rest, and that may create tensions. There may also be tensions related to the fact that different specialists will want to solve problems in different ways. Eliminating those tensions is crucial for delivering a quality product in accordance with the schedule.

One way to ensure these issues don’t arise or are solved quickly is to invest in the development of individual team members and the team as a whole. Make sure everyone can progress in accordance with their preferences when opportunities arise. Paying attention to ensuring developer happiness and the overall job satisfaction are also crucial for succeeding at managing any dev team.

Rule #8: Ensure the backlog is prepared for team expansion

Likely, certain elements of the backlog will be interconnected with others, especially if you work with larger projects that require multiple Agile dev teams. Therefore, it’s critical to bring on board additional people when it’s time to begin the specific piece of work they are about to work on. If you don’t do that, you may end up having people on board while they remain redundant and exceed the client’s budget unnecessarily.

To avoid such a scenario, ensure the vision of the product has been thoroughly clarified before you bring new people on board. This will help you analyze the backlog accordingly and organize workloads into independent segments, or, will help you understand that the backlog is so complex that work cannot be performed independently. In any case, you will be able to avoid chaos and manage your Agile development team more efficiently.

Rule #9: Have a Lead overlook the work

No matter the size of the Agile dev team you’re managing, there can always be misunderstandings about the requirements. These can result from the different levels of experience of the individual team members, or chaotic communication between them. With that, it’s also possible that you will hire a junior developer to support the project, while in fact you need to hire a mid-level specialist.

The best way to avoid these scenarios is to have a Team Lead, Tech Lead or Architect responsible for making crucial decisions, guiding the rest of the team and looking out for all the technical needs that arise. Streamlining communications in this way will ensure clarity among the entire Agile team as well as making good decisions when it comes to filling project staffing needs.

Rule #10: Set solid communication mechanisms

Communication issues are likely to occur in any Agile dev team, especially when the team consists of specialists with different levels of expertise. Setting the relevant communication mechanisms is crucial for eliminating those issues.

In this case, again, a thorough project documentation will not only provide guidance and instructions for newcomers, but will help to standardize nomenclature used in the project.

In addition, managers in charge of managing growing development teams should never underestimate the power of tools like the Definition of Done that help to establish the relevant delivery criteria. When working with them, focus on defining the results that will maximize the quality of the product and project outcomes.

Are you interested in commissioning a project to RST Software?

At RST, we pay great attention to delivering high quality digital products through proven leadership strategies that work also when managing growing Agile teams. We’ve helped numerous customers globally to deliver bespoke digital tools that support their growth. If you’re interested in working with us, feel free to explore our website where you’ll find out more about work culture and principles, as well as our areas of expertise, which include location-based productscustom maps, data visualization tools, media streaming, chat applications and others. If you have specific questions, contact me directly at magda@rst.software and I’ll make sure they’re answered.

People also ask

No items found.
Want more posts from the author?
Read more
Read more
Read more

Want to read more?

Project Management

Agile health metrics: how to know when your project is doomed?

Learn how Agile health metrics can signal project risks and identify potential pitfalls. Ensure project success with proactive insights.
Project Management

How to effectively manage risk in Scrum projects? Proven tools and strategies

Master risk management in Scrum projects with proven tools and strategies. Ensure project success through informed decisions.
Project Management

Agile roles and responsibilities explained: Scrum Master, Product Owner, Development Team

Gain insights into Agile roles - Scrum Master, Product Owner, and Development Team. Optimize collaboration for Agile success.
No results found.
There are no results with this criteria. Try changing your search.
en