[[collaboration and collisions]]
[[scrum of scrims for ltd of teams, aka sAfe]]
[[where do the multiple teams have to talk together, daily stand ups, retrospectives, demo day]]
[[two much detail, sprint planning, back gold grooming]]
[[have sprint leads attend both teams planning / backlog grookming]]
[[ideally only cross team resource is the scrum master]]
[[each team pints scores differently]]
[[put the points on the back of the card when in backlog, if another team decides to do they need to rescore]]
[[watch out for competition comparing team points]]
=Competing Teams
As human beings we love to compete, it seems to be in our very DNA. One of the risks when you move to multiple AgileBI Sprint teams, is the tendency to want to compare the two teams to see which team is “better”.
And as well as competing the other thing we love to do is measure things. Of course the first place we start when we want to compare teams is to compare the story points the teams are completing each sprint.
STOP!
Each team score points in their own way and you cannot compare across the teams.
One of the major values of the points is that it allows the team to estimate their expected efforts in a safe way and with the limited amount of information they have to hand before they actually start the user stories.
If you try and compare teams some bad behaviours will arise:
- The teams will start to try and find out the cadence of the other teams points and try and match it, this means they are not scoring the points based on their experience and the points will become less accurate
- The teams might try and get much more detail than they need to make their points more “accurate”, slowing down th backlog grooming process
- The teams might put less and less in the Sprint background to ensure they deliver it, not such a bad thing but one of the valuable things of AgileBI is the ability for the teams to be able to take risks and fail safely
- The team might over engineer the delivery of the stories, or worse pressure the Product Owner to accept undercooked delivery for the user stories, to get more accepted as Done Done
There is however one thing that you can compare across AgileBI teams:
- Did the AgileBI team clear the scrum board at the end of the sprint and deliver what they said they did
[[but definitely competition for completing what they promised in the sprint, the team is in control]]
Often a customer will start off with one sprint team as a toe in the water to see if the process wil work, before they decide to scale into multiple teams. This is actually an approach I highly recommend.
[[split first team into two teams and add new resources to both, kills velocity but makes it safer as the old team members coach the new ones]]
{{one of the intersting behaviours I have experienced as a customer expands into multiple AgileBI teams is the idea of Sprint Team 1 and Sprint Team 2, or Sprint Team Alpha and Sprint Team Beta. These terms somehow infer that the first team are more important than the second, or at least some sense of hierarchy or order. This can lead to some unhealthy behaviours at some stage. So one of the first things I do when scaling to multiple teams is to ask the teams to come up with a team name. They will normally come up with some fairly numerous which is always entertaining. If possible I have both teams in the room at the same time, and ask both teams to do it separately. The intersting behaviour here is that each team will normally also pick the name of the other team, for example Team Day and Team Night. I never set a boundary that says they cannot do this, but I do set a boundary that the teams are not allowed to collaborate during the naming process. At the end of the process each team has picked their own name and we ignore the alternative names. It often results in very humorous combinations that have little if any relevance to each other, but it gives a great story to tell when people invariably ask}}
==collisions
[[code is the obvious collision, source control, check in and out, TDD]]
[[collision on BEAM templates, or bigger risk of no reuse. Publish BEAM templates early]]
[[how do you manage draft BEAM templates vs done done ones?]]
[[collission on design]]]
[[collison on business rules, defining and implementing]]
[[Test automation for managing test,
==????
[[do the sprint teams have to follow the same dev process steps]]
== summary
When you scale your AgileBI approach to more than one team, then all the disciplines and methods I describe in later articles become critical. When there is only one team, they are able to self manage around any issues that arise because they do not follow these methods. When there are two or more teams, issues encountered by one team are more than likely to negatively effect the other teams. This means the impact of the issue are much greater and the ability for the team with the issues to be a be able to fix them themselves greatly reduced.