Thoughts on temporarily removing team members to work on cross team architectural issues

I've been asked my view on this.

What is the view of the teams themselves? How would they prefer to handle this challenge?

I guess its more the first issue that disturbs me.

In Scrum, it would be more disturbing if decisions were to be made about those teams, by others, for them.

> What is the view of the teams themselves? How would they prefer to handle this challenge?

The individuals within the team who would be taken out prefer this as it was there idea and they asked my view. The opinions of others within the team seem to be relatively unclear at the moment. Its a great question and one I need to put more time into understanding



> In Scrum, it would be more disturbing if decisions were to be made about those teams, by others, for them.

No decisions have been made yet but the proposal was drafted by leads from each team + the VP. This is partially where my concern lies and I guess I can't validate it until I hear the rest of the teams views.



Thanks for you response Ian

One of the premises of agile software development is being able to adapt when new information is gained or situations are identified.  While having a team members work together for long periods of time can provide many benefits, sometimes situations warrant different behaviors.  And any change can cause disturbances to the organizations flow, even negative disturbances.  But that is why it is best to involve everyone impacted by the problem in coming up with the decision. Be agile and adapt to the changes. 

However you mentioned that 

 the proposal was drafted by leads from each team + the VP.

I have a bit of concern on that approach.  First that there are "leads from each team" seems to indicate a hierarchy which is a red flag for self-organization and self-management.  The second concern is that the VP was involved in it.  I don't know how your organization works but in most that I have been in, when a VP is involved it comes across as a decision and not a proposal.  So how likely are the non-lead team members of each team to voice disagreement to the proposal given the body of people that created it?



If I had been in this situation, I would have started by asking the leads and VP to pose the problem to the organization and see how the larger body of individuals felt it could be handled.  That gives everyone a chance to share responsibility for the solution and to self-organize around the problem.  

I would echo the core message wrote by Daniel and Ian -> Involve in the process of finding a solution / making a decision the teams that will be impacted by it.

To add something, IMHO the proposed strategy seems logical and quite agile in nature -> you share something together? you take responsibility for that together. The strategy to form a temporary team composed of single developers delegated from other "stable" teams in order to focus on a bigger initiative seems for me to have more advantages in the long run, than disadvantages - so if I will have the possibility to vote, I vote for that.

About the implied hierarchy mentioned by Daniel, I kinda disagree, as much as the Scrum Guide state that within a Scrum Team there are no hierarchies, it should not be extrapolated on the whole organization. Scrum focuses on developing products, not on running a business. I understand that this "no hierarchies" sentence is something that should make stronger the value of Respect, and Self-organization, and self-management. I think that basing on some self-organization definitions:

Self-organization, also called (in the social sciences) spontaneous order, is a process where some form of overall order arises from local interactions between parts of an initially disordered system.

it may be also possible to argue that a team which is free from any hierarchy to distinguish, will possess such formal or informal hierarchy overtime of its existence. In my opinion assessment of the impact of such hierarchy should be made only within the context of such team and organization, and because of that I rather try to avoid making shortcuts such as: "did you say "team leader"? It does not align with the Scrum Guide". 😉

architectural components that all teams agree are required for their work to progress

If these components were required to deliver value, they would already exist.

"if you guys were the inventors of facebook, you'd have invented facebook"

Mark Zuckerberg

This leads me to wonder if this is a new project or an existing greenfield project.

If this is an existing project, then why are these new services "needed" and why can't they be delivered alongside a Sprint. If my team needs a new service to complete a PBI item in the sprint... they create it within the sprint.

If this is a new project, then I wonder if the architects and developers are overthinking the requirements. Designing a system based on what they think they need, not what they do need. Sometimes this can be called Sprint Zero, where a team starts by getting a basic Framework in place. This can lead to an architecture that's not fit for purpose when requirements change in Sprint 1.

If you give with one hand, you take from the other. So moving developers around is shifting value from one team to the other. If you take from two teams to form a third, then you simply remove the value (Story Points, PBI, Volocity) from two, to put it into a new. The new team also incurs waste as it has to form.

So, what's wrong with getting the existing teams to do the work?

If you only have two teams and they've don't have the time to develop the new service then borrowing is a bad idea. You may decimate the existing teams to form the new team. In this case, the answer is "no, we can't do it".

Developers requirements/wants can exceed reality. I personally feel this is a problem with Scrum, allowing teams to self organise. But this doesn't mean the teams can "waste" sprints developing "cool" features that make it slightly easier for the developer but offer little value to the business. The Product Owner should ensure value is being delivered. At Valve, developers are free to work on what they want. They can spend time building "cool" tech solutions that provide little value to their customers.

However, if you have a large number of teams, and the new services are Products that deliver value, then you can form a new team. I would rather hire to form the new team, but this may not be an option due to cost.

Borrowing from a team

This forum is full of stories where developers have been borrowed. Ether to never be returned or replaced.

This can cripple both teams and change the culture.

If the company can't afford to form a new team for the new services, then they can't have the new services.

If the development team can't build an increment of the service within a Scrum, to assist in delivering value, then they can't have the new services.

References

(https://en.wikipedia.org/wiki/Tuckman%27s_stages_of_group_development)

https://www.slideshare.net/luisw19/spotify-engineering-culture-summary

https://medium.com/@dperciv1/welcome-to-flatland-valves-unique-culture-…

If these components were required to deliver value, they would already exist.

To be fair, every team might be working around the same common issue, with the same common bad pattern that is hard to maintain, fragile, and delivers poor outcomes (but does deliver the outcome).

I don't want to invent the component or scenario but I have seen it in several organisations. As soon as a new component "goes live" it is consumed within a month by dozens of teams.

Nothing in the Spotify slide-deck says teams are perfectly static, nor is there any mention of how teams change over time. They do change, and there is an organisational cost to that change.

@Robbie: if the team members are being "taken" from a team that's the antithesis of "self-managing."

If the need is communicated, and team members in consultation with their team come forward - that is exactly what Scrum intends. The teams are self-managing to implement a new product.