Setting up a Scrum Team
Hello Community,
in our last Project we had a Development Team and needed for an Interface to a SAP System an SAP Developer. But just for that. We had one in our Company, so good so far. Now we came to the question if we should integrate him to the Development Team or not.
We decide not to do, as nobody could help him doing his Job and vice versa. Instead the PO had is own Little Project with him so, the PO could link and prioritize the work accordingly.
This did not work well. Lack of Quality, Problems in Linking the workpackage.
Alternatively the idea is to let him partial be part of the scrum Team. May be for a few Sprints till the Backlog items regarding the SAP functionallity are done. Is this flexible Team building a good idea?
Another regarding question: If this Flexi Team is a solution, could this be used for mixed product development where Hardware and Software Guys works together? In a known case the Hardware must be implemted first but later in the progress more software changes will be made.
Same Solution here, first the Hardware Guy is on the Project but will later leave (contribute on demand) the Team to develop another Hardware.
In both cases for me it seems hard to deliver a sustainable pace and deliver transparent velocity and burn down Information.
What do you think?
Kind regards
Benjamin
Hi Benjamin,
I think, that "flexible team" could have solved the problem, because the SAP-guy would have been working with the team and upcomming problems could have been recognized earlier. I wouldn't call it "flexible team", because it's important for the team having a stable core. nevertheless ist's a good idea to add experience to the team just temporarily -- if you need it just temporarily. First thing in this case is defining strong interfaces everyone can work against. Same to the hardware-case, I think.
Peter
Team composition ought to be consistent within a Sprint, but it may vary somewhat across Sprints as the features and associated skills may also vary.
The important thing is to avoid substantial changes in membership from one Sprint to the next. *Any* change should be expected to cause a short term-dip in productivity as the team makes the adjustment. In an inspective and adaptive process, such variances must be understood and controlled.
Hi Peter, hi Ian,
thank you for your advices.
I will give the fexible team stuffing a chance next time.
I think it is possible to have a core team and to add experts on certain subjects as needed to the team. I will try to manage the fluctuation regarding to transparence and stability.
Kind regards
Benjamin
When there is subject matter expertise needed for a story that the team doesn't have but is present outside of the team, I have seen excellent results when those "experts" are not assimilated into the team temporarily, but are made available in an advisory capacity only. The team still does the work (groom the story, estimate, develop, test, etc), but arrangements are made so that the SME is an available resource to the team.
The Scrum Master can help facilitate this structure by arranging a recurring point each day where the team can interact with the SME (if the SME's time is stretched thin), as well as scheduling opportunities for knowledge transfer between the SME and the team. The work eventually gets done, the team remains stable, and the situation is leveraged as a learning opportunity (Win/Win/Win).
Keep in mind that when you fall into the familiar trap of treating team members as "plug and play" resources according to specialization, you deprive others from the team from filling in the knowledge gap.