The flawed model
You've probably seen this kind of model - the idea that "Cross-functional feature teams are able to deliver vertical slices of value". So, basically, you'd design a team where at least one team member can tick the box in each of the quadrants: |
| Does "Vertical slicing" mean you can do all things on the horizontal domain on the vertical domain? |
Here's why:
The model makes a massive assumption: that a "product" has only these dimensions. That may be a developer's (or IT person's) point of view. But - is that really true?
The hidden third dimension
 |
| Yeah, the Business - who cares about the business? Is that even important? |
Typical Sales splitting lines could be products, channels, markets or regions or customer segments. So, even each of the single business domains could turn out to have multiple sub-dimensions.
In large enterprises, the model is no longer two dimensional, "horizontal or vertical slices", it's multi-dimensional with a potentially incomprehensibly large amount of dimensions!
As such, we're not even making "slices" - the delivery of value would mean that we have to cut across n dimensions!
Defining your Product
Once we realize that we're crossing borders in more than two dimensions, we need to answer the question of "What is the product we're working on?" |
| Crossing what? |
Let me take, for example - a company that wants to add Widgets to their portfolio.
Widgets need to appear in search engines, on commercials, linked to the Online Shop so that people can buy them - Widget contracts need to be bullet proof both in procurement and fulfilment - Widgets need to get shipped to the buyers, who need to get charged correctly for their Widgets - have the amount collected from their account - and finally, customer service may need to settle disputes on Widget purchases. The simple "Widget" may thus require changes to a whole boatload of technical platforms, across a wide range of business processes - and there is no "end to end customer value" until all of these functions are implemented!
This, of course, begs the question:
Can a single team of developers manage all of this?
If the business processes, technology landscape and development processes are sufficiently simple, the answer may be "Yes".
And what if they aren't?
What if there are independent technical solutions for Online Shopping, retail, B2B sales, wholesale?
What if ERP doesn't happen in the CRM solution? And what if fulfilment is outsourced to a third party? All these conditions are normal in Large Enterprises.
Organizing Teams
Especially when transitioning towards an agile organization, it's important to accept current reality and learn to understand where we are, then move from there."You go to war with the army you have -Most traditional organizations are set up to optimize IT for utilization - that is, there are different departments, groups and teams to do fragmented work:
not with the one you'd wish to have at a later time."
- Donald Rumsfeld
The Classic IT Model
Classic IT is typically specialized with "project groups" where an IT project manager oversees teams specialized in a subset of technical Engineering domains, and -depending on project size- also specialized in a subset of technologies.These teams are cross-functional in no dimension and can not deliver "full slices" of anything. They do piecemeal work and depend on other teams for everything.
From here, we get into the question: "Which direction do we want to go?"
Cross-Functional Development Teams
Scrum, among other models, assumes cross-functional teams - but what Scrum actually means is "cross functional in engineering", that is - analysis, development, test, deployment and operation are done within the same team.Re-organizing especially smaller projects into one or two cross-functional development teams who have full control over their development process "from requested to Done" across the entire project's tech stack is a simple exercise. Breaking the team boundaries also opens the door to DevOps and thus offers some performance benefits.
Technical Component Teams
The clarification of "technical component" is important for later - because there are also business components.An alternative approach in highly fragmented organizations is to bring together teams that can do end-to-end work on technical components. Breaking the barriers between analysis, test and development for certain technologies (e.g., a Database) can already be a quantum leap forward.
The downside is that such technical component teams need to constantly communicate and synchronize with other technical component teams to deliver anything that works.
The reason why technical component teams might actually make sense: If we have monolithic components used by multiple business processes and other technical components, then we may have nobody except these component specialists who can actually work with this component.
An example would be a centralized Enterprise Database which serves as single source of truth for Campaign Management, Sales, Customer Service, ERP and Revenue Assurance.
Such components are a pain to work with, but if that's what you have - you need to work with it.
Typically, these technical components become the bottleneck in most development efforts, so regardless of the size of the technical component team, there will always be a lot of coordination, stress and blaming going on.
Business Component Teams
While certainly preferable to technical components, Business Components are the same as technical components, on a different level of abstraction: Consider, for example, an out-of-the-box CRM platform that serves as a central customer database, and provides a frontend for typical business user processes.While IT may claim that this CRM is a "vertical slice" and "provides end to end customer value", this only works when we have an extremely narrow definition of "end to end", "customer" and "value".
A CRM company can create an entire business model out of providing a standard product with a standard User Interface and standard functions like "create user, administer account, CRUD customer, CRUD product, CRUD order" - so the CRM company can "provide end to end customer value" to their customers, that is, companies buying their solution.
The picture looks different when an enterprise buys the CRM solution and integrates it into their business landscape: a new product is configured in the Product Management Tool, product information is provided to the CRM via API, and the CRM has to offer business insight information via API to ERP, DWH - and even business partner platforms!
In this case, the entire CRM solution is merely a component of a larger ecosystem - making the CRM team not a product team, but a component team - by nothing other than a change of perspective!
End to End Value Delivery Teams
Is it feasible to simply assume that someone who was formerly a Java coding specialist for a CRM system to take coding responsibility for the python product management and ABAP ERP as well? That's not universal to answer - yet if the answer is "No", then having business component teams with end to end responsibility for a single component's stack and processes is probably already the limit.Given this scenario, an "end to end value delivery team" would need the ability and expertise to work across a wide range of business processes, technologies and development functions. Using the initial 3D model, such a team doesn't deliver "vertical slices" - it serves "multidimensional cubes"!
While this may be a very fascinating perfection vision, when asking the question, "How do we work today - and how do we want to work tomorrow?" - most organizations are not even remotely at a level where it's a feasible option to immediately regroup into small teams that combine all development, technology and content expertise of the entire company!
The False Dichotomy of Feature Teams
Some agilists have very strong opinions about whether we should do "Feature Teams or Component Teams" - promoting the advantages of "feature teams" and listing the disadvantages of "component teams". Yet, when taking all the previous factors into play, we quickly realize that "feature team vs. component team" is a false dichotomy.Cross-Functionality vs. Specialization
Feature Teams are Cross-Functional and Component Teams are specialized - that's easy to proclaim. What's assumed, yet never pronounced: "Feature Teams are cross-functional in development process and technology, but specialized in the business content domain."If we look at development from different perspectives, the statement boils down to "feature teams are specialists from a business perspective - component teams are specialists from a technical perspective." Therefore, "teams are specialists" poses a false dichotomy. All teams specialize in something.
Component work vs. end-to-end customer value
Component Teams deliver piecemeal that needs to be integrated, whereas Feature Teams can deliver end-to-end customer value. Again, we have a hidden assumption: the "customer". If we consider "the customer" to be a project, then a database operations team can well claim to deliver end-to-end customer value: from installation over configuration to access management and service requests, the team does everything.Would we agree that AWS is a component of software systems? As an Enterprise application developer, yes. As a member of Amazon, working in the AWS development unit, this component is the product! Does Amazon deliver a product with features - or are they delivering piecemeal that needs to be integrated?
We end up at the same problem as before: by assuming a different perspective, one person's "component team" may be another person's "end to end customer value delivery team". Therefore, "teams deliver end to end customer value" is yet another false dichotomy. Depending on how the customer is defined, all teams (or: no teams) deliver end-to-end customer value.
Levels of abstraction
Component Teams work only on a small portion of the Value Stream, whereas Feature Teams can deliver a Feature across the Value Stream. There's another hidden assumption: that the "Value Stream" is an absolute, and has only one definition.Returning to our AWS example - the AWS platform is merely the technical platform of an Enterprise Platform. Suppose that Enterprise Platform spans a business process, then that platform is just a component of an Enterprise Process. And if that process is part of a Value Stream, then that process is again just a component. And that value stream may be a component of a Value Chain, ... again: component. And if that value chain is used by another company: again: component.
The bigger we perceive the system, everything we previously considered "end to end" becomes a component on the next level of abstraction. As the complexity of an Enterprise grows, there may be a myriad of abstraction layers. Eventually, it becomes impossible for any single person to even understand how many technical changes need to be made in order to provide "end to end customer value", or: vice versa - how much new "end to end customer value" can be generated by a single technical change.
Therefore: claiming that a team "delivers end to end customer value" poses even a second another false dichotomy: it assumes an organization without abstraction layers. Only when a single team has direct access both to the low-level tech stack of all components and the end customers of the value chain - only then will any team ever deliver end to end customer value.
Aligning mental models
In the dispute of "feature teams or component teams", we need to clarify some terminology, concepts and expectations - otherwise, we get nowhere.Specialization
We have explored in depth the different potential domains of specialization: development specialists, technology specialists - and content specialists. By now adding the question of abstraction layers, we need to also answer the question of layer specialization. The term "full stack developer" assumes a developer working on the tech stack of a single business platform - not a potentially infinite array of business platforms with a potentially infinite array of tech stacks. At some point, the "full stack developer" would become a "Master of (almost) none." - and whether they'd actually be a "Jack of all trades" becomes increasingly doubtful as the stack grows.We need to agree on what we call "specialization" and in what context we expect "generalization", lest we're potentially talking about "being everything for everyone".
"We can't do everything for everyone everywhere, but we can do something for someone somewhere."
- Richard L. Evans
End to End Work
When we talk about end-to-end, we have different concepts, and things become difficult from there.A really obvious example is the difference in definitions of "lead time". Whereas the common Lean understanding is that it's the time between initiation and completion of a process - this gets defined differently. While most IT project managers would calculate "lead time" as the time between when a development project gets approved and closed, the book "Accelerate" defines "lead time" as the time between "code committed" and "code deployed on Production".
Returning from the specific idea of "lead time" - one person may define "end to end" as "from customer to customer", another as "from request to delivery", another as "from development to deployment", and yet another as "from build to production".
We need to agree on the definition of "end to end", to make any discussion around "end to end teams" meaningful.
Components
We have already exhausted the subject of abstraction levels. While Software Vendors deliver certain Products, these products are just components of bigger enterprise architectures. Software Integrators do nothing other than customize and integrate one of more of these "products" into a software landscape. And even an entire array of vendor products, fully integrated into a business process - may be seen as but a component of a larger value stream.It's irrelevant of how many layers of abstraction we have in an organization - everything one layer below is a "component". By adding one abstraction layer, every "product" turns into a "component".
We need to agree on the abstraction level we're talking about, otherwise every discussion around "component vs. product" is entirely futile.
Systems
I have painstakingly avoided the term "system" wherever possible here. The reason: everyone has a different understanding of what "The System" is supposed to be!When we're talking about "The System", do we mean a piece of software? Do we mean the larger architectural context within which this piece of software operates, its integration context? Or do we mean the development organization developing (and integrating) said software? How about abstraction layers? How would "the system" look like at another abstraction layer?
It's common that a developer means "the piece of code that's running on a server" when they use the term "the system" - whereas a business user might consider a complex, b2b mesh of services encapsulated by a single frontend to be "the system". A systems thinker would abhor both ideas, and would equally include processes, rules and people into "the system".
We need to agree on a common understanding of "the system", lest different understandings generate confusion and misunderstanding.
Complexity
When deciding whether a team is doing simple, complicated or complex work - we're quickly falling into the trap of category errors, because "complexity", like "end to end", depends on the domains we consider. Software development is pretty simple for a single piece of content and in a single technology. As we cross technology boundaries, a simple feature can quickly become a monstrosity of technical complexity - and as we cross content boundaries, possibly even organizational boundaries - even technically simple changes can become infinitely complex.The problem: Until we have decided the dimensions in which we assume linearity and the dimensions in which we have variation, we do not understand how much complexity we're actually dealing with!
Whereas common sense dictates that "complexity" needs to consider all relevant dimensions, these dimensions can become infinite - making everything so complex that the very word becomes meaningless!
We need to agree to what we call "complexity" - and what we don't.
Bringing the right people together
After much philosophical ado, we can use all of the above to determine how to organize teams.
A team is able to work with minimal constraints if it is:
- Appropriately specialized, i.e. they don't rely on third parties for knowledge
- Doing end-to-end work, i.e. don't have handovers as part of their process
- Able to work on all relevant components, i.e. don't give or receive "orders" for component work
- Autonomous within the overarching System, i.e. team performance depends on the team and not outside factors.
- Feasibly complex, i.e. given the complexity of all relevant domains and the cumulative skills of all team members, there's a realistic learning curve
Will the outcome of these five factors be a "feature team" or a "component team"?
Back to square one - that's a false dichotomy. And it's the wrong question.
In most organizations, it will be a huge struggle and steep learning journey to form such teams, and it's entirely moot to discuss how we label them.
Before even considering whether we should re-organize, we should ponder whether any of the above five factors is currently the hindering constraint in organizational performance.
If, instead of all of these, the performance constraint rests outside the current teams - for example, in policies and procedures, in politics or processes, in budget or timelines - then it's entirely irrelevant how teams are organized, as even the "ideal feature team" would still suffer from the same constraints.
Conclusion
The entire discussion of "feature teams or component teams" is a red herring.
Reorganizing teams is only relevant if it elevates the current constraint - and the question is not whether it should be a "proper Feature Team" or whether "component teams have dependencies".
The right question is: "will the reorganization elevate the constraint on the current system?" - only if that is the case, then will the new team structure generate any better outcomes than the previous structure!
Hence: Work on your systemic constraints. Bring those people together who can elevate the constraint. Just let people work until the team structure is the constraint! And don't assume it is until you have supporting evidence!
No comments:
Post a Comment