Scrum team size in a small department
We as a department adopted scrum about a year ago and it has worked well on the projects we use it on.
Our department consists of 10 developers and 3 testers.
Our current situation is that we have a quarterly release of our core software product which is made up of many components. To achieve this we have about 7 developers and 3 testers in the scrum team along with the PO.
We also have another 2 developers who are mostly working on a longer term project that isn't yet part of the release.
We often get complaints from within the team that the team is too large. But I also think there is a problem that the other 2 are left out , Is there any advice on how to structure a small department like ours to make the best use of scrum?
Did you ask the team for their own thinking about this issue ?
Generally speaking, the 2 options are Component Teams & Feature Teams, with much more pros in favor of Feature Teams.
In Scrum, the Product Owner should be able to release an increment each and every Sprint, not just every quarter. If it is established that a particular Sprint will *not* result in a potentially releasable increment, antipatterns such as sprint hardening can result, and the value of work in hand is likely to depreciate.
Releasing every quarter - which is to say, planning to release on cadence but less frequently than every Sprint - can be viable as part of a gradual agile transformation. In truth, many so-called agile organizations struggle to release even at quarterly frequency, and yours has done well to achieve it.
The question is: who is complaining about your team being too large, and why? It might simply be the case that the team is the right size for managing large batches of work that are released every quarter rather than every Sprint.
I suspect that if the Product Owner exerted a demand (pull) for releases every Sprint, the need to refactor the existing team may become apparent. In other words a demand for greater agility might be propagated.
This is easier said than done, because there could be a number of stakeholders who currently expect a predictive release schedule. They would need to be brought on board if greater agility is to be achieved across the enterprise.
Some members of the team are complaining about team size. But these are the same people that complain about having to waste time in daily scrums, their problem being that they do not want to hear what everyone else is doing.
I agree we should be able to release every sprint, we are looking at being able to do that, we have been successful in sticking to a quarterly release of our product. We have a very complex product made up of a lot of components with a lot of complicated ways of installing and configuring it.
The other issue is the other work and people outside of this team, in a way it would be useful to have an even bigger team so everyone is included and all time and resource can be planned as one but that would mean a team of about 15.