Teams - Amazee Agile Agency Survey Results - Part 3

Let’s focus on teams for part 3 of our series, processing the results of the Amazee Agile Agency Survey. What’s the size of your delivery team? Where does your team work? And how do you match projects and teams in a continuously evolving agency environment? In Part 1 we already looked at different sizes of project teams. The average team sizes were the following: 30% have teams of “3 or less”, 26.7% of the teams have “5” members, 13.3% have “4” members, another 13.3% have “6” members and 10% stated “8 or more”. We didn’t ask for this, but I think team size heavily depends on factors like project size and duration. At Amazee our teams are usually made up of five people. Compared to smaller teams we can benefit from a lot of knowledge transfer and collaboration within the team. Also, we are less affected by off time from individual team members, and most of the T-shaped skill sets are represented at least twice within a team.

The highest rated option for where teams work was 33.3% “mostly co-located with some degree of remote”. This setup is followed by 23.3% “all co-located in an office” as well as 23.3% “mostly remote”. At Amazee we always had some degree of remotes, but over the last years we transitioned more and more into “50% co-located and remote”. Having the option to work remotely provides a flexibility we don’t want to miss. I.e. it allows those team members who work from an office to visit friends and family abroad easily. Also, if you are on the way to a client meeting, you would still be able to join team meetings such as standups remotely via our preferred video conferencing tool zoom. More thoughts on working remotely versus locally can be found in Vasi’s recent blog post.

Regarding matching teams and projects, 50% choose to “form a team when a new project starts” whereas 30% have “stable teams with multiple projects at the same time”. 10% have the luxury of “stable teams with one project at a time”. I called it a luxury because this is what Scrum is designed for, but in an agency environment, it is often hard or impossible to achieve this setup. From the free-form survey replies, it appears that “forming teams when a new project starts” is preferred to achieve the best pairing of available resources. Also mixing people/teams allows for knowledge transfer and refresh team members minds from time to time. However, a reason why solid teams are preferable is that they can improve themselves over extended periods of time. When I joined Amazee, we used to have one big team of 10 developers handling multiple projects at the same time. Every week, between the tech leads and project managers we would assign the different developers to a project and decide how much they would work on that project, which was great because we could always appoint the best person to a job. But, this also proved to have some drawbacks, as there was limited ownership of developers and projects. Since we introduced Scrum, we have “stable teams working on multiple projects at the same time”. This setup allows our teams to continuously improve their processes and take full ownership of the projects assigned to them. We also formed a separate support team that focuses on reacting quickly. We also noticed that having maintenance projects assigned to the teams, that run off a Scrum-based workflow for new delivery projects comes with a challenge, which is why we created a dedicated global maintenance team. You can find out more about that here: recent talk “Maintenance and Longevity - Keeping customers and developers happy”. 

70% of the teams change “once a quarter” or less often which indicates that stability is an essential factor teams take into account when it comes to changing their assignments. Initially, when we evaluated Scrum, we were thinking about forming teams for every project. As we would have a new project kick-off every couple of months, we were concerned about team stability and had to find another solution. By building stable teams, we can continuously invest in team dynamics and have them fully self-organised. The downside of this is that the team will work on multiple projects at the same time but so far we are happy with balancing that, and it is also refreshing for the team to not work only on one project for a year. As a conclusion of part 3 of the Amazee Agile Agency Survey Results, I would like to pose a couple of questions. How do you form contracts? What works and what does not? Leave us a comment below. If you are interested in an Agile Scrum training, don’t hesitate to contact us. Stay tuned for the next post where we’ll look at discovery and planning.