Scrum: Optimizing Goals
Introduction
Each Agile framework is tailored to optimize the organization in some specific way. When a company decides to adopt one of these frameworks, it should clearly understand what sort of organizational optimization this framework will foster. If this is not the one needed for the company, this framework might wreak havoc instead of benefiting the business.
In this article, we will try to identify the Optimizing Goals of Scrum and of those Scrum-scaling frameworks, which are entirely in line with Scrum.
What are the Optimizing Goals, and why needed?
Optimizing Goals of an Agile Framework reflect the intended state of some key organizational characteristics that this framework enables when it is appropriately adopted.
Optimizing Goals of an Organization reflect the intended state of some key organizational characteristics that the company targets to ensure its capability to achieve its business goals.
Some examples of possible Optimizing Goals, which may be “good” for one organization and “bad” for another one:
- a high number of features delivered over a specified time period;
- short time-to-market;
- fast learning and gaining new skills
- strict fulfillment of requirements
- high adaptiveness to changing requirements
Case #1. No Goals
An organization does not have any understanding of its Optimizing Goals. In this case, risks of the adoption of any Agile framework are comparable to those when playing the Russian Roulette or randomly taking a medication when you’re sick and hope you will get better.
Case #2. No Correlation
An organization has clear Optimizing Goals. However, the Optimizing goals of the organization and the framework do not fit each other. In this case, this is a direct way to either huge losses or a complete disaster.
Case #3. Full Correlation
An organization has clear Optimizing Goals that have a snug fit with those of the framework. When the framework adopted adequately, the organization has considerable changes to achieve its Optimizing Goals.
Only the snug fit between the optimizing goals of the organization and framework, and only when the framework is adequately adopted, increases chances to succeed in the achievement of the Optimizing Goals of the organization. Here, we need to recall that accomplishing the Optimizing Goals of the organization does not necessarily mean the achievement of its business goals.
The organization must choose those Optimizing Goals, which achievement creates the necessary capability to achieve the business goals. Otherwise, the same outcome can be expected, as in Case #1 above.
As soon as the framework adoption and respective organizational optimization are usually quite time-consuming, it makes sense to consider some long-term business goals here.
The organization can significantly increase its chances to achieve its business goals through the adoption of an Agile framework, if:
- The organization has clear and right Optimizing Goals — their achievement enables its capability to achieve its business goals.
- The framework and the organization have correlated Optimizing Goals;
- Framework adoption is done appropriately.
Complex Domain
According to the definition of Scrum:
Scrum (n): A framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value.
Complex adaptive problems pertain to the Complex Domain described in the Cynefin Framework.
There’s enough useful information about all domains, so we will not repeat the definition and explanation of all of them here. Let’s recall what the Complex Domain is:
In the Complex Domain, the cause-effect relations are possible to identify only retrospectively.
Innovative Product Development
Let’s call the Innovative Product Development those cases in which Scrum is intended to be most helpful.
Most innovative products offer some functional innovations — some new ways of addressing the needs of customers. As soon as customers are people, success in Innovative Product Development mostly depends on the subjective opinion of people. In this case, we cannot be sure what changes to the product will most likely lead to customer satisfaction before we deliver the product to the customer.
Even customers can not guarantee their satisfaction with the innovative product implemented precisely according to their requirements unless they try the product.
Some Innovative Products may have no functional innovation or even no functional change at all — this may happen when products are innovative from a technical perspective. Even when a complex technical innovation of the non-functional side of the product has no impact on the needs of end-users, it impacts the business in the form of reduced maintenance costs, compliance with technical regulations, etc…
Innovative Product Development — when either of the following applies:
a) Some new functionality is actively developed, not just solely some maintenance with bug-fixing;
b) Some complex technical innovation happens, even if the functionality does not evolve at all.
Whatever the causes are — a complex technical innovation or dependency on customers’ satisfaction — the effect is going to be the same: many problems addressed in the Innovative Product Development have cause-effect relations that are possible to identify only retrospectively. And this is a definition of the Complex Domain.
Some activities in Innovative Product Development may be quite simple, repetitive, and deterministic. They can be associated with Complicated or Obvious (a.k.a. Simple) domains. Many other activities are connected to problems on the Complex Domain. To be more precise:
The dominating risk amount in Innovative Product Development comes from the Complex domain.
Experts
By “Experts,” we will mean those people who have enough experience, skills, and knowledge, to reduce the uncertainty.
Based on the definitions of the domains, we can conclude that experts exist in the Complicated domain only. In the Obvious domain, everyone is more or less an expert, so this term does not make sense there.
In turn, the Complex domain, by definition, does not allow anyone to make a high-probability prediction to reduce the uncertainty. It means that:
Nobody can effectively reduce uncertainty in the Complex Domain. Hence no experts exist in this domain. If one can do that — this is an Expert, and the problem is not the Complex domain anymore.
Usually, when there’s some uncertainty, it poses a risk, and it is reasonable to mitigate this risk by involving respective experts. As previously discussed, in some cases, Product Development teams face problems of the Complicated domain — this is where experts are present, and having them on the team (or at least receiving their advice) would be extremely helpful.
However, as we have just identified, in the Complex Domain, experts are absent by definition. Per our definition of the Innovative Product Development, the risk amount coming from problems pertaining to the Complex domain dominates over risks from the Complicated domain. It means that:
For the majority of risks in Innovative Product Development, no experts exist.
Risk in Complex Domain
As we found out earlier, the risk level in the Product Development (in the context that we gave above) is very high. It is a result of the vast uncertainty predominantly coming from the Complex domain, which lacks experts who could reduce this uncertainty.
In the Complex Domain, there’s a high probability that the decisions are far from optimal ones.
Traditional Project Management in Innovative Product Development
As a summary of what we discussed so far and what we know about traditional Project Management:
- The majority of the risk amount comes from the Complex Domain;
- In the Complex Domain, there are no experts.
- Traditional Project Management is heavily reliant on expert judgment.
Traditional Project Management is useless in dealing with the majority of the risk amount in Innovative Product Development.
Risk Management Strategy #1: Adaptiveness
A solution exists. As it is well-known, in the Complex Domain, it is recommended to use the iterative-incremental approach. Within each iteration, Inspection/Adaptation cycles happen to carry out “experiments” concerning both the product and the way of working. Then the results of experiments are analyzed, and respective adoption should happen. The more effective this approach, the higher the Adaptiveness.
Higher Adaptiveness allows to reduce Risk Severity — the shorter the “experiments,” higher quality of inspection (analysis of results of experiments) and more effective adaptation — the lower the cost of risk.
Risk Management Strategy #1 in the Complex Domain: to reduce Risk Severity, the organization should ensure its high-enough Adaptiveness.
So-called Agile Project Management (or Iterative Project Management) is an example of utilizing this Risk Management Strategy, though solely concerning the Adaptiveness of the Product, not the way of working.
This approach has higher chances of success in Product Development compared to traditional Project Management. Like many other approaches, the potential of this one is restricted by using only one of the two major Risk Management Strategies.
Risk Management Strategy #2: Total Engagement
In many cases, unfortunately, this risk management opportunity is misunderstood and undervalued. As discussed above, the main risk driver in the Complex domain is related to the quality of decisions.
Risk Management Strategy #1 addresses only the severity of consequences in case the quality of decisions is poor. Why not consider improving the quality of decisions to address both the risk severity and probability?
In the Complex Domain, as explained above, the critical problem is the lack of knowledge about cause-effect relations. However, if we could somehow get access to all the information about this world and had a complete picture of all cause-effect relations, then there would be no Complex Domain for us at all.
It is impossible, at least yet, although we can at least come closer to this effect. The more diverse and useful information we take as an input to decision-making, the higher our chances of increasing our decision-making quality. As a result, our decisions would stand a chance to be closer to the optimal ones.
All people have their own mental models. This is great, because:
In general, the more intrinsically motivated people having relevant knowledge and striving for a common goal are involved in decision-making necessary for this goal achievement, the higher the probability of making the decision closer to the optimal one.
As a highlight, we are talking here not about any people but precisely those who have relevant knowledge and simultaneously intrinsically high-enough motivated to help make the best possible decision.
Moreover, the involvement of many people in decision-making does not necessarily mean that they all must decide. These people should at least provide the necessary input to the decision-making process, try to influence the opinion of the decision-makers.
It allows us to increase the quality of our decisions if we have the Total Engagement of all who are highly motivated to achieve our goals.
„ We will win and you will lose. … We are aware that business has become terribly complex. Survival is very uncertain. Therefore, a company must have the constant commitment of the minds of all of its employees to survive. For us, management is the entire workforce’s intellectual commitment at the service of the company.
We know that the intelligence of a few technocrats — even very bright ones — has become totally inadequate to face these challenges. Only the intellects of all employees can permit a company to live with the ups and downs and the requirements of its new environment.“
— Konosuke Matsushita Founder of Panasonic
This saying is exactly about the concept that we will call “Total Engagement”.
Risk Management Strategy #2 in the Complex Domain: to reduce both the probability and severity of the risk, the organization should ensure the Total Engagement of its employees.
Moreover, the Total Engagement of Product Development team members has a great positive effect on the Adaptiveness of both the product and the way the team works. It means, that:
The Risk Management Strategy #2 increases the effectiveness of the Risk Management Strategy #1.
Agile Manifesto and Complex Domain
Only the implementation of both Risk Management Strategies may allow the organization to maximize the effectiveness of risk management, thus allowing it to survive and even thrive in the Complex Domain. Principles of the Agile Manifesto fully support these Risk Management strategies. On the image provided below, we mention only some of them.
Scrum and Complex Domain
Agile philosophy is in the core of Scrum. By adopting Scrum, organizations increase chances to implement both Risk Management Strategies.
The concept of the self-organizing teams enables the organization to create necessary conditions for Total Engagement. The entire process in Scrum allows the organization to develop high Adaptiveness.
It is essential to highlight that Scrum does not implement these Risk Management Strategies itself — its adoption only creates favorable conditions for doing so.
First of all, this is because Scrum is intentionally high-level and does not prescribe details of implementation, which are always unique depending on the context of the organization.
Additionally, Scrum does not say anything about the structure of the wider organization. However, exactly the organizational structure surrounding the Scrum Team usually has a massive effect on the success of Scrum adoption, and respectively on the implementation of these Risk Management Strategies.
Optimizing Goals of Scrum
Now we have a clear connection between the Complex Domain, its major Risk and Risk Management Strategies, Agile Manifesto, and Scrum.
Optimizing Goals of Scrum are intended to enable the successful implementation of both Risk Management Strategies in the Complex Domain.
Optimizing Goals of Scrum:
* Adaptiveness — with respect to the Product and Processes;
* Total Engagement — of all team members around the common goal to maximize the business value.
Conclusion
Whenever an organization wants to succeed in the Innovative Product Development, it makes sense to check if Scrum adoption can help.
Scrum is designed to provide the necessary processual, cultural, and mindset grounds based on which teams, developing innovative products, can build effective risk management, which is out of reach for traditional project management.
Companies going for Scrum should clearly understand that its adoption will have chances to enable their business to become a triumph story in the only case. Along with business goals, a clear optimizing goal should be pursued to achieve high adaptiveness and total engagement.
