Development Dream Teams
Photo by Budslife “busy”
Over the years I’ve build some teams. The size and composition most often was determined by the company I was working for. This meant the team was developer only, at least some teams were cross-functional. I wished to have the freedom to create an optimal development team, a dream team.
In modern teams everyone should be able to do everything – this avoids bottlenecks or single point of failures and distributes the burden of some tasks. But there are limits. Skills are not easily found combined in one person:
- Test Know How
- UX/Design CSS
- Product Development / Management
So a cross functional team needs to include:
- Product manager / PO for product development, wire frames, business analyist, business cases
- UX/HTML designer for usabilty, design and hardcore CSS problems, developers can’t solve
- 5-7 Developers for programming, backend, frontend, CSS/HTML, development, unit testing
- QA/tester: works with PM to determine acceptance tests, writes automatic acceptance tests, exploratory testing, helps developers with their tests, keeps the testing focus
- Optional, but helpful: Operations guy for the sub system. This role can be temporary
Why strive for a cross functional team? When a team is not cross functional, there is a lot of communcation overhead and lots of filled queues. With no product manager as part of the team, there are vertical silos and handoffs. Repsonsibility is split and in the case of trouble, finger-pointing starts.
And Jon Moore blogs in “Scrum thoughts: cross-functional teams”:
As a developer, this was great. We had instant access to team members from the other disciplines, able to brainstorm about how a feature should work and getting questions answered quickly. There was a very real team vibe, very exciting. [...] The six weeks that we operated like this were really fun!
With cross functional teams, communication is easier, missunderstandings seldom. Colocation is a must and leads to much higher productivity. With one team there is only one responsibility. The team is tasked with a user story and the whole team is responsible for delivery.
Scrum strives for cross functional teams, the biggest hurdle for Scrum Masters on that road are political struggles and thinking in kingdoms.In Scrum, product owners (PO) and developers are considered one team, which is often not colocated. They belong to different departments with different goals. Therefor a ScrumMaster constantly needs to tell them they are one team. One real team makes Scrum easier and more successful. Companies should organize teams not at department boundaries, but value streams.
Team size is another paramter. From my experience, the team should be smaller than 10 people, team communication and managment gets more difficult when you approach the threshold of 10 people. Pete Abilla writes about the size of the famous 2-Pizza Teams at Amazon:
[...] Amazon’s 2-Pizza Team, which is defined as the following: a team where the team size is no larger than 2 pizzas can feed. Amazon realized early on that in order to cut software development time, the solution was *NOT* to put more people on the project.
The number of developers matters most, as it influences the number of the other team players. If the number is small, there might not be a good ratio to testers, designers and product managers. If the number of developers is larger, this is better, because it creates more throughput according to queuing theory. More throughput means shorter cycle time. Too many developers on the other hand lead to communication overhead and get ineffective says Jens:
Intra-project communication becomes more and more challenging with increasing team sizes. When team size increase so does the number of different communication channels. Every team member can communicate with every other team member. Mathematically it looks like this:
number of communication channels = n(n-1)/2, n=team size
While Jeff Sutherland goes farther and generally attributes lower productivity to large team sizes:
There is plenty of data to show that team sizes over 7 result in significantly lower productivity. Any team over 7 in size should be split up into multiple SCRUMs.
My dream team is a cross functional, cross department development team with less than 10 people. What would be your dream team?