Self forming teams at scale

http://blogs.msdn.com/b/bharry/archive/2015/07/24/self-forming-teams-at-scale.aspx

by taspeotis • 11 years ago

49 9 11 years ago

blogs.msdn.com

I've seen/implemented this at three different companies and it always went well -- and there were many folks who didn't think it would.

I like the "selling" idea, and even though it already feels a little too over-engineered the way the MS guy is pitching it, I might add one more wrinkle: nobody stays on the same feature team more than X months. Becoming an expert in a particular area is sorely needed in many tech organizations, but after 1, 2, or 3 years, it's probably time to move on to something else.

jaynate• 11 years ago

Like the idea, but it feels heavy to me and like it may suit slower release cycles better. Maybe that's because MS is still shipping installed software tools (TFS in this case).

"We’ve done it 3 times now over the past ~7 years and have been happy with the results every time"

This comment confirmed it for me. I'm interested in companies who are using this model in a context where software is released continuously or at least multiple times per year?

taylaf• 11 years ago

Actually, this team is responsible for both TFS (major releases 1-2 years, minor releases quarterly) and Visual Studio Online which is a hosted service and releases once every three weeks. Pretty much everyone on the team works on both products because they share a very large percentage of their code.

Source: I'm the guy closest to the camera in the picture. Oh, and we're hiring if anyone is interested.

taspeotis• 11 years ago

I don't suppose you're hiring in Brisbane, Australia?

VOYD2• 11 years ago

Nice!

adamtait• 11 years ago

Same. Changing teams every two years seems like a long time. Not mentioned in the post, but I would bet that in Microsoft-land, the release cycle is about two years so it gives a natural transition point. Let's say that an engineer takes 4-6 months to ramp-up on a new team, that still gives 18 months of full productivity. I'm sure that engineers reach 80% of the learning curve was traversed at 12 months.

The fact that it takes them 3-4 days to decide the next round of teams seems very long, in spite the post's insistence that it's short.

I'm interested in environments where teams chose a much shorter cycles. I think shorter cycles would present a different set of challenges, like reducing ramp-up times and cycle decision times. It may also be easier, like reducing the risk of a single cycle decision.

I have heard reports from a company with ~50 engineers who had 2 week cycle times, which was basically their sprint time though releases would have much more frequently. They had the advantage of a mostly homogeneous language and development environment. There kept in up for more than two years, at which point the company pivoted, no longer had a homogeneous dev environment and were doing more greenfield and less support/optimization/incremental-improvement. All reports were great. People were always surprised how the team would even out the teams when put in a single room, where the teams and choices were clear to everyone.

MichaelCrawford• 11 years ago

I feel that continuous and frequest releases do not serve the end user.

It can take time to find and fix subtle bugs. Adding new features introduces new subtle bugs.

Even as a developer, for me to grow happy with a tool often means that Apple will crush my joy by altering thatntool in a way that makes no sense to me.

Today's "UX" is particularly tragic. I find so many user interfaces that make no sense. Perhaps thats because there isnt enough time to solicit feedback from end users.

sitkack• 11 years ago

I wanted this to be teams of 10k people or more, I wouldn't say this is "at scale".

tl;dr Self selected Instant runoff voting of future destiny instead of forcing decisions on workers turns out pretty well.

VOYD2• 11 years ago

I love how the original concept is then convoluted and completely compromised by "early selling" and "manager selection".

Self forming teams at scale

Related Stories