Comments on: The Benefits of Feature Teams http://blog.mountaingoatsoftware.com/the-benefits-of-feature-teams Succeeding With Agile® Wed, 08 Feb 2012 15:06:15 +0000 hourly 1 http://wordpress.org/?v=3.3.1 By: Mike Cohn http://blog.mountaingoatsoftware.com/the-benefits-of-feature-teams/comment-page-1#comment-265830 Mike Cohn Wed, 14 Sep 2011 16:33:00 +0000 http://blog.mountaingoatsoftware.com/?p=454#comment-265830 Hi Mike-- I'm with you. After doing agile, I don't know how anyone can go back to older ways of working. They are so joyless, comparatively. A lot of projects will include a team doing the pure maintenance work. That comes with all the drawbacks it has with a traditional development model. But if you do that, you're right, I would rotate people onto and off that team. No one would want to be on such a team forever. Hi Mike–
I’m with you. After doing agile, I don’t know how anyone can go back to older ways of working. They are so joyless, comparatively. A lot of projects will include a team doing the pure maintenance work. That comes with all the drawbacks it has with a traditional development model. But if you do that, you’re right, I would rotate people onto and off that team. No one would want to be on such a team forever.

]]> By: Mike http://blog.mountaingoatsoftware.com/the-benefits-of-feature-teams/comment-page-1#comment-265786 Mike Wed, 14 Sep 2011 14:28:46 +0000 http://blog.mountaingoatsoftware.com/?p=454#comment-265786 Hi Mike, I drank the agile/lean Kool-aid a few years ago and I'll never go back. :) We are transitioning from component teams to feature teams across our product group. This is great for new development, but defects are still reported against components. A lot of our work is still around sustaining engineering. (Our product quality isn't where it needs to be yet.) Are there any best practices around sustaining engineering during this transition? Would you have a sustaining feature team, maybe on a rotating basis? Thanks in advance. Hi Mike,

I drank the agile/lean Kool-aid a few years ago and I’ll never go back. :) We are transitioning from component teams to feature teams across our product group. This is great for new development, but defects are still reported against components. A lot of our work is still around sustaining engineering. (Our product quality isn’t where it needs to be yet.) Are there any best practices around sustaining engineering during this transition? Would you have a sustaining feature team, maybe on a rotating basis?

Thanks in advance.

]]> By: Mike Cohn http://blog.mountaingoatsoftware.com/the-benefits-of-feature-teams/comment-page-1#comment-186036 Mike Cohn Wed, 13 Apr 2011 19:47:53 +0000 http://blog.mountaingoatsoftware.com/?p=454#comment-186036 Hi Alaa-- Thanks for your kind words. I believe in the scaling chapter of Succeeding with Agile, I also mention that sharing a team member between a feature and component has the big downside of promoting multitasking, which is something I find very, very detrimental. I mention the approach of sharing a team member as a valid way to help early identification of dependencies between teams when it is necessary to use a component team. In general, I still advise using feature teams in most cases. A large, complex project will have a component team or two but the number of them should be minimized. Hi Alaa–
Thanks for your kind words. I believe in the scaling chapter of Succeeding with Agile, I also mention that sharing a team member between a feature and component has the big downside of promoting multitasking, which is something I find very, very detrimental. I mention the approach of sharing a team member as a valid way to help early identification of dependencies between teams when it is necessary to use a component team. In general, I still advise using feature teams in most cases. A large, complex project will have a component team or two but the number of them should be minimized.

]]> By: Alaa http://blog.mountaingoatsoftware.com/the-benefits-of-feature-teams/comment-page-1#comment-185857 Alaa Wed, 13 Apr 2011 13:09:16 +0000 http://blog.mountaingoatsoftware.com/?p=454#comment-185857 Hi Mike, First, Thank you for your continuous support in this Scrum ever-lasting journey. I have been reading your book "Succeeding with Agile", and the feature team/component team debate is always in my head. You mention the use of component teams sparingly and always project an end to it. Then in scaling scrum, you mention sharing team members between component teams and feature teams to manage dependencies. And because of that I got confused of whether I should find a way to get rid of component teams, or use sharing of members. How would large product companies use Scrum then? A product with an underlying framework and vertical applications on top of it, would not allow in my opinion vertical team members un-specialized in the framework development, to work on new features for this framework. Thank you for your continuous support and guidance. Hi Mike,

First, Thank you for your continuous support in this Scrum ever-lasting journey. I have been reading your book “Succeeding with Agile”, and the feature team/component team debate is always in my head. You mention the use of component teams sparingly and always project an end to it. Then in scaling scrum, you mention sharing team members between component teams and feature teams to manage dependencies. And because of that I got confused of whether I should find a way to get rid of component teams, or use sharing of members.

How would large product companies use Scrum then? A product with an underlying framework and vertical applications on top of it, would not allow in my opinion vertical team members un-specialized in the framework development, to work on new features for this framework.

Thank you for your continuous support and guidance.

]]> By: Lanooba http://blog.mountaingoatsoftware.com/the-benefits-of-feature-teams/comment-page-1#comment-64435 Lanooba Thu, 21 Jan 2010 21:58:05 +0000 http://blog.mountaingoatsoftware.com/?p=454#comment-64435 Thanks Mike. We're taking up your recommendation and looking at ways to restructure the team. Thanks Mike. We’re taking up your recommendation and looking at ways to restructure the team.

]]> By: Mike Cohn http://blog.mountaingoatsoftware.com/the-benefits-of-feature-teams/comment-page-1#comment-63465 Mike Cohn Wed, 06 Jan 2010 02:28:27 +0000 http://blog.mountaingoatsoftware.com/?p=454#comment-63465 Hi Lanooba-- Thanks for joining the discussion. We all appreciate it. Without visiting your company and learning a lot about the project I can't really say exactly how *your* teams should be structured. But, September is a long time away and I wouldn't hesitate at all to change to what I thought a better team structure with that much time left on the project. Good luck with it. Hi Lanooba–
Thanks for joining the discussion. We all appreciate it.

Without visiting your company and learning a lot about the project I can’t really say exactly how *your* teams should be structured. But, September is a long time away and I wouldn’t hesitate at all to change to what I thought a better team structure with that much time left on the project. Good luck with it.

]]> By: Lanooba http://blog.mountaingoatsoftware.com/the-benefits-of-feature-teams/comment-page-1#comment-63441 Lanooba Tue, 05 Jan 2010 19:19:58 +0000 http://blog.mountaingoatsoftware.com/?p=454#comment-63441 Mike: I'm a frequent lurker in your blog; this is the first time I'm posting. :-) I'm new to a distributed team who's having a very hard time with their delivery. At the time of creation, the team was divided by components and there have been several large misfires regarding the design and architecture (note: there is not yet an enterprise architecture framework). The end product is due at the beginning of Q3 and I'm wondering if it's too late to reorganize them into feature teams. What do you recommend? Mike:

I’m a frequent lurker in your blog; this is the first time I’m posting. :-)

I’m new to a distributed team who’s having a very hard time with their delivery. At the time of creation, the team was divided by components and there have been several large misfires regarding the design and architecture (note: there is not yet an enterprise architecture framework). The end product is due at the beginning of Q3 and I’m wondering if it’s too late to reorganize them into feature teams. What do you recommend?

]]> By: Mike Cohn http://blog.mountaingoatsoftware.com/the-benefits-of-feature-teams/comment-page-1#comment-63259 Mike Cohn Mon, 04 Jan 2010 03:02:05 +0000 http://blog.mountaingoatsoftware.com/?p=454#comment-63259 Hi Jay-- Absolutely. There is occasionally the need for a component or layer to come under the stewardship of a particular team. That's an occasion when I would use a component team. However, there are fewer of those occasions than most teams think. In other words, it is very rare that I consult to an organization and tell them they need more component teams. I often tell them they need fewer. (And of course sometimes they've got it right.) Hi Jay–
Absolutely. There is occasionally the need for a component or layer to come under the stewardship of a particular team. That’s an occasion when I would use a component team. However, there are fewer of those occasions than most teams think. In other words, it is very rare that I consult to an organization and tell them they need more component teams. I often tell them they need fewer. (And of course sometimes they’ve got it right.)

]]> By: Jay Ennis http://blog.mountaingoatsoftware.com/the-benefits-of-feature-teams/comment-page-1#comment-63020 Jay Ennis Fri, 01 Jan 2010 19:05:35 +0000 http://blog.mountaingoatsoftware.com/?p=454#comment-63020 Mike, What about the need for some stewardship in each component/layer of the product architecture? My experience has been that unless each part of the software system is owned by a team that takes pride in it and responsibility for it, technical debt builds up very quickly. While I can see where feature teams might be great for time to market of short-lived products, I question the suitability for products that will be actively developed over many years. I'd really appreciate your thoughts on this. Mike,

What about the need for some stewardship in each component/layer of the product architecture? My experience has been that unless each part of the software system is owned by a team that takes pride in it and responsibility for it, technical debt builds up very quickly. While I can see where feature teams might be great for time to market of short-lived products, I question the suitability for products that will be actively developed over many years. I’d really appreciate your thoughts on this.

]]> By: Mike Cohn http://blog.mountaingoatsoftware.com/the-benefits-of-feature-teams/comment-page-1#comment-61680 Mike Cohn Thu, 17 Dec 2009 14:52:47 +0000 http://blog.mountaingoatsoftware.com/?p=454#comment-61680 HI Tribhuwan-- Yes, there are times when a project can benefit from component teams. I always want to be careful in saying that, though, because what I've found is that if I open the door that such teams can be used *occasionally* there are some who will use that to justify such teams in all cases. Use them cautiously and try not to institutionalize one (i.e., have it live forever). HI Tribhuwan–
Yes, there are times when a project can benefit from component teams. I always want to be careful in saying that, though, because what I’ve found is that if I open the door that such teams can be used *occasionally* there are some who will use that to justify such teams in all cases. Use them cautiously and try not to institutionalize one (i.e., have it live forever).

]]>