Resistance to Feature teams
I'm involved in a new project where we are coming up with a green field app, and we want to reduce some of the beauocratic process which has built up over time. We've currently got Scrum teams organised by UI layers and a separate Application Development set of Scrum teams.
My proposal was to form a feature team using Scrum (. This has been met with resistance - main reasons:
- The UI teams have built up expertise in UI, fear this will be lost
- The skillset does not currently exist for people on a feature team to be t-shaped
Does anyone have any experience of this and maybe activities you could use to help inform of the benefits of feature teams?
I am actually facing a similar situation in my new project as well.
Before I joined it seems the teams tried to have full feature teams in the past and it did not work because they could not complete features by end of each sprint because of dependencies and management was getting al concerned about their performance... So they switched to UI and backend teams, basically working in waterfall with sprints. It's just a way to cover real issues and create an illusion of fast delivery.
Long story short, I understand your pain. So far I have not been able to convince my teams to try to go for the feature development teams, but this topic is often brought up. There is also a lot of resistance from the teams.
However, in my opinion, if you were to implement something like that, going with a pilot team might work well - creating a quick win. What I mean by pilot team is having just enough people to create one full feature team and leave the rest of the team the way they work now. The pilot team would work on UI and Application tickets at the same time to be able to create full features.
If you need to get Management buy-in on that, I would use Cycle Time of Full Feature Delivery as your primary metric. Calculate how much time does it really takes your team to complete any one set of functionality, then see how this metric is improved with your pilot team.
A feature team ought to be cross-functional, meaning that all of the skills needed to create a working and “Done” increment must be present in the team. Scrum doesn’t say anything about individual people having to be cross-skilled themselves. Cross-skilling is just one possible optimization strategy for improving in-Sprint value flow.
The challenge is coaching people to self-organize in such a way that each team has the necessary skills within it to create a “Done” increment of release quality. When this is done well, any dependencies between teams will be eliminated or minimized. Usually people resist this because of organizational inertia and a desire to retain existing team relationships and cultural norms, no matter how dysfunctional they may be. Executive sponsorship is generally required to overcome this, and the higher-ups will need to provide it along with a suitable sense of urgency.