Skip to main content

Resistance to Feature teams

Last post 06:03 pm January 22, 2018 by Ian Mitchell
2 replies
03:39 pm January 22, 2018

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?


04:38 pm January 22, 2018

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.


06:03 pm January 22, 2018

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.


By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.