Seeing system dynamics in organizational change: 2) local optimization and system optimizing goal
This is the second article in the series of seeing system dynamics in organizational change. We shall learn where the local optimization comes from, and how important it is to define a clear system optimizing goal and use that to guide the change.
"It is more cost-efficient to test many requirements at once." This is a typical local optimization. Why do we do this?
B1-loop: Test many requirements at once to save cost
Once there is cost pressure, we increase the number of requirements in one test run, so as to reduce testing cost. Then, cost pressure is relieved.
We do this because the fixed cost of one test run is high, e.g. it takes much effort to set up the test environment. So, we do not make local optimization on purpose, but just try to solve a problem.
Why is it a local optimization? Let's zoom out.
In the upper left side, it is the original B1-loop. Now, we pull more variables into the picture. When we increase the number of requirements in one test run, we increase the waiting time. On one hand, this directly increases cycle time. On the other hand, this delays the feedback, and causes more rework. The rework increases development cost (here we apply the traditional distinction between development and testing). The total cost is the sum of testing cost and development cost, thus, it may increase too. Meanwhile, the rework also increases cycle time.
In summary, if we look at the "global" effect from increasing the number of requirements in one test run, while it reduces testing cost, it increases development cost, and possibly total cost as well; and it increases cycle time.
There are actually two different kinds of local optimizations here.
- Reducing testing cost may increase total cost. This reflects that "optimizing the parts does not optimize the whole".
- Reducing cost may increase cycle time. This begs the question - what do we optimize for as a whole? I.e. what is our system optimizing goal?
System optimizing goal
If we reduce cost but increase cycle time, is it a local optimization? We could not really answer it, before we are clear about our system optimizing goal. If our goal is cost efficiency, it may be a global optimization; but if our goal is cycle time, it is clearly a local optimization.
System optimizing goal should be defined in our change vision, otherwise, we do not have solid foundation to guide the change. One of the common change efforts these days is the agile movement, what does it optimize for? It is for agility and adaptiveness, as well as maximizing customer value and reducing cycle time; but not for throughput, resource utilization, compliance, cost efficiency, etc. If the goal is not clearly set, our change effort is doomed, as local optimization would be "natural".
Even though we set cycle time as our system optimizing goal, some people may still have the cost concern. They say: "Yes, cycle time is important, but we also need to consider cost. It is simply too costly to test one requirement at a time, thus, we have to stick with the current practice of testing many requirements at once." Other people nod and the group dismiss. Craig Larman calls this "losing the plot".
In the organizational change, we need to make clear distinction between system optimizing goal and secondary concerns. We shall not solve secondary concerns at the expense of system optimizing goal. Secondary concerns should be addressed in other ways.
In this case, it means that we should break the B1-loop, while introducing an alternative B2-loop to solve the cost concern.
B2-loop: Reduce the fixed cost in one test run
Once there is cost pressure, we increases the effort on automating test setup, which reduces the fixed cost in one test run, thus testing cost. Then, cost pressure is relieved.
In summary, it is important to set clear system optimizing goal for our change, which helps discern all sorts of local optimizations. Then, we address secondary concerns in ways that do no harm to our system optimizing goal.
Seeing system dynamics in organizational change: 1) from change resistance to limits to growth
I have written a series of blogs focusing on seeing system dynamics in organizational design. Now, i'd like to start a new series, focusing on organizational change.
In this first one, let's understand three common problems in organizational changes:
- change stalls after it is initiated, due to change resistance;
- change stalls after it is "done", due to goal seeking behavior;
- change stalls after it grows for a while, due to limits to growth.
Why is change resisted? A basic balancing loop is at work.
B1-loop: Change is resisted to keep status quo
Once we increase change effort, the actual increases, moving away from the goal. This increases the gap, thus, another "change" effort starts, which brings the actual back to the goal (as shown in the small arrow line at the right hand), then gap is reduced.
The goal is the status quo, and the "change" effort is change resistance. What is called change resistance is simply a force to bring the system into the stable state. Notice that there are two change efforts in the diagram. Change effort moves the actual away from the goal, while "Change" effort moves the actual back to the goal. From system perspective, they are both change forces, and neither good nor bad.
Instead of exerting more change effort, which invokes more "change" effort (i.e. change resistance), one leverage is to elevate the goal. As will be discussed in next sections, the change resistance disappears when the goal is kept above the actual continuously. This explains why many change attempts failed due to change resistance. Without the common change goal, people in the organization would naturally try to keep the status quo.
Once the goal we seek is higher than our status quo, the dynamic changes.
B2-loop: Change is done to achieve the goal
The goal increases the gap. Change effort starts to increase the actual, which brings it towards the goal (as shown in the small arrow line at the right hand), then gap is reduced.
This balancing loop actually is no different than the B1-loop, and they both seek goal. However, as the goal in B1-loop is the status quo, thus, we see the resistance to change; while as the goal in B2-loop is the higher state than the status quo, thus, we see the support to change, till the point that the goal is achieved.
After the goal is achieved, the change is done. The goal state becomes the new status quo. How could we continue the change towards even better state? One leverage is again to elevate the goal.
Grow the change
After the original goal is achieved, we elevate the goal again to grow the change.
R1-loop: Elevate the goal to grow the change
Once the actual increases to reach the goal through B2-loop (as shown in the first small arrow line at the right hand); we elevate the goal. Now, the B2-loop is at work again, until the new goal is reached (as shown in the second small arrow line at the right hand), we elevate the goal again. This is the essential continuous improvement.
Ideally, we would grow the change indefinitely. However, the change still stalls after a while, as there are limits to growth.
Limits to growth
In order to change the actual, it requires not only the effort, but also the capability. Capability here refers to all kinds such as organizational, technical, collaboration, and etc.
B3-loop: Capability shortage to limit the change growth
Once the goal is elevated, the required capability increases. While the available capability is the constraint, it leads to the increasing capability shortage, which decreases the actual.
R1-loop and B3-loop create the typical "limits to growth" system archetype. In order to keep growing the change, one leverage is to build the capability earlier, as it will take time. Various constraints will be exposed along the way, but in the context of product development organizational change, some are well known. One of them is the technical weakness unfortunately seen in many development organizations. This is why for example in LeSS, it is recommended to start technical coaching for a few months before doing organizational redesign. This is to remove the constraint before we hit it.
In summary, in order to grow the change forever (i.e. continuous improvement), the main leverages are as following:
- create the common goal to be higher than status quo, in order to avoid the change resistance
- elevate the goal to grow the change, in order to avoid the change being stalled after it is "done"
- remove the constraints earlier, in order to avoid the change being stalled when hitting the limits
Zoom out and see the big picture of Scrum roles
Zooming out and seeing the big picture is a form of systems thinking, and we see how it helps to understand Scrum roles.
Distributed project management
"Distributed project management" is a very powerful exercise regarding Scrum roles. We start to write down all project management tasks in post-it notes, then, group them based on which Scrum role does it. The below is the typical outcome.
It shows that project management is distributed among Scrum roles, without the role of project manager. The key points for each role in relation to project management are as following.
- Product Owner: manage the release, in terms of items, sprints, and teams
- Team: manage the sprint, in terms of items/tasks, days and team members
- ScrumMaster: develop the team so that members would work together to deliver the product
- Others (undefined in Scrum): form the project team, which is done very differently after shifting from project mode to product mode with Scrum
Often, people would draw another couple of conclusions:
- ScrumMaster does not have much work to do
- Product Owner is the project manager
This is a common manifestation of fast thinking. We started from project management tasks in this exercise. If you reasoned well with slow thinking, you would notice that this only touched the project management work.
The more solid conclusion would respectively be:
- ScrumMaster does not have much project management work
- Product Owner does some project management work
And we still need to see the bigger picture, beyond the project management work.
One important aspect of systems thinking is seeing the big picture. The wonderful children book "Zoom" illustrates the approach of zooming out and seeing the ever bigger pictures, with one sample shown in the below.
Similarly, we zoom out and see the bigger picture of Scrum roles.
Now, we go beyond the project management work, and the bigger picture shows the below.
- Product Owner: the main job for PO is product discovery, i.e. find the valuable work, see 80% product discovery and 20% project management
- Team: the main job for team is product delivery, with self-management, i.e. manage its progress and process
- ScrumMaster: focus on coaching for self-organization and continuous improvement, rather than short-term delivery.
Click "Zoom out":)
My view of LeSS
As part of the LeSS trainer application, I was asked to give a graphical representation of LeSS. Here's the result showing my view of LeSS.
A series of choices
LeSS is a series of choices for the large-scale product development. We could make any choice if we were not clear about the optimizing goal. The choices made by LeSS are optimized for the agility and adaptiveness.
Among others, two choices stand out.
- One Product Owner and one Product Backlog, rather than many Product Owners and many Product Backlogs (team PO as anti-pattern; 1 vs. n product owners; 1 vs. n product backlogs)
- Feature team, rather than component team and feature group (component team vs. feature team; feature team vs. feature group)
To get the informed consent about adopting LeSS, i.e. making a series of choices, we should explore and see the system dynamics behind those choices. This is why systems thinking is critical in understanding LeSS.
Systems thinking sounds great, thus, it could be claimed to be relevant anywhere. LeSS applies it concretely to evaluate the choices you make. What is the system optimizing goal? What are your choices? What are causes behind it? What are consequences from it? Is it consistent to your system optimizing goal?
I am often asked to compare LeSS with SAFe and others. I have no answer, but would like to offer doing an exercise of system modeling on the different choices they make. We evaluate those by applying systems thinking.
When team gets big, we split it into two. How? most typically by dividing into components or sub-components. Why do we split this way? What are the consequences? What are the alternatives? Often, we did not think them through. That is the typical manifestation of fast thinking. However, those choices are so important that they deserve slow thinking. System modeling helps us do slow thinking, and critical thinking.
If you practice systems thinking on your choices, you are free to do experiments that may not be consistent with LeSS. Eventually, you "own" what you do, rather than "rent" ideas from others. Less copying, more learning.
Systems thinking is the cornerstone (i.e. the fifth discipline) for a learning organization. LeSS opens up the stairway to a learning organization in the field of product development. By experimenting and practicing the five disciplines, we move toward the learning organization, while LeSS is a starting point in the journey.
This is my view of LeSS.
P.S. I had to ask my daughter for help in doing this graphical representation. I learned a small detail afterwards. There are two paths to the house representing the learning organization. One is through the back door, which is the shorter route; the other is through the front door, which is the longer route. They happen to be a good representation of fast thinking and slow thinking.
Team Leader vs. Product Owner and ScrumMaster for component team
[Team Leader = TL; Product Owner = PO; ScrumMaster = SM]
The real Scrum requires significant organizational redesign. I have seen two common settings to pilot Scrum: 1) project group and 2) component team, as those are existing structures thus convenient to just use them. However, without organizational redesign, you could not adopt the real Scrum.
In this article, we focus on the setting of component team, and discuss two alternatives before we are ready for organizational redesign to adopt the real Scrum.
Here is the starting point.
Let me clarify a few terms I use here:
- Features are requirements on the product, and they are customer centric and associated with business value
- Component requirements are requirements on the component, and they are actually tasks from the perspective of the product.
- Component tasks are internal tasks in the component.
Traditionally, TL is responsible for the component team, and held accountable for the delivery of the component work.
The fake Scrum with team PO
This is what usually happens while adopting Scrum for component team.
Of course, we introduce the role of SM and PO, right? As there used to be one TL, I have seen a couple of common arrangements.
- TL becomes the PO, who is a team PO as well as a fake PO, as he is clearly not responsible maximizing value for the product; and find another person to be the SM
- TL becomes the SM; find another person to be the team PO.
Usually, regardless of TL becoming PO or SM, the accountability is still kept in the TL.
With Scrum roles in place, 1) team PO creates a fake product backlog for the component, which becomes the single source of the work for the component team; 2) SM coaches team to self-organize in completing the component work.
Those are good progress. However, it misses the most important point behind the real Scrum - maximize the value through inspection and adaptation on the product and features. Therefore, this is the fake Scrum with team PO.
The real "Scrum" with TL
An alternative I would recommend is to keep the TL role but transform the role to 1) do the fake Scrum on the component, 2) shift the focus to the product and features, and 3) advocate for the organizational redesign.
Let me elaborate:
- do the fake Scrum on the component
- consolidate all component work and prioritize (i.e. what the fake PO does)
- coach team to self-organize in delivering the component (i.e. what the SM does)
- shift the focus to the product and features
- connect component work to the product and features
- connect component team to the real PO
- coach team to self-organize with other component teams in delivering the feature
- coach the real PO to inspect & adapt on the product
- advocate for the organizational redesign
- spread the knowledge and experience on organizational redesign to feature team
- prepare with cross-learning and technical excellence
This approach better follows big ideas behind Scrum, even though Scrum roles are missing. Therefore, this is the real "Scrum" with TL.
Only after the organizational redesign to feature team, the team would work directly with the real PO, and it would take end-to-end responsibility for feature delivery. Eventually, TL would be replaced by SM - a coaching role not responsible for the delivery. That would be the real Scrum.
In fact, TL working this way is well defined in the book "Leading Self-Directed Work Teams". It describes the TL role as a boundary manager. Please do not introduce team PO for component team, and TL will do.
Seeing the system dynamic: single-functional team vs. cross-functional team
This sounds like an easy choice in Agile development, however, single-functional team such as testing team is still prevalent in many organizations. There are forces favoring in it. By understanding the factors and dynamics behind different choices, we make more informed decisions.
Efficiency & Quality vs. Cycle time
Why do we want to have single-functional team? The answer is often with efficiency and quality, as shown in B1-loop and B2-loop.
Why do we want to have cross-functional team? The answer is often with cycle time, which further relates to speed and flexibility, as shown in B3-loop.
B1-loop: Functional specialization for efficiency
When there is efficiency gap, we reduce team's functional scope and develop more functional skill, thus, increase the efficiency so that the efficiency gap is filled.
B2-loop: Functional specialization for quality
When there is quality gap, we reduce team's functional scope and develop more functional skill, thus, increase the quality so that the quality gap is filled.
B3-loop: Cross-functionality for speed
When there is time pressure, we expand team's functional scope and decrease the number of teams to coordinate, thus, shorten the cycle time, so that the time pressure is released.
Only seeing this, team's functional scope becomes a tradeoff between efficiency & quality and speed.
The efficiency and quality comes from the functional skill, how do we develop our functional skill? Traditional thinking is that we achieve functional proficiency by focusing on the narrow functional scope. There is some truth, but does not provide the complete picture. Learning comes from the feedback and the collaboration with other functions too.
R1-loop: Reduced learning leads to less efficiency
As we reduce team's functional scope for more efficiency in B1-loop, the functional silo gets stronger and the feedback speed gets slower, which reduces learning. It eventually decreases functional skill and makes it less efficient. Together with B1-loop, they form the "fixes that backfire" archetype.
R2-loop: Reduced learning leads to lower quality
The dynamic on quality is similar to the one on efficiency. We reduce team's functional scope for higher quality, but the reduced learning eventually leads to lower quality. B2-loop and R2-loop form the "fixes that backfire" archetype too.
This adds more advantage on cross-functional team, as it both provides broader context and speeds up the feedback to support learning. However, this means to abandon the traditional waterfall development practices, but to adopt Agile engineering practices especially specification by example to make the cross-functional team collaborate in a truly different way.
Functional team tries to optimize in its own scope, which often leads to sub-optimization.
B4/B5-loop: Increase WIP for cost saving
Driven by the cascaded goal on cost saving, functional team increases WIP in its function. This achieves more efficiency, which leads to lower cost in its function, then, lower overall cost. One such common action is that testing team would accumulate many requirements to test altogether, as this is the most cost efficient way from their perspective.
R3-loop: High WIP increases cost of delay
As WIP gets higher, the cycle time gets longer. This increases cost of delay, which adds up to overall cost. The cost of delay includes both for the development (e.g. increased cost on rework due to delayed feedback from testing) and for the product (e.g. decreased customer value due to delayed releasing to market). B5-loop and R3-loop form the "fixes that backfire" archetype.
As team's functional scope gets bigger, it is more likely to make global optimization.
In the short term, this choice is about the tradeoff between efficiency & quality and speed. However, learning also benefits from the feedback speed and cross-functional collaboration associated with cross-functional team. Therefore, in the long term, cross-functional team could lead to high efficiency and quality as well. Moreover, we shall be cautious of the sub-optimization often made by single-functional team, while it is more likely for cross-functional team to make global optimization.
Revisit feature team - cont'd
Two years ago, I wrote a blog article called "Revisit feature team". I felt not quite complete, thus, the thought went on, until I discovered what was missing recently.
Let me recap the scenario here. There is one so-called feature team, in which small groups work on different features. The team is stable, while those small groups are dynamic, as shown in the below picture.
Within those small groups, they take collective ownership for delivering the feature. However, as the big team, they do not take collective ownership for all features. Therefore, it is not a real team. To make it a real team, it must take the whole-team approach, meaning that the whole team takes shared responsibility to deliver all features, as shown in the below picture.
What does the whole-team approach mean in practice? How is it different from the above scenario?
Resilience and Overhead
Let's understand more about the whole-team approach from Scrum.
Think about a team with 5 features to deliver in one sprint. A good team does not work on all features in parallel, but they may still work on a couple of features in parallel, as shown in the above picture. Are A1/A2/A3 and A4/A5/A6 also small dynamic groups in the team? Yes and no.
Yes in the sense that A1/A2/A3 working on feature 1 collaborate more closely and learn more details on that feature. They are more strongly connected on those days, during which they are working on the same feature.
No in the sense that the whole team learns about all features in the backlog refinement and planning, and every member inspects the progress in the daily scrum and is ready to jump in.
On one hand, we want to create resilience, so as to take advantage of the whole team's skill and capacity to deliver high-priority features. On the other hand, we want to have reasonable amount of overhead, as everybody in the team would spend effort in learning a bit more than what he/she absolutely and immediately needs.
B1-loop: Increase the team size for more resilience
The bigger team, the more people who could swarm, the more resilient we are as a team.
B2-loop: Decrease the team size for less overhead
The bigger team, the more people who prepare themselves to swarm, the more overhead there is, till the point where we could not afford any more.
It is the team size that balances these two factors. In my experience, the sweet spot for team size is usually 5-7 people. A team of 3 people does not create sufficient resilience, while a team of 10 people brings too much overhead.
What are alternatives than what is in the original scenario - one big feature team, in which there are small dynamic groups on various features?
1. Split the big feature team into 2 small feature teams, as shown in the below picture.
This alternative was suggested in my previous blog article. This is straightforward.
2. Keep one big feature team, in which there are small dynamic groups on various feature sets, as shown in the below picture.
This differs from what is in the original scenario, in that the dynamic group is on feature set, rather than on one feature. This creates more balance between resilience and overhead. The collective ownership happens in those medium-sized feature groups, while the stability is kept in the big feature team.
It is indeed more complicated than the first alternative, then does it bring in any advantage? It avoids to force splitting the related work into two teams. It is more cohesive for one group to take all related work. This is essentially the same argument as whether it is good for timebox to force splitting the related work into two sprints.
Seeing the system dynamic: narrow vs. broad product definition - part 2
In part 1, we looked at the case of platform as product. Now, we are going to look at the case of product area as product. Those products all have customer views, but there is possibility to define a broad product, then the products become product areas in the broad product. Let's separate them further into two cases, one is defining product solution as product; the other is defining product family as products.
Product solution as Product
The product solution includes several products that interact to create customer value. Let's take a couple of examples. In telecom, RAN (Radio Access Network) is a solution, while BTS (Base Transceiver Station) and RNC (Radio Network Controller) are separate products - network elements inside the network solution. In e-commerce, the e-commerce platform provides the end-to-end solution for customer, while shopping, payment, logistics are separate products - elements inside the solution. Usually, the product solution evolves to an open ecosystem. We could redefine product solution as product, then those products in the same product solution become product areas.
1. Productization, synchronization and flexibility
Even though the relation among products in the product solution is different from the relation between application product and platform product in part 1, the below dynamic is similar.
The productization is a key drive for narrow product definition, which is illustrated by B1-loop. The support on productization includes marketing, sales, budget, etc. Once there is gap, we define them as separate products under the same product solution. This increases the product orientation, leading to better support on productization, thus closing the gap.
To deliver the value at the level of product solution, those parts still need to be in sync. The separation of products decreases the extent of synchronization, thus, extends the cycle time. The longer cycle time raises the time pressure, which acts as a force against the separation and narrow product definition. This is illustrated by B2-loop.
The separation also creates silo effect among narrow products, which reduces the overall flexibility. When there is more valuable work in one product, it is hard to move teams from other products to this product. When the whole product solution is still full of uncertainty and the size of the organization is still small, the expected flexibility is high. Thus, it creates a force against the separation and narrow product. This is illustrated by B3-loop.
Similar to turning a platform to a real product, the separation of products in the product solution is better to emerge than to plan upfront. The premature separation creates more problems than what it solves.
2. Local innovation and holistic innovation
There is another tradeoff between local innovation and holistic innovation. Local innovation means the innovation within each narrow product, while holistic innovation means the innovation at the level of product solution.
Narrow product definition helps close the gap on local innovation, which is illustrated by B4-loop. This acts as a drive for narrow product definition. However, the product separation creates the silo effect, which harms the collaboration, then reduces holistic innovation. When a gap is perceived, we define broad product to reduce silo effect and increase collaboration, holistic innovation goes up, which closes the gap. This is illustrated by B5-loop, which acts as a force against narrow product.
Organization may choose a different balancing loop to address the lack of holistic innovation. Instead of defining broad product, they create cross-product task forces to increase the collaboration, thus, promote holistic innovation. This is illustrated by B6-loop. In theory, this is a good idea. However, in practice, it is a challenge to implement the outcome from those task forces into those separate products. Defining broad product and having task forces could be complementary too.
Product family as Product
The product family includes several products targeted for the same market but different customer segments, e.g. some for high-end, the other for low-end. Usually they share a large portion of code base too. We could redefine product family as product, then those products in the same product family become product areas.
1. Attention, competition and confusion
We first look at the dynamic regarding business and customers. Attention on customers increases customer satisfaction, while confusion by customers decreases it. The competition means that products in the same product family compete for business and customers.
One drive to define narrow product in product family is to serve their customers better. The narrower the product is, the more attention those customers get. This increases customer satisfaction and relieves customer pressure. This is illustrated by B7-loop.
When each product in the same product family goes on their own, the alignment drops. The competition among products increases, till the point of having alignment gap, which triggers to redefine a broad product. The broad product definition increases the alignment then closes the gap. This is illustrated by B8-loop, which acts as a force against narrow product definition.
What's interesting is when alignment is lower, the confusion by customers increases as they may use multiple products in the same product family and get different even conflicting marketing messages. The confusion decreases customer satisfaction. This unintended consequence is illustrated by R1-loop. B7-loop and R1-loop form the "fixes that backfire" archetype.
2. Duplication and common components
Let's look at the dynamic regarding development. The duplication has negative impact on development cost, while common components help lower the cost.
When each product in the same product family goes on their own, the transparency across them becomes lower, which makes fewer common components, leading to more duplication. The duplication increases the development cost, then raises the cost pressure. In response to it, one solution is to define product family as the broad product, thus, all previous products become product areas under one product. This increases the transparency, which enables more common components, leading to less duplication. This decreases the development cost, then relieves the cost pressure. This is illustrated by B9-loop, which acts as a force against narrow product definition.
There is another common solution in response to the duplication. We create organizations around potential common components, which drive their usage to make them become real common components, leading to less duplication. This decreases the development cost, then relieves the cost pressure. This is illustrated by B10-loop. As you probably have noticed, this is essentially the case of platform as product - the platform is a component, which has been described in part 1.
B9-loop and B10-loop are two different ways of creating common components, one is to enable it via transparency; the other is to define it. In my experience, it usually works better to emerge than define upfront.
Narrow vs. broad product definition is a big topic and the contextual difference is massive. These two articles (part 1 and part 2) are far from comprehensive. I summarize the major tradeoffs and pitfalls here.
- Productization is a key drive for narrow product definition. As the right narrow product emerges, we should avoid premature separation.
- Cycle time and flexibility are main forces against narrow product definition. This applies for both real product and platform/component.
- Common components and reusable platforms help reduce the development cost, but they are not necessarily defined as product associated with development organization.
- Narrow product definition may promote local innovation at the expense of holistic innovation.
P.S. While writing these two articles, I gained much insight and clarity from the discussion with Jurgen De Smet, thank you!
Seeing the system dynamic: narrow vs. broad product definition - part 1
What is the product? This is a critical question in organization design. You define the product narrowly or broadly, and the scope of the product is a continuum. We are going to see the factors and dynamics behind different choices in two parts. In part 1, we shall look at the case of platform as product; while in part 2, we shall look at the case of product area as product.
Platform is a popular concept in many product organization. It is often defined as product associated with organization - product backlog and teams. In most cases those are essentially components, as they are not facing external customers. They form one product together with the application. This is illustrated by the left part in the above picture. In some cases those are indeed products, as they have separate external customers than the application. There are two products with different customers. This is illustrated by the right part in the above picture. Let's look at them separately.
Platform is a component
Why does organization want to define platform as product, even though it is essentially a component? For reuse - multiple applications would reuse the same platform, so as to save the development cost. This is illustrated by balancing loop B1. The goal is the cost budget. The action is to create narrow product (i.e. platform) to promote the reuse. The rationale is that platform increases the extent of reuse, thus development cost is reduced, then cost pressure is relieved.
Why does organization NOT want to define platform as product? There is another balancing loop B2 involved. As smaller platforms are defined, more platforms are involved in delivering value to customer. The extent of synchronization gets lower, thus, cycle time gets longer. This creates time pressure, which drives against defining more platforms as products. It is a matter of which balancing loop dominates at certain period.
What's more interesting is that the asynchrony causes the waste of waiting, thus, increases the development cost. That forms a reinforcing loop R1. B1-loop and R1-loop together create "fixes that backfire". While B1 dominates, R1 is in vicious cycle, thus harms the goal of meeting cost budget. While B2 dominates, R1 is in virtuous cycle in helping meet the cost budget too. This dynamic is shown in the below diagram.
Back to reuse, what are alternatives that could still increase the extent of reuse while not defining platform as product? Internal open source is one alternative approach. The most challenge in adopting this approach is its organic nature, which can not be controlled but only be nurtured.
Platform is a product
There is a different tradeoff involved when the platform is indeed a product, facing external customers, besides internal applications.
In this case, the main drive is not the development cost, but the focus and support necessary to bring a product into the market. B3-loop illustrates this. The support on productization includes marketing, sales, budget, etc. Once there is gap, we define platform as separate product than the application product. This increases the product orientation, leading to better support on productization, thus closing the gap.
Meanwhile, this has an impact on application product. As platform goes on its own, the request from application may not be done in synchronous manner. Thus, the cycle time gets longer, which increases time pressure. This is the previous B2-loop, which creates a balancing force against defining more platforms as products.
In reality, platform product emerges much more than being correctly predefined. I have seen that many platforms never became real product. Those that did become real product were seldom predefined. Same as reuse, the platform product is better nurtured than controlled. When done prematurely, it sacrifices the application product, meanwhile does not gain in making successful platform product either.
In part 2, we shall look at the choice of defining as a narrow product vs. as a product area in the broader product.
Seeing the system dynamic: requirement vs. task
One important leverage in coaching Agile teams is to increase the focus on requirement, rather than task. This article describes the dynamic behind it.
Traditional project tracks the progress at two levels. One level is the milestone, which is often associated with stages such as requirement analyzed, ready for integration, testing done, etc. The other level is the task status often through weekly report meeting. In contrast, Agile development tracks the progress in requirements (note: better to track the value of those requirements, but out of this article's scope). We shall see the dynamic behind different choices, and this understanding helps us make successful change.
There is a reason to focus on tasks.
Task focus essentially represents resource focus. When facing cost pressure, we try to increase resource focus, then resource efficiency, so as to reduce cost pressure.
How do we increase resource focus? One way is through tasks. In fact, when tracking tasks, the sequence is often person by person, asking what tasks each person is doing. This makes sure that every person is busy. What if there is no suitable task matching their skills? We create tasks to accommodate their skills. This has intriguing impact as we shall see later.
There is a reason to focus on requirements too.
Requirement focus represents customer focus. When facing market pressure, we try to increase customer focus, then flow efficiency, deliver more value, so as to reduce market pressure.
How do we increase flow efficiency? One way is through requirements. Instead of tracking tasks and persons, we track requirements and make sure that they are flowing. The focus is less on who's idle and more on how requirements could flow smoother.
With two separate balancing loops, both goals regarding cost and market could be achieved. However, there is the tension between resource efficiency and flow efficiency.
As we mentioned for resource efficiency, when there is no suitable task for some people in one requirement, we start another requirement with tasks matching their skills for resource efficiency. Please note that it is not resource efficient if it involves learning. Therefore, resource focus has negative impact on customer focus.
It works vice versa. When we focus on customer and pursue flow efficiency by limiting the number of requirements working in parallel, it inevitably creates the situation where some people will have less suitable tasks to do, which is not resource efficient. Therefore, customer focus has negative impact on resource focus.
Now, two balancing loops interact. When market pressure gets higher, customer focus increases, and so does flow efficiency. Meanwhile, resource focus decreases, and so does resource efficiency. Thus, B2-loop dominates. When cost pressure gets higher, resource focus increases, so does resource efficiency. Meanwhile, customer focus decreases, and so does flow efficiency. Thus, B1-loop dominates.
Understanding this tension helps see the resistance in a different way. Even though the customer focus is hard to refute, the underlying systemic structure creates the force against it.
The tension also raises an important question about system goal. For your specific organization, which goal do you optimize - resource efficiency or flow efficiency?
Is it possible to achieve both, or take one as primary and the other as secondary but still considered?
Look at how we achieve resource efficiency. We start more work in progress by accommodating the skill at the expense of customer focus. Instead of B1-loop, we could initiate the B3-loop, which expands the skill breadth via learning, and eventually increases resource efficiency. B3-loop does not have negative impact on customer focus, however, learning also takes time. Not surprisingly, the real leverage lies at how effective we could learn and expand skills.
The above is the efficiency matrix from the book "This is Lean". The blue line shows the evolution path towards "The perfect state", first achieving B1-loop (flow efficiency) then B3-loop (resource efficiency). However, many organization perceives their starting point as "Efficient islands", in which B2-loop dominates, thus the evolution path becomes the red line. The red line is hard from change management perspective, as it means the drop in resource efficiency firstly. You either change the perception to start from "Wasteland" as it often actually is, or make sure that the drop in resource efficiency is manageable.
The choice of focus on requirement vs. task is essentially the choice between customer focus and resource focus.