Scrum, squad, squid, feature team, tribe… Help !
XAnge recently held a “TECH’buffet” to address the organizational issues of IT teams.
On this occasion, we gathered a bunch of IT teams from our B to C startup portfolio: Chauffeur Privé, Evaneos, KissKissBankBank, La Ruche Qui Dit Oui !, Ledger and Lydia.
And what an outcome! To say the least, the discussions were vibrant and productive. Obviously, the way IT teams organize themselves is a major issue for any self-respected developer! :-) Their aim is to be always more efficient, to best serve their product and their business.
Beyond agility
Methods such as scrum have proved efficient: beyond its agility rules and methods, it’s the actual spirit that prevails. Efficiency, motivation and creativity are the keywords. When the Tech team grows bigger, reaching over 10 to 15 developers, and when the product and business needs are multiplied, it becomes vital — yet difficult — to delve into the happy efficiency of a small, cohesive team — the one that’s able to react to an obstacle in no time and to come up with the ultimate, unhoped-for solution.
In this respect, we were amazed to discover that startups have already reached their 3rd or 4th generation of attempts / failures / iterations process, when it comes to their dev organization. The starting point often appears to be Spotify’s approach: an organization based on small teams without managers (Squads, Squids or Feature Teams) who set up cross-department functions.
Strong team autonomy
Basically, Squads are multi-functional teams (product owner, front-end and back-end developers etc.) with an organization that allows them to handle a specific functionality. They have complete autonomy over their mission. The group remains under the responsibility of the CTO, who ensures overall project coherence, streamlines human relations, arbitrates in case of unresolved issues, and drives the long-term software architecture.
The Squads’ strong autonomy immediately instills an overall “re-energizing” effect within the teams: a swarm of initiatives are launched and large numbers of squads develop (sometimes more than twenty) — forcing the creation of transversal groups (“Tribes”…) in order to synchronize all these teams.
Squads stem by affinities (projects, features and people). They are totally autonomous (recruitment, roadmap, objectives etc.) and settle their own relevant KPIs, in order to monitor their performance.
Tribes can be more customer-centric (with an organization that follows each step of the customer experience for instance) or derived from key business indicators such as quality of service, churn rate, lead generation, upsell etc.
Yet a step further: these organizations may sometimes need an additional transversal layer of “Experts and Communities”. Experts provide squads/tribes with a referent adviser when a critical decision needs to be made. These experts can also address given communities. When addressing the “Dev” community for instance, the expert typically promotes competence-sharing, hosts informal dos and monitors the community members’ learning curve on topics that relate to his/her area of expertise.
Want more on Evaneos’ insight? Try this:
Support / maintenance management
Managing maintenance support can prove problematic because its transversal nature does not match a Squad approach. An original solution could be to alternately name a “Hero”, every 2.5 days (a carefully calculated time period). In an organization with 20 staff members for instance, and if we count over 200 working days a year, this would mean that a given team member would have to stick to the job every 3 months, more or less. He or she would handle all the maintenance-related requests (not the structural ones). With this approach, every one takes responsibility, everyone gets to know all the aspects of the platform, and — a somewhat unexpected benefit — all team members make a great documentation effort in order to help the “Hero” to become quickly operational.
No more CTOs?
One of these companies no longer has a CTO: its developers are organized in squads. In order to manage the overall work synchronization, a team of 5 has been appointed to endorse the roles that are usually assigned to the CTO only. This team becomes a referral entity and organizes communications on cross-department topics such as hiring, training, customer satisfaction, etc. Since there is no manager, lead developers naturally stand out for their expertise and for the confidence they gain.
This organization requires constant communication between its members and the question of whether there is a need/no need for a CTO remains open: at least, this experience will help better define what the team exactly expects from a CTO position.
