Flat And Independent
Assume that company ABC develops products for customers in domain XYZ as follows:
To remove the “development process” variable from further consideration in this post (because, thanks to consultants, it seems like everybody and their brother thinks process (traditional, Scrum, XP, LeSS, SAFE, Lean, etc.) is the maker or breaker of success), assume that all the teams use the same development process.
As the figure implies, each product is tailor-made for each customer. Since there are no inter-team dependencies and there is no hierarchy in the organizational structure, each team is an island unto itself and fully responsible for its own success or failure.
The tradeoff for this team independence is that the cost of development for company ABC may be higher than alternative strategies due to the duplication of work inherent in this Flat And Independent (FAIN) approach. For example, the above figure shows that components A and B are developed from scratch 3 times and component 2 is developed twice. What a waste of resources, no? However, assuming that components A and B only need to be developed once and reused across the board requires that component A is identical for all customers and component C is identical for customers 2 and 3. However, even though the products are targeted for the same domain this may not be true. The amount of overlapping functionality for a given component is dependent on the amount of overlap between the customer requirements applicable to that component:
If there is zero requirements overlap, or the amount of overlap is so small that it’s too expensive to gauge, then financing three separate component development efforts is more economically viable and schedule-friendly than trying to ferret out all overlaps and embracing the alternative, Hierarchical And Inter-Dependent (HAID) strategy…..
Hierarchical And Inter-Dependent
Now, assume that company DEF also develops products for customers in domain XYZ, but the org employs the HAID strategy as follows:
In this specific instantiation of the HAID (aka product line) approach:
- Core asset component B is developed once and reused three times
- Core asset components A and C are developed once and reused twice
Beside the obvious downside of core asset components D, E, and F being developed but not reused at all (violating YAGNI in this specific case when it actually applies), there is a less obvious but insidious inefficiency in the two layer hierarchical structure: the product teams are dependent on, and thus, at the mercy of the core assets team. The cost and schedule inefficiencies introduced by this hierarchical dependency can make the HAID approach less economically viable than the traditional, seemingly wasteful, FAIN approach. But wait! It’s worse than that. If you’ve been immersed in the HAID way of life for too long, like a fish in water that has no concept of what the hell water is, you may not even know that you’d be better off if you initially chose, or currently revert to, the FAIN strategy.
Inappropriate application of, or poor execution of, the HAID approach to product development reminds me of the classic framework dilemma in software development. You know the feeling. It’s when you break out into a cold sweat after you choose a development framework (or development process!) and you suddenly realize that you’ve handcuffed yourself into submission after it’s too late to reverse the decision. D’oh!
I guess the moral of this story is nothing new: “just because you changed strategies to become more effective doesn’t make it so.” Well, maybe there is no moral, but I had to end this post some-freakin’-how.
My previous post highlighted inter-company culture clashes. This followup highlights the most insidious intra-company culture clash:
Without deviation from the norm, progress is not possible – Frank Zappa
The further a new idea deviates from the norm, the more resistance there will be to its adoption – and the deviance/resistance relationship is ominously nonlinear:
Since it’s human nature to prefer the familiar over the comfortable, passionate purveyors of new ideas that have proven to work for themselves and their orgs better take heed: the way you promote a deviant idea matters.
The more radical your idea, the more graceful you must be in your advocacy in order for the idea to have any chance of infiltrating the mainstream. If both your idea and your approach are radically extreme, then you’ll likely be perceived as a frontal assault idiot by not only those few in power, but those many on the front lines who would otherwise become your allies.
Even if you eschew a militant stance and adopt a graceful approach toward getting your deviant idea widely accepted, the odds are still stacked against you because of the powerful “familiar over comfortable” force field that keeps the status quo in place.
Of course, if I was unemployed, or actively looking for a new job, I would have replied differently to the solicitation. Wouldn’t you have?
Assume that, in order to prevent chaos from reigning in your organizational processes, you design and place into operation a change management system.
In order for your system to be effective, the turnaround time (i.e. latency), from request to disposition better be low enough so that people will be motivated to participate in the system.
If, over time, you keep adding more and more evaluation rules to your system and imposing more and more pre-conditions (e.g. requiring a formal ROI analysis paper) on your proposers, your system’s latency will keep rising and its effectiveness at managing change (accepting the good and rejecting the bad) will keep decreasing. People will conclude that it’s just not worth their time to traverse your bureaucratic gauntlet. In the extreme case, your system will automagically morph from a change management system into a change prevention system – and you may not even know that it has happened.