Agile Team Structure – Part 2

In part 1 of agile team structure we took a look at how things used to be when I first started my role as a Scrum Master. Platform based teams worked fine for a long time, but we wanted to supercharge our progress. So we started to look at ways we could improve; our next experiment was project based development teams.

Project Based Teams – The Pilot

We knew that the way we were currently working with platform based teams was slowing us down. We didn’t know exactly how to proceed, so we decided to pilot a new approach. Using a pilot helped us get buy-in from more senior people in the organisation, it helped us to not cause any issues with ongoing work, and it allowed us to potentially fail. By using a pilot, we reduced the risk of causing issues in all of our projects, across all of our platforms, all at the same time.

We identified a pilot project and set up a single project based development team to see how it worked. As I mentioned in my previous article, historically the same feature would arrive on different platforms at different times; we were aiming to stop that from happening ever again.

Note

You don’t have to build all features on all platforms, but for my particular product, it is mostly the case that we build the same features on all our platforms.

The pilot project was to launch a new podcast platform on iOS and Android at the same time. We assembled a team of iOS, Android and backend developers, with a semi-dedicated QA, a semi-dedicated product owner, and yours truly (now with a 4th scrum team to look after) as scrum master. Our department looked a bit like this:

Scrum teams including new Podcasts Project Team

The team was run just like any other scrum team, the same set of meetings, just at slightly different times to the other teams.

What happened…

We launched the podcasts platform in only 11 sprints (22 weeks), it was a great success! The main problems however started immediately after that. Here’s a summary of what we struggled with in general:

  • Some people on the “normal” teams asked why they weren’t selected for the cool new project based team. That’s something you need to deal with.
  • It took a few sprints to “get things going”, our project burn-up was very flat for the first few sprints (see chart below). We struggled to gel as a team as new people got used to each working with each other for the first time. We didn’t have a long lived team here, they were all brand new teammates.
Chart showing podcasts burn up progress
  • For months we were targeting an MVP (Minimum Viable Product). When we finished the project and launched the feature, we were asked to look at the next most exciting thing. This was instead of using valuable feedback from our users and iterating on the product. So we didn’t build the best possible thing we could have done. We were left with an MVP.
  • As the project team had moved onto something else; there was no-one to fix all the bugs found by users after the launch. It was very hard getting time in the roadmap in advance for “just in case” scenarios; or iteration of an existing ideas, so we had some tough decisions to make immediately after launch.

What happens when the project is over?

This was by far our biggest problem.

We got very excited about getting things done, but we overlooked what happens next. We unconsciously deferred that thinking until after the project was complete and it’s something you certainly need to consider if you are thinking of setting up a project based team.

In this particular example, the team was slowly disbanded back into other teams, to help continue with some of the roadmap as required – whilst being distracted by small bug fixes and tweaks after our initial MVP launch. Not only did we have an unfinished product, we slowed down future product enhancements by being constantly distracted by other things. Not ideal.

Using project teams meant that our teams were no longer “long-lived” causing an actual slow down in performance over time as people context switched and got used to working with each other all over again.

Switching responsibilities at the end of the project meant that potential shortcuts could be taken in the code to hit a deadline, whilst having no responsibility to fix those things in the future. This isn’t the behaviour we wanted to drive.

In short, project teams were not for us.

The good bits

It wasn’t all bad! Like I mentioned above, we delivered a great MVP; we brought a brand new product to market, across multiple platforms, in a very short amount of time.

  • For the first time, front end and backend developers started working together, in the same sprint. We started breaking down dependencies between teams! ๐Ÿฅณ
  • We also started working together across platform i.e. iOS and Android developers working together, to figure out the best way of implementing something consistently across both platforms. ๐Ÿ + ๐Ÿค–
  • We delivered the same functionality, on multiple platforms at the same time. Our marketing department no longer needs to say * available on iOS onlycoming soon to Android ๐Ÿ™Œ
  • Our product owners saw an immediate 50% drop in the number of times they had to explain how a feature worked. Rather than explain the same feature to different platform teams, they simply articulated what they wanted once, to one project based team.

Summary

By experimenting we learned a lot about how project based teams work in a real life work environment. Ultimately, we decided this approach wasn’t for us, we learnt our lessons and tried something new. Coming up in part 3, we’ll talk about feature based product development teams; our next attempt at organising our teams for optimum performance!

See you there!

Stephen Waring
Stephen Waring

I’m an enthusiastic and energetic Scrum Master who loves everything about Agile!