Table of Contents
Over the course of the last quarter, we profoundly restructured the way our teams work at Kambu. The newly introduced multi-project teams are inspired by the idea of organizational agility and ensure we can easily accommodate different project sizes with multiple team layouts.
Multi-Project Teams – What Changed?
Kambu has been an agile company since its foundation, 11 years ago. Everyone, from developers to designers, follows Scrum practices. As a result, we are able to deliver business value consistently to our partners. It just works.
However, we felt it was time to upgrade. Our teams were always based on projects and we could see there was room for improvement.
Our aim was to work on:
- Efficiency – Our teams report spending a lot of time on meetings. How can we eliminate choke points such as this?
- Elasticity – We have projects of different sizes and scopes. How can we ensure we address all tasks with the best prioritization?
- Adaptability – We onboard team members regularly and are looking to expand. How to streamline the process so they are fully integrated sooner?
We studied and collected feedback from the team.
Agile conferences also offered case studies with great insights on how to move forward. For example, in AgileCorporate BNP Paribas talked about using a single backlog. If big banks can organize work in such a way, what prevents us from trying it?
So the idea was to turn things around – to base teams on technologies instead of on projects. Team Project x and team Project y would be reorganized into team Java or team .Net, for example.
How We Hope Multi-Project Teams Power The Agile Organization
By dividing teams into technologies, we hoped to create a single backlog per technology, showing both required work and capacity in one place.
This is huge and makes it easier to plan and prioritize.
The other effect is less time spent on meetings, especially dailies and retros.
Implementation – Has To Be Collaborative
Overall, we are talking about a big change, so it was important to start it right.
The first step was meeting with team leaders for workshops where they presented their questions and worries. The main concerns were:
Concerns on Implementing Multi-Project Teams
- “The 15-minute dailies will not be enough to discuss multiple projects”
- “Sprint estimations will be harder since different projects use different measures”
- “We will not be able to deliver functionalities of all projects equally”
- “Some team members only work in one project, so they will waste time”
- “It’s hard to collect the competencies that we are lacking”
It was very important to hear these concerns, but I was also confident that the new multi-project teams approach would actually address them all.
It was time to put the plan into action and start testing.
First Sprints
We started the first sprint following this method with the Java team on October 7th.
The first sprint planning was a learning experience, but in the retro the feedback from the team was great. They noticed that the transition was quite smooth and observed a better overview of what was going on in the sprint.
We were able to plan different projects 2 weeks in advance and it was much easier to plan the work around the absences of members.
Finally, now that the Java developers have an overview of different projects, we see more easily opportunities to optimize tasks across the board. A big win for our partners’ projects.
There was no discussion: we were keeping the multi-projects team model.
Over one month later, we now have three teams: Java, .Net, and Node.JS/PHP. All with testers and frontend.
Agile Means Always Being Prepared
Before concluding, it’s worth mentioning that we were not strict with our new model. Doing so wouldn’t be agile! We made some adaptations:
Does something change for the customer, in particular when they act as PO?
No, because the new process involves dailies and retros only. So meetings with customers (usually demos and backlog refinements) are not affected.
What if a project utilizes different technologies?
We simply divided the task for each technology into the respective backlog. For now, it worked well.
Conclusion – What We Expect Moving Forward
So far, the new model has been a success. I expect that in the future we’ll have outcomes even outside developments. For example, HR activities will improve, since we will know even more clearly which competencies we are lacking.
More than that, we are building a scalable foundation so we can answer our partners’ demands even more quickly. With projects big and small, we will have more time to go above and beyond in implementing great things.
