3

I am already read a ton of referencing about feature teams, squads and growth hacking structure.. but imo, there is still a lack of concrete examples and how to break down a product/organization in feature teams.

To give an example of a traditional website e-commerce, how we should break down the teams? I could have a feature team for example: - home page (value proposition) - showcase ( product, categories and search) - cart management - sign up - checkout - customer account (order history, order status)

I think in that way we are customer focused. We are dividing our team in business flow.

Suggestions?

5

I thought a feature team is a team that can fully complete features to production without dependencies on other teams. What you describe sounds like area teams.

Here the LeSS (Large Scale Scrum) perspective on feature teams and requirement areas:

A feature team, is a long-lived, cross-functional, cross-component team that completes many end-to-end customer features—one by one.

https://less.works/less/structure/feature-teams.html

When you have a lot of feature teams it might make sense to group them in areas:

Feature teams scale nicely, but when their number goes above eight teams additional structure is needed. Requirement areas provide this structure and complement the concepts behind feature teams. A requirement area is a categorization of the requirements leading to different views of the Product Backlog.

https://less.works/less/less-huge/requirement-areas.html

If you do not have a lot of feature teams, it could backfire if the teams think their area is their only job. What if you have some key features in a single area that are the most important now. Why would some feature teams work on a un-important area? I think you want to be able to refactor your feature teams to be able to shift easily to a different area when needed.

Keeping the same area context for a team helps a lot to keep the team stable (and or hyperproductive), so do not refactor continuously. I do think there is a need for each team to understand that we could need multiple teams on a single area. For example to beat a competitor to market, or to be a fast follower. Thus they need to be prepared for this mentally, organisational, technology- and skill-wise.

My suggestion would be to experiment with a smaller scale, e.g. two-three teams and then scale up to all the teams. Creating a sort of reference model to learn from. There is no silver bullet, but experimenting with ideas from LeSS, Scrum@Scale or the "Spotify Model" might learn what works for your company or industry.

  • Really succinct and excellent answer Niels. Have bookmarked that, never come across such an elegant explanation on one page. Hopefully you won't mind it if I use this in my own workshops? ;-) – Venture2099 Jul 30 '18 at 12:44
  • 1
    @Venture2099 Thanks, answers on SE are licensed "cc by-sa 3.0" and thus can be freely shared and adapted, but I do think you have to give attribution to SE if you want to use it in content you share. See the copyright notice in the footer of this page for more details :) – Niels van Reijmersdal Jul 30 '18 at 13:09
  • @NielsvanReijmersdal thanks for the answer! I have already looked in how Spotify organize their team. They have like search, content and so one. It seems more a requirement area (tribe) than a Squad right? If not, they could have the same prioritisation problem that you presented above. – p.magalhaes Jul 30 '18 at 16:34
  • @p.magalhaes Probably, but keep in mind stuff you read about the spotify model is probably 4 years old, do you still think Spotify works like that? I think they have evolved further. Henrik Kniberg even says the Spotify model does not exist, and he should know cause he documented it. I know other companies like Booking.com also structure their teams in areas a couple of years back, maybe they still do. Do wonder if your company is the same scale, because having hundreds of engineers makes the prioritisation problem I describe less impactful, compared to having just 3 teams of 4-5 engineers. – Niels van Reijmersdal Jul 31 '18 at 7:24
0

The idea of a feature team is that it is a cross-functional team with all of the skills needed to deliver any given feature. To build one of these teams, you need to start with identifying what skills are used to create features. I'd usually recommend asking the teams. For a web product, the list would probably look something like:

graphic design, html/css, java/python/c#/whatever language, database
administration, [other domain knowledge areas for your company]

From here, you want to ask team members to rank themselves in each of these skills. Usually I use a scale something like this:

0 - no knowledge/experience 
1 - beginner - someone should look over my work 
2 - proficient - able to effectively work alone on most tasks 
3 - expert - can take hard tasks and mentor others

Now you can take any team and see if they have gaps (nobody with a 2+ in a skill) or bottlenecks (only 1 person with a 2+ in a skill). If you want to reform your people into feature teams, just ask them to self-organize into groups that have no gaps or bottlenecks (you may decide some bottlenecks are ok for infrequently used skills).

Congratulations. Now you have teams that can all work on any given feature as needed.

It is worth noting that something it makes sense to break your product down into areas and then the teams may work in one or two product areas, but this is usually reserved for incredibly large products (like Microsoft Office) or products where different areas have radically different skill sets (as an example, I worked in a datacenter company where some teams were building a web application and other teams were building customer storage hardware).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.