In terms of increasing or elevating your team’s productivity, there are a lot of ideas, things to be measured, technical aspects, and management styles that contribute to that goal.
I’m sharing some perspectives, knowledge, and own experiences with the aim of helping teams to experiment with those points that they have never tried before.
We could try improving our teams through soft-skills like contributing to their happiness or focus on hard-skills like quality or coding delivery.
Some personal experiences include defining team members’ goals together, creating a ‘Team-coffee’ meeting after each sprint, or improving our coding delivery process.
Let’s delve deeper into more ideas below.
1. Keep it simple
In my opinion, it doesn’t matter if we’re discussing about managerial staff, architectural decisions, or something else; just please begin at this point–don’t reinvent the wheel.
Of course, we need to guarantee high quality and follow good practices. But be pragmatic and keep things simple; you will be able to scale them up but avoid over-engineering. Because our industry is dynamic, changes quickly, and cutting-edge technologies emerge all the time.
I suffered decisions like using a programming language just because it was fancy, and we had the need to re-develop features after some months, create a monster-service connected to different microservices in a different way with no sense because each team decided a different way for their services to be connected, or facing issues because we forced ourselves to include new technologies in architectural solutions.
2. Define an MVP
Our developer or technician mindset is usually problem-solving oriented, and we aim to make everything possible for the business. However, it’s crucial to be smart, realistic, and honest. One effective way to deliver a product is to first define and design an MVP(Minimum Viable Product).
In one of the teams I managed, we had the mission to design and develop a system from scratch in two and a half months. The team was new, with members who had recently joined the company, and there was no product manager to handle business, customers, or UX conversations.
We had to deal with numerous teams and unplanned work. In such situations, my recommendation is clear: define an MVP without hesitation.
In this case, I inquired about the contracts we needed to fulfill with our customers. Then, as a team, we defined a realistic MVP to be accomplished in two and a half months.
Simultaneously, while the team is working on the solution, I recommend one more important thing: measure the technical debt that you are going to generate along the way. Keep it visible to address it sooner with its corresponding effort, and communicate this to the business and product departments.
3. Involve other departments
As a manager or leader, you will sometimes have a general vision of the product that your team is building. Therefore, a way to reduce costs, prevent issues, and make your team more effective is to consider impacts at the same level or even more than dependencies.
I’ve faced challenging situations both independently and with my team, often involving dependencies with other teams. Some of the tough scenarios include:
- Our team developed critical features, and once the development was completed, the feature required legal and mandatory approval to go live.
- Features that needed UX approvals to maintain consistency with a general marketplace.
- Features were blocked because they were not security-friendly or, even worse, required new and unplanned development. You may explore the shift-left movement at this point if you want to delve deeper, which involves checking for security issues earlier in the development process.
It’s always worthwhile to involve the necessary teams or departments in the development life cycle. Attend their workshops, seek feedback about your application, and engage in collaborative efforts. This approach enhances your team’s performance, fosters trust, and promotes self-motivation.
4. Optimizing Meetings
Sometimes, we find ourselves in a cycle of meetings and forget that developers need time and focus to code, managers need time and focus to manage and address issues, UX designers need time and focus to design, and so on. How can you achieve this if you are immersed in meetings for eight hours a day?
Be Agile
- SCRUM Ceremonies: Depending on the team, goals, and other factors, maybe SCRUM is not always the best fit for your team. At the very least, invest time in thinking about it; there are multiple approaches.
Goal Meetings
- Select the audience carefully.
- Include only necessary participants.
- Provide a description explaining the purpose of the meeting.
- Attach links to the documentation to be reviewed before the meeting.
- Facilitate the meeting to avoid unnecessary extensions.
- Make decisions.
Asynchronous Communication
- Encourage Git comments.
- Keep documentation up to date.
- Promote autonomy within the team to share knowledge with colleagues.
5. Managing the Technical Debt
In an ideal world, a team should not have technical debt, but in my experience, I’ve never seen that. There are always things to be improved.
- If you need to rush with a solution to increase business value or for any other reason, some technical debt will be generated.
- If there’s a new way to make something more efficient, you’ll need to invest some time and negotiate it with the Product or Business departments.
- Keeping libraries up to date requires dedicated time and effort.
- If you or your team think that everything is already done and there’s no room for improvement in any system, I’m sorry, but there’s always something—especially when the waters are calm (documentation, library updates, workflow enhancements, efficiency investigations, etc.).
You can label all of these challenges as technical debt or not, but there are always these kinds of conflicts between tech and business. Therefore, my advice to you is to allocate a percentage of time every sprint for these matters and keep them in mind during your quarterly planning (or whatever timing you’re using).
6. Measure Performance
Analyze what can be improved and seek out other teams facing similar issues. Perhaps this is not affecting only your team. There are at least four important questions to ask yourself, and these can be measured:
- What is the team’s delivery provisioning time? From the moment a requirement is defined until it runs in production, assess whether the entire process is too bureaucratic or if there are elements being overlooked. In either case, there is room for improvement.
- The deployment frequency could indicate that our code segments might be too large. Maintaining consistency in the size or scope of our services is crucial. This will have an impact on contributors’ motivation, costs, feedback about our system, etc. Continuous delivery will also reduce unplanned work.
- How much time does it take for your team’s services to be restored? It depends on the criticality, but what if your most important service is down for a minute, an hour, or a day? You may identify that the deployment speed, or even the pipeline steps, need improvement.
- What is the team’s error rate? This includes the percentage of hotfixes, checks on the same piece of code, or ‘temporary’ patches. You may be able to improve quality processes, monitoring, technical debt, clean code, etc.
There are multiple technical aspects to improve a team’s performance, but I’m confident that the four I mentioned can be helpful in identifying problems or areas for improvement.
Conclusion
- Keep your team conscious of the team goals, ensuring alignment with the company’s direction. Highlight the positive impact of their day-to-day work and emphasize how it contributes to their performance and knowledge.
- Measure what you want, but at TEAM LEVEL, not individually.
- Keep things as simple as you can. I don’t think there is a perfect solution, and even if there were, it would probably change because technology advances rapidly.