Use Feature Teams. Yes, Use Component Teams

Last Updated on Thursday, 27 June 2013 02:18 Written by Andrew Fuqua Tuesday, 2 July 2013 07:59

This is a follow-on to my post on starting an agile transformation with Structure 1st and to Mike Cottmeyer’s great article on feature teams and component teams and is based on some discussions I’ve had with Dennis Stevens. In fact, I stole some of this text directly from Dennis.

At some scale, having pure feature teams will break down. That’s not to say you won’t have feature teams at all. On the contrary, at scale, we should have product facing feature teams. However, the specialist skills, services and platforms, that are truly cross product or that are truly technically difficult, should be in component teams.

Feature teams have everything they need to deliver an increment of value for their product. But let’s think about that for a second. They don’t have operating system engineers on the team. They don’t have people implementing a DBMS on the team. They don’t have someone developing network protocols on the team. Most of us don’t have committers to open source libraries on our teams. So they don’t reeeealllly have everything they need. They depend on capabilities delivered from a bunch of reliable services – like the operating systems, data center equipment, 3rd party libraries and network. Similarly, in your company, at the next level higher are additional services or components that your feature teams need. Component or services teams can develop these services and components that the teams in your company need.

Having component teams does not mean you separate the development of presentation, domain, and data management layers into separate teams. Feature teams may work across all layers, but also make use of components and services provided by others. Component teams build domain services and tools to support the feature teams. The feature teams should be consuming those services.

Some specialty resources (for example, those that know 3rd party propriety software, are few in number, and broadly needed) should be in pools and should be scheduled as Non Instant-availability Resources. Give them lots of slack in order to respond quickly and manage that with kanban.

The economic cost of delay on the dependent work supported by the Non Instant-availability Resources and component teams should be the primary drivers in the prioritization of their work. Any team (Feature or Component) that has dependencies on a Non Instant-availability Resource or Component team should be using a 2-tier Feature or Epic level view to coordinate these dependencies and to ensure actual end-user value delivery at the program level, instead of a bunch of components with nothing to tie them together into enterprise level feature sets.

Take care of your org structure 1st. Have feature teams. Yes, have component teams too.

Learn More

Structure 1st: Why You Should Not Start With Practices

Last Updated on Monday, 24 June 2013 11:06 Written by Andrew Fuqua Tuesday, 25 June 2013 08:10

Starting your agile transformation with a focus on practices is not an entirely bad idea, but with the wrong culture and structure, agile practices will be superficial. People will go through the motions. People will do agile things like have standups, demos, and planning meetings. You’ll have stories. It will look agile on the surface. But that’s all it will be — looks. There will be no substantive change, no stable teams, no control over Work-In-Process, no empowerment, and no predictability. You’ll have shallow collaboration, fault-finding and blame, and an unstable velocity. You’ll have no real support for agile or for improvement. You’ll get limited value out of your agile adoption efforts.

This isn’t the 1st time I’ve written negatively about mechanical agile and about how the agile values and culture are more important than the practices. While that is what I know to be true, there is more to the story.

So if starting with practices isn’t the best, where should we start? It’s not wise to start with culture either. Why not? CSM courses talk about practices and agile culture but when people go back to work they hit a structure that doesn’t support it, or they hit a command and control environment that doesn’t allow it. Attempts to change their culture are met with the realities of their organizational structure. Their structure is built around a different set of cultural expectations. The existing structure reinforces the old culture. Changing culture is hard, which is why many organizations start an agile transformation with practices.

Fortunately, deciding between culture and practices as the starting point is a false dichotomy. The place to start is with the structure.

Starting change with structure creates space and safety for practices to be put in place. At this point, we still can’t tackle culture head-on, and the practices will still be superficial at the start, but now there is support for the practices. You’ll have a shot at stable teams, at self-organization within the team, and enough empowerment for making reasonable commitments, leading to predictability. In this way, you can act your way into a new culture. Yes, I’m saying a new culture will emerge, but at this point, some intentional attention to shaping the culture is wise.

When I say structure, I have a few ideas in mind. The first is choosing between feature teams, component teams, services teams, or a mix. There is a great discussion on this topic on the LeadingAgile blog. Feature teams are great when you can have them, but an organization of size and complexity at some scale needs services or component teams added to the mix. Often, large organizations are already structured around component teams. We have to consider whether that is the best structure for their agile implementation.

Another idea I have in mind is just the stability of the team and whether it’s really a team, as opposed to a workgroup or project-group. For agile to work, we must have stable teams. Teams don’t work if management is often moving people around or if people are on multiple “teams”. Teams need to bond, to learn how to work together. Colocation is a huge help. Cross-functional is assumed.

Structure is among the most important concepts to nail for anyone scaling agile. At LeadingAgile we’ve been developing shared understanding on our approach. During this time, I’ve come to appreciate how much you can achieve with structure, along with practices, to create a team-based iterative and incremental delivery setup that is a precursor to agile. Once that is in place and we have some personal safety and delivery capability, some of the other things can begin to emerge, toward an agile culture. At a high level, that is our strategy for how to walk through the structure–practices–culture loop.

Learn More

Organizational Myopia?

Last Updated on Friday, 16 November 2012 12:50 Written by Mike Cottmeyer Thursday, 5 November 2009 08:09

Okay… I want to write a quick little post here to point out something that is becoming increasingly obvious to me. I’ve talked quite a bit over the past year about the ongoing feature team/component team debate. We talk about how agile teams are supposed to deliver an end-to-end cross-functional slice of the application architecture. When applications get big, I’ve talked about how sometimes we have to organize around large scale system components or services. So here is the deal… I think that in practice… most people actually get this. It seems that the more I talk to people doing agile in large organizations… the component team model might be THE primary organizational model in the enterprise.

Great right… no debate? Well… actually no. The problem is in the language we are using. If we are only building component features… software that is theoretically ‘valuable’ to the business… we are not building software that is sellable in and of itself. It is only the integration of multiple services or components that our external customers really care about. To some degree we are deluding ourselves about what we are really creating for the business. We get better at building our feature subset… our component features… but as an enterprise we are not getting any better at getting value out of the overall system. We are not getting better at delivering the end-to-end apps that our customers care about.

I think that to some degree we are guilty of a sort of institutional myopia. Because we can’t control anything outside of our team… because we don’t own, or have influence over, the PMO… over management… over the architecture group… over the integrated feature set… we control what we can control… we pretend the rest doesn’t exist. We focus on our team. We desperately want to be good at what we do and we want to deliver value. We want to do valuable work. So what do we do? We change the rules. We redefine value and call it a backlog item. We redefine our customer and call him a product owner. We say that we are delivering working software that our ‘customer’ wants… but at the end of the day… we are just delivering a piece of the overall puzzle.

Learn More