Teams are the holy fundament that agile resides on. Teams should be autonomous and cross functional. Teams should be kept together over longer periods of time to become good at what they are doing, to be high performing. This is sort of ”common sense” in the agile world today, we all know this. But what if the team model doesn’t fit your needs?
To team, or not to team?
It happened during one of our biweekly meetings that discuss continuous improvements to the process. The question ”Why can’t we split the team?” was raised. The discussion started and soon the more general question ”Why do we work in teams at all?” was brought up. I was sort of defending it, teams are the way to go and we should not change that, but afterwards I started to think. This blog post holds those thoughts.
Some background first. We have a relatively small development department. It is currently divided into three teams. Each team has their own set of responsibilities. Personnel has stayed fairly intact over time so everybody knows each other in the department. Each developer has a broad competence, meaning that most of them can do all types of work. Some of the developers have ”special competence” regarding certain areas.
Back to the question about teams. It was raised because only two persons is allocated to work with one of our responsibility areas. Two persons are not a team. Why not have a kanban board for that responsibility area, and have a daily meeting where people that has an interest in this responsibility area can participate? The kanban board then don’t belong to a team, but rather to a responsibility area (this could be one of your products for example).
This thought is not new. I recall that I have read in a David J Anderson book that they had a kanban board and a daily meeting with 50 participants (yet the meeting took less than 10 minutes). I hardly think those 50 persons thought they belonged to the same team, more that they shared interest and participated in a work flow (depicted on the kanban board). I also know that Spotify makes many small organizational changes. On a regular basis (quarterly?) they form the teams (they call them squads) needed. Afterwards they evaluate and re-forms the teams if needed.
I have an example of this that I would like to share with you. We needed to make a new release of one of our old products (that is not in our main focus anymore). Before when that have happened, we have spread out the work on the individual teams, to be fair to the persons that holds the ”special competence” needed to make the release. Work has then not become prioritized and have been dragging for months before it got completed.
This time we thought to try something different. Why not setup a ”temporary group” (I call it so in lack of a better name) and take out those ”specialists” needed from their current teams. We prepared a kanban board and set a time for a daily meeting. Work started and the focus was really good, the ”temporary group” completed the release work in 13,5 working days! The same type of release took two to three months in lead time to perform when working the old way. After the release was done, the persons in the ”temporary group” re-joined their former teams.
What I am trying to describe is to have ”temporary groups” that forms some sort of task force to come together to solve a particular mission, then they are scattered to be able to join in on something else. Do you have experience in working in this manner when it comes to software development? I would really like it if you can share your stories!
All the best,
Tomas from TheAgileist