Teams Are Greater Than Projects

My post ["Sprint Planning Meeting Introductory Script"]("/sprint planning-meeting-introductory-script/index.html") sparked some conversation with an old schoolmate on facebook, Justin Antoszek. He was describing his department. He’s a senior software developer in an R&D department with 3 teams running 3 different projects that have several people involved in multiple teams depending on which project has the highest priority from sprint to sprint. I can’t imagine how hectic it must be to track the velocity of any of these teams with the team members in each being in flux. It sounds like these teams aren’t even given a chance to develop the chemistry with the revolving door of team members. From my experience, you stand to gain a lot out of agile by keeping a team together, letting them develop chemistry, and come to cooperate by instinct.

I feel strongly that to really get the most out of agile, you need to secure, grow, and protect your team. By having so many team members jumping from one team to another when the pressure is on, you rob the core team (the members who don’t shift between teams) from developing the chemistry, confidence, and predictability that can continue to grow. While I haven’t had any direct experience with it yet (I have protected my team from 2 potential reshuffles in the 5 months that we’ve been together), every source I’ve read on agile has talked about the loss in velocity to a team when the composition changes. It’s often described as regressing from norming/performing to forming/storming and starting the growth cycle once again.

What I would suggest is to solidify the 3 teams (with the potential of keeping a couple folks as team consultants if their skill set is specialized, required on all 3 teams, and expensive or otherwise prohibitive to cross-train) with team members that don’t change. By keeping the team static, you allow each team to reach further through the cycle into the norm and perform which I feel results in greater velocities despite the shift in type of work. The key to helping a team move through this cycle faster and with greater results revolves around effective retrospectives, which are harder when your team makeup changes and you lose key members only to gain them back the following sprint.

The trade-off with fixing your team membership is that you will need to shift from spreading around team members to spreading around the work. If we take the example of Justin’s department, with 3 teams dedicated to 3 different projects, you could have a situation where one of the projects suddenly becomes more important than the others. This happened recently in my department. The sales department sold our product and said they needed to move up the deadline to having a MVP (Minimum Viable Product). Since we had committed to fixing our teams, we decided that having this MVP completed on time was more important than making progress with a project that another scrum team was performing and blew up the sprint of one of our 3 teams. As the scrum master of the team working on the MVP product, I identified what epics and stories could be handled by the other team. This analysis was required because there was a significant difference in the technologies used by the front end and back end which would require a steep learning curve that we already ate, but they couldn’t afford. They met, built up a new sprint backlog from this project, and were off to the races again.

We chose to delay one project in order to ensure we completed the other project on time with the new deadline. You don’t need to go as extreme with this, though. If you think about it, each team is just working through a backlog, and there’s nothing that is tying you to stocking a backlog with only items from a single product. That being said, the context switch and environment setup moving from a task on one project to a task on another needs to be considered, so you’d be well advised to clump up the stories from each product to minimize this.

I would push for this change because I feel strongly that the best value provided by agile revolves around your teams, so they should be emphasized and considered more than the projects that the teams are working on.