We are building the Jumbo Tech Campus since October 2017. The Jumbo Tech Campus is the software development organisation of Jumbo. And since we wanted the Jumbo Tech Campus to be an
organisation based on Agile principles, we re-organised ourselves halfway 2018. We implemented a new structure in our
organisation that stimulates us to work in multi-disciplinary scrum teams and that allows us to scale.
Why? Well, Jumbo is a fast growing company that meanwhile transforms into a more technology focused company, so as an IT team, we need to be able to innovate and scale.
The organisational structure we implemented is pretty straight forward. We wanted to implement a best-practice, so that’s what we did. We started with the teams, these needed to be multi-disciplinary. Meaning that a team has all the skills to be able to implement a user story from A to Z. Depending on the task our teams have, they can consist of developers, testers, consultants, ops, designers etc. This makes sure that teams can implement stories from the start to the end.
The team has a product owner, who is in charge of the backlog and one of the team members of the team acts as a scrum master. We thrive to have all dedicated product owners and from experience we have learned that 1 product owner can support two teams. The teams also have a team lead, who is mainly focussed on coaching the team on both hard & soft skills, hiring the right people and keeping an eye on the delivery of the team. So the team lead is the “HR manager”.
Two teams often have one team lead and one product owner. If you make a drawing it looks like this:
Indeed it looks like a cherry, which is a great metaphor for an agile team. Since a cherry has a strong pit, which stands for the hard skills a team needs to be effective. Team members need to be good at testing, developing or whatever their role is in the team. But a cherry also has a soft part, surrounding the whole pit. This stands for the soft skills a team needs to be effective. They need be a good team, working together not afraid to make mistakes and to get and give each other feedback.
Two teams with one lead we call a cell within our organisation and since we are a development team of around 300 people we have 35 teams all of them organised in the same way. There are around 15 team leads which are organised in three areas: Core, Digital and Data. These areas are managed by the development managers, so the team leads report into them.
One of the principles behind our development organisation is learning. We believe that when people can develop themselves, their job will be challenging, they will be more effective and more motivated to achieve great things together for Jumbo. Our organisation and our processes need to be set-up in such a way that it is easy for all members of the team to get feedback and learn. The scrum proces in itself is, of course, a good example of that, but also the team lead is very much focussed on coaching her/his team. Now we run into an issue, our teams are multi-disciplinary and it is the task of a team lead to coach the team also on hard-skills. Most of our team leads are from a development background and therefore coaching people in for example design, or testing is a challenge.
Luckily we have one other team in our department, which is called our pathfinder team. Pathfinders are guru’s, really good at a specific skill. For example design, or agile and we have quite some technical pathfinders, focused on microservices, or infrastructure. Pathfinders have different tasks, one is to help team leads to coach on hard skills. Especially in the areas that team leads aren’t very much skilled in. So our Design pathfinder helps many leads to recruit the right people for their teams.
The name pathfinders isn’t accidentally chosen, they do “find the right path”. Especially between the different teams. We like the teams to be very autonomous, making a lot of decisions themselves. But teams do not always know the answers themselves and they like to get help. Also there are topics that should be aligned for the whole department. Things like code guidelines, design guidelines etc. These are all typical pathfinder topics. We always say that making mistakes isn’t a problem. As long as you learn from them and do better next time. On the other hand, we have 35 teams. And although making mistakes is part of the learning proces, we do not have to make the same mistake 35 times. Pathfinders avoid this.
We’ve implemented this structure to be able to innovate faster. How does this work. Well, scrum is a process in which you try to make all improvements small and fast. Making sure that you can develop new stuff quickly, implement it quickly and learn what your users/customers think of it. Which this feedback you can improve your software until it is good enough. Within our E-commerce environment we are pretty far in this sense. We can already release more times per day.
The organisation is pretty straight forward and scales by adding more cells to the structure. More cherries in the tree so to speak. This means we’ll have more teams, more team leads and maybe an extra development manager is needed at a certain point.
In general, I believe Jumbo should, when talking about IT, have a best-practices strategy. In the end we are in the business of selling groceries the best way possible and not in the business of inventing new (software development) processes. So the whole story above is not unique for an IT team. It is mainly a best-practise within the IT world on how software should be build and how an IT team should be organised.
As said, we are in this new organisation now for a few months. So now we start noticing how things work out. This is the moment that your team members start asking questions. Very relevant questions most of the time. And there is one question that is asked many times, especially by people that have seen other agile implementations in other companies:
Why is a scrum master not a dedicated function in itself, but a role of someone in the team? And why is there a separate team lead who is HR responsible?
I heard people talking about the “cherry-model” of Jumbo. In the beginning I didn’t understand why people talked about it. We implemented a best-practice, so what was special about the Jumbo version?
But later I realised, when designing our organisation we followed the scrum principles very thoroughly, “scrum-by-the-book”. Maybe a bit more than most companies do. So we indeed might have done something a little bit different than the mainstream. And I believe this was a very wise choice, let me explain why.
The essence of scrum is not implementing the process we all know, the rituals. It is about building a culture and building cultures isn’t easy. To make that happen in a big development team you need to do a lot. Actually everything that can help, you should do. And that’s the reason why I strongly believe the cherry model works. One thing to add here is that I do not believe in completely autonomous teams. I do believe in fairly autonomous teams; especially in larger IT teams I believe that some kind of normal HR is needed and actually very much appreciated by the people that work there. One of the reasons is that work motivation is very often strongly related to the speed in which you can learn. Learning fast is very often facilitated by some kind of mentor or coach and that is very often your manager or lead.
To build a scrum culture you need to do everything you can to make it easy for people to talk about their mistakes With the cherry model you split the responsibility of HR from the responsibility to make the scrum proces work. Meaning the team can do its proces as autonomous as possible, without a manager kind of type interfering. So when you are in a retro, the lead doesn’t need to be there making it safer to talk about your failures.
Also sometimes teams get in trouble, they can’t solve it themselves anymore. A lead is than an outsider, objective to whatever matter is at hand.