QuizUp is actively trying to be an agile company (more on that in a later post). We work in (mostly) autonomous and cross-functional teams, plaster our working space with tape & post-its and embrace change and teamwork experiments.
Recently, one of our teams was asked to work on two cross-team projects. In one of the projects, a developer was ‘loaned’ to another team to work on internal tooling. The other project was building a backend feature that another team’s client developers were waiting on.
One project was canned, the other is being wrapped up, but both were by our standards, below-average in teamwork, cooperation and satisfaction. We retrospected both. The following are our learnings & experiments we’re gonna try going forward.
Cross-team projects are (very) hard
Maybe a given, but a point that people (us included) seem to forget all too often. If you do a project, and it’s across teams, it’s almost certainly going to be hard. Day to day communication and customs, that teams have created together, are in many cases not applicable in cross-team projects.
It’s a new set of folks, with possibly more than one work custom and communication pattern. We need to try as hard as we can to mitigate these effects for the project to be successful.
Cross-team projects need to be clear
One of the projects we started was unclear and fuzzy from the beginning. We didn’t have a discussion on the feasibility of it, or a hack-session on technical viability. We just started. This led to vague show of progress and overview, with no clear end.
Cross-team projects need a venue to sync-up
All our teams have daily stand-ups and weekly planning meetings. That leads to a promise of a discussion on how things are going at least once a day. In addition, the teams sit together in their space, which makes daily and ad-hoc communication very easy.
We completely messed that part up for our projects. We didn’t have a venue to regularly sync, or a place that showed our progress. We didn’t retrospect over the course of the projects, and we didn’t sit down and plan it with all those involved.
This, in part, led to frustration being built up, because we didn’t have a place to vent frustrations or point out things we should change.
Experiments going forward
Based on the learnings we got from retrospecting the projects, and discussion that came after, we made a short list of things we want to try next time we do a cross-team project.
Treat the project as a swat-team
For our next project that goes across teams, we’re going to have a kick-off meeting, create a pop-up board, regular sync-ups (dailies or such), and retrospectives.
If the project is a tooling or internal improvements project, we’ll time box it. First a small amount of time —like a 4 hour hack session — and if that shows promising results, break it into stories and tasks and continue with the work. The reasoning for that is we spent two weeks on something that ended up not being technically feasible for us in the end.
Make expectations clear
One of the projects had the unintended consequence of creating frustration within one of our engineering groups. The reason: we didn’t convey the objective of the project well enough. While one group thought we were merely building a feature, the other approached it as a learning opportunity to create internal tooling, as well as the feature. This led to a mini communication breakdown. (Don’t worry, all is well now :-) )
Next time a project like this is started, we’re gonna make sure all expectations and objectives of the project are clear to stakeholders.
What is your experience of cross-team projects?
I work as an agile coach at QuizUp. If you liked this post, please log in and recommend it to your friends & find me on Twitter :-)
