Ever since my employer adopted agile some 4 years, ago, we’ve developed our products with a variety of team “configurations”. Here’s a short overview of what we’ve tried and why product teams take the crown so far.
Pre-Scrum: Silos
In pre-Scrum times there were no real teams, but rather groups of people with a similar skill set who shared a room. Everyone had their own tasks to work on. We had a room full of web developers, one with perl hoshis, another one where the project managers sat, and so forth.
The seperation was unfortunate. A nice example dates back to 2010: There is a page that lists all groups in a customer’s sipgate team account. This page had agonizingly long loading times. I’m talking minutes here. Upon closer inspection it turned out that the page requested lots of information from the backend, although it only needed to show little pieces of the requested data. There wasn’t a backend function that delivered precisely what the web page needed. And as web developers and backend developers were working separately the web developers collected the data they needed from methods that were already available, rather than wait for a method to be custom made.
Scrum: Cross-functional Teams
Today it would go differently, because in 2010 we adopted Scrum: We build real, cross-functional teams, consisting of web devs, backend devs, a designer or UX person and a product owner (a re-purposed project manager). One of the devs doubled as scrum master in each team. Such a team worked on shared tasks and could build a complete piece of new functionality.
With this setup we were already developing much faster than before. Pre-Scrum feature development had often dragged along. Now the 5 product owners were hard pressed to come up with enough work for all teams. So far, so good.
Unfortunately inter-team communication left something to be desired. Be aware that all 5 teams worked on the same products. Not simultaneously, but in due time. All teams pulled their tasks from the same pool of work in the hopes of staying flexible. In reality, teams often stepped on each others toes. If one team messed up, it could happen that another team had to fix it, once they started to work on that piece of code. Not the best conditions for peaceful co-existence. It also made it harder to identify with a certain product. Saying “Look, ma, I build that!” with pride is impossible when there are always so very many people involved, even for small features.
Product Teams – Now with more cross-functional!
Today 1 team works on exactly 1 product. Now team members can identify with their “baby” and build up product specific knowledge. Some products have more than one team dedicated to them, each of them with a different focus. But one team never works on two products.
Apart from that we added more roles to a team: a dedicated Scrum master, a marketing person and support people. This way, all customer problems are only a desk away from people able to solve them at the root. So far, this setup has worked great for us.
If you’d like to work in such an environment and speak German, check out sipgate’s open positions 🙂