If you're thinking about an agile transformation, you already know about feature teams. You might even call them/use them as product teams. You might wonder about organizing all the work as product work.
See Your Current Organization
Many organizations use functions to organize people. The “Typical Product Development Organization” shows the kind of organization I see most often. That's why I called it “typical.”
There is a senior functional manager, where the function is Engineering or IT or some name like that. In this image, that's the VP/CIO/CTO.
The middle managers—the directors—often reflect layers in the architecture. I added my “implement by feature” image in a 3-tier architecture to the left. The various development directors correspond to the various horizontal layers in the product.
Each of the directors might have several managers and team members “beneath” them. (Yes, the people are literally underneath their names on the org chart. That's one way that our words reflect our culture.)
If you look back up at the typical org chart, there's a QA Director and TechPubs. Maybe you have a Database Director, too.
Here's the interesting part:
Every architectural layer has a middle manager who reports to the senior manager.
When we design organizations around architectural layers, we invite Conway's Law into the work.
Note that the product management and customer support folks have no representation here. Neither do Finance or HR, or other “Admin” functions. That's a relic of how we centralize “support” functions and report profit and loss to the outside world.
Except, in an agile approach, product management (often via product owners) is an integral part of a high-performing agile team. And, great agile teams often have HR support near the team, if not part of the team.
“Typical” Organizations Don't Support an Agile Transformation
Can people in a “typical” organization make an agile approach work for projects? Of course. They matrix people into teams. With any luck, those teams are long-lived, as I suggested in Project Work vs. Product Work.
Can they create an agile transformation?
Maybe. The organization of the people doesn't create an environment that supports an agile culture.
I see these problems:
- The middle managers' incentives and the entire way the organization manages career ladders and performance is inverse to what an agile transformation demands.
- Product management is not integrated into Product Development.
A “typical” organization uses the ideas of resource efficiency instead of flow efficiency to build the organization. In a real sense, the org chart—how the people are organized—works against the goals of a possible agile transformation. (And, we have Conway's Law, depending on the number of managers.)
We ask the people to collaborate and deliver. The teams can succeed using agile approaches. Rarely does the transformation succeed because we haven't change the culture, specifically, what we reward.
In my experience, unless you change the rewards and recognition system, you can't have an agile transformation.
You might get agile projects and programs. You won't get an agile culture. (See my “Scaling” Agile series.)
The problem is this: if you want an agile transformation, you need to change the culture.
What if we designed the organization for fast creation and delivery of products? See Part 2.
All the posts in this series:
- Project Work vs. Product Work (I didn't realize I'd started this series.)
- Product Orientation Requires Technical Excellence
- Designing an Organization for a Product Approach, Part 1
- Designing an Organization for a Product Approach, Part 2
- Defining the Manager’s Role for a Product Approach, Part 3
- Possible Changes for a Product Approach, Part 4
- Possible Organization Changes for a Product Approach, Part 5
- Starting a Product Organization Transformation, Part 6
I believe there is a conflict between structuring an organization along feature/product lines and business domain lines. To be clear, domain driven organizational structure also suggests cross-functional teams. including front-end, back-end, QA engineers, designers as well as business experts. This is the main tenet of strategic domain driven design. However, a business domain is NOT a product. While there may be some cases when these two patterns are aligned, in most cases a product spans across multiple business domains. How is it possible to reconcile these two approaches?
Thanks, good question. Your note about cross-functional teams is key. I have to admit, I’m trying to think of an example for a business domain that’s not a product. I’m stuck. Maybe you can give me an example.
Here are some options:
– Can you (whomever) create either a large team or a program (collection of projects) that solve the problems the business domains have?
– Is it possible for the business domains to collaborate to define a product? (A product-based organization is not just for the people who create the solutions to the problems. It’s also for the people who have the problems.)
– I’m going a little meta here: what is the ultimate business goal? How “high up” the organization do we need to go, to find a person with a problem to solve? That problem and solution is the “product.”
Product-based organizations solve a problem for someone, where the product has an ongoing life, past this project. (I’m not sure if you saw Project Work vs. Product Work.) If the solution to a problem has a need past one project, it’s a product. If the solution is a one-time thing, it’s not. (Even for me, that’s pretty binary. I’ll have to think about that more!)
If you do have an example to share, I’d love to hear it.
Thanks for the response.
I think the distinction I made between feature/product vs. business domain was a little vague, particularly because of the ambiguity around the exact definition of the term “product”, at least my understanding of it. Let me try to explain with an example.
Lets assume an example company, providing a browser-based online registration to collect information from potential customers who are looking to buy a certain commodity. Once a set of matching options are presented and the customer decides to purchase one, due to regulatory constraints, the closing of the sale becomes an offline process supported by a call center. Now lets also assume that there are 3 new ongoing initiatives.
1- Integration with a third party where the collection of the information regarding the customer’s requirements for the commodity starts at the partner’s website. The potential customer is finally redirected to the example company’s website for the presentation of matching offers.
2- Development of a mobile app as an alternative to the browser based registration.
3- Development of capabilities where the closing of the sale becomes a fully online self-service process.
Both within some company lingo and in some literature, (e.g. a recent blog post I read https://medium.com/nick-tune-tech-strategy-blog/product-aligned-vs-capability-aligned-organisation-design-99309596adde), I have witnessed that such initiatives as the ones I mention above, are all referred to as “products”.
In my understanding of strategic level domain driven design perspective, and with some simplification for the sake of this argument, this example company operates in 3 business domains, registration of customer wish and presentation of offers, offline sales supported by the call center and a new domain represented by the third initiative above, i.e. self-service checkout. All of these domains have distinctively different business considerations, they represent different business capabilities.
If the first two initiatives, mentioned above, are going to be called products, I would argue that building teams around these “products” is not justifiable, except in some circumstances where time-to-market is vital and paying off technical debt later is factored into the overall planning. However, after reading your article re:Project Work vs. Product Work, I think you would rather refer to these as “projects” and not “products”.
To summarize:
– In some contexts I think terminologies such as business domains, business capabilities, feature sets and “products” are used interchangeably and advise is given to align cross-functional teams along these lines
– Again in others, terminologies such as projects and “products” are used interchangeably and general advise seems to be to refrain establishing teams along these lines.
The question then becomes, what is the appropriate definition of product.
Paul, thank you for this clear example and for the link. I will need to think more carefully.
Pingback: Five Blogs – 4 October 2018 – 5blogs
Pingback: New PM Articles for the Week of October 1 – 7 - The Practicing IT Project ManagerThe Practicing IT Project Manager