My two latest posts have dealt with Feature Centric Development (FCD), an “orginizational architecture” pattern that is rapidly gaining popularity in the world of systems and software development.
In this post, I’ll briefly touch upon a couple of the concepts/notions that are frequently heard whenever people talk about FCD.
If you’ve been involved in discussions about FCD, you have probably come across the terms “Feature Team”, “Component Team” and “Cross Functional Team”. What’s the difference ?
IMO (and as anyone who’s been around the world of software engineering for a a couple of decades probably will acknowledge, in our business there are very few if any absolute truths, only more or less relevant opinions) feature teams and component teams are two fundamentally different ways to organize development, where one of the main differences is about ownership: if an organization or project is mainly structured based on system components (“system things”), then what you have is a component team organization. Each team “owns” a set of components, and no other team is permitted to touch any of those components. Requirements (“features”) are decomposed and allocated to the different component teams, by the system architects. On the other hand, if your organization or project is organized around “features”, i.e something that provides business value to a customer, then you are in a feature team organization. In feature team organization, every team has the right to touch the code of whatever part of the system, that is, in order to realize a feature, changes are made by the team, potentially “all over the place”, i.e. in any part of the architecture.
The difference between these two ways to organize is fundamental, impacting virtually every workflow. For instance, if your organization is strictly structured as a set of component teams, you will most likely have a heavy weight “system integration team” in place, i.e. a separate organizational unit responsible for ensuring that all the bits and pieces of the system, i.e. the various “components” fit together. More often than not the pieces will not fit together, at least initially. Daily development is typically performed in individual developer and team sandboxes, and inter-team integration is not a very frequent event. In pure component based setup, teams typically communicate “by contracts”, that is, technical specifications outlining the interfaces are agreed upon, and each team goes away to implement, often in isolation, what those contracts state. At some point later down the stream, often very much later, some poor sod (typically the integration team) is left to resolve all the mismatches between the components. In a component based organization, each team becomes experts in their own component(s), but often fail to see “the bigger picture”, i.e. what the overall system is supposed to do, and what the customer is willing to pay for, and such an organization is often prone to falling into the “not my problem” trap, where everybody takes full responsibility for their own components, but no one (except the poor integration team) assumes full responsibility for the full “system”.
On the other hand, if you are structured as feature teams, you are most likely relying upon “continuous integration”, i.e. a process where the changes of each team, and each individual developer are very frequently, many times per day, merged into the current system main track. The main track is continuously exercised with tests, including a full set of regression testing, in order to minimize the amount of broken code at any point in time. Immediate feedback at system level and “Fail fast, fix fast!” is the paradigm. The prime input to a feature team is a feature (wow! :-), and the task at hand for each of the feature teams is to take that particular feature “end-to-end”, i.e. all the way from understanding what the feature is all about, over what impact it has on the current architecture, what components need to be modified, and finally to implement and test the feature in a full system context. A feature team thus assumes full responsibility for the “end-to-end” evolution of each feature.
A significant difference between these two ways to organize development resides it the way communication occurs: in component organization, communication between teams is typically document based, “by contract”, where requirements are passed from analysts/product mgrs to architects, architectures and specifications are passed from architects to designers, designs are passed from designers to programmers, and programmers pass their code to the integration and verification team. In a feature organization, much of this document driven specification and communication is taken away, because teams, containing all the required roles, are able to have high bandwidth face-to-face conversations, either in real life around a whiteboard, or using or technology, e.g. video calls.
One way to think about the difference between a feature team organization and a component team organization is that of “top down” vs “bottom up“: feature teams take a feature, i.e. a “top level” statement of desired functionality/capability, and “realize” that feature from A to Z. A component based team organization is building the system (and thus indirectly the capabilities that will eventually provide the set of features) “bottom up”, i.e. by implementing functionality/API’s that “might be needed” by some future feature.
Another way, perhaps a bit more philosophical, to think about the difference is in terms of “holistic” versus “reductionist” system view: the feature based organization operates in a “holistic” manner, where the focus of everyone is on the capabilities of the system that the end user (the customer) is willing to pay for. That is in stark contrast to the component team organization, which from a philosophical point of view is a reductionist approach, where the system is nothing more and nothing less than the aggregated sum of the components it contains.
So, is a feature team organization “better” than a component team organization….? Yes and no, IMO. “Yes”, because the holistic view will help in building the system faster and particularly with better probability that the system will meet the needs of the customer. “No”, because some types of systems have characteristics, e.g. inherent complexity, that demand a specialized team for realizing the capabilities of some or other subsystem. For instance, if you are building anything a smidgen more complex than a web-application, chances are that you will need to build some sort of “framework” or “middleware” to support the features that will eventually provide the core capabilities of your “system”. To build that framework, you would probably want to employ a component team, with the responsibility to make sure that the framework is capable of supporting future functionality growth, and that it meets all the non-functional (“non-feature”) requirements such as scalability, robustness, extensibility, portability etc. Then, when you at least have an embryo of that framework in place, you might want to organize the rest of your teams by features, where the feature teams now should be capable of using all the cool API’s of the framework to realize the needed customer facing features.
Thus, as so often in systems and software development, a combination of “bottom up” and “top down” approaches is what is needed.
So, now that we’ve covered “component teams” and “feature teams”, what about cross functional teams ?
Good question! IMO (remember, there are few truths in our business, only opinions!) a cross functional team is a team that contains all the roles required for producing an end-to-end result (e.g. realizing a feature from A to Z). To me, a feature team is naturally realized as a cross functional team, that is, a feature team contains all the roles (architect, designer, programmer, tester etc) required to take a feature end-to-end.
However, I can also imagine – albeit I’ve seen very few instances of this pattern – to have a component team realized as a cross functional team, containing all the roles required. The reason I’ve yet seen very few instances of this latter type of component based cross functional team is probably due to the at least a century old tayloristic industrial organizational pattern still so common in our industry, with a clear division of roles and work, where system architects, designers, programmers, testers etc each sit in their own functional silo, and at the time where the rubber finally hits the road, i.e. when all the documents and spec’s produced upstream finally hit real implementation – i.e. the poor programmers – the upstream roles are long gone to work on other stuff….
A good example (?) for a true cross functional team is that of the surgery team in a major hospital’s emergency room, with several multi-disciplinary roles such as the surgeon, the anaesthetist, the nurses etc involved, all acting as a team realizing a “feature”, i.e. something of value for the “customer” (saving the patient).