Shu-Ha-Ri: Can't we customize?

Let's have a short discussion on Shu-Ha-Ri and how it should affect your learning journey.
Many people feel that "This (or that) constraint isn't right, can't we remove it or try a different approach?"
Some common examples may be: "Why can't we have flexible sprint length?" - "Can't we do that step without a WIP limit?" - or even: "We need more Product Owners!"


Let's explore this matter briefly.

In the basic learner phase (Shu), every approach is rigorous and inflexible - that't the entire point of learning the basics: The constraints serve to protect.

In the advanced learner phase (Ha), the rigour no longer feels like a constraint as you already start to understand why it helps you and you've found ways to harness your potential within those constraints.

In the transcendence phase (Ri), the rigour becomes irrelevant, as you know how to achieve the ends with other means. For that, you must understand these means and the purpose they serve. Now, in the Ri phase, you may even be more rigorous than before - albeit in a different way, that may no longer have anything to do with the original form.


But ...
If you are wondering like "I think Karate hurts my muscles too much. Is Taekwondo better?" I can clearly answer that with: You'll have the same and other problems.

Refrain from the knee-jerk reaction of looking for a different "way out" and consider what you're doing wrong. Also, refrain from considering yourself in the Ri phase - if you were, you wouldn't have so many problems.

For example, a Ri practitioner may feel that Sprints are too slow - they prefer to deliver daily. Or, they don't understand the point of defining WIP limits as theirs is 1. Or, they don't even see the need to have a Product Owner at all.

They can do all those things, but they don't need to do them, because they can achieve the purpose of these practices without any effort.

If you're not there yet, you are Shu.

Changing priorities - what to do?

"A team mentioned the following: We are unable to focus on the work, resources are being borrowed mid flight, we have to wait for env to be ready for testing/deployment , priorities keep changing and worst of all ; often we hear <Our resources should give their 100%>, now how the hell can we give 100% with these constraints?"

Those are six different problems mentioned there. Let's address them one by one.

#1 - Unable to focus

The more things you do, the less you can focus. It's easy to focus on one thing, yet impossible to focus on a dozen things at the same time. We lose focus when we lack clarity of what matters - and what doesn't.

Likely Causes:

• Lack of transparency concerning value
• Lack of clarity on the impact of multitasking on outcome

Possible Solution:
Create an environment where limited WIP is possible, encouraged and enforced. (it's always possible, the rest is management mindset)

#2 - Borrowing mid-flight

This only occurs when there is confusion in the organization on what is actually important - and why.
It doesn't even make sense to divert people from doing the most important thing they can do.
Again, that's a management mindset problem.

Likely Causes:

• Confusion around priorities
• Managers who are unaware of the disruptive impact of their behaviours. Closely linked to #1.

Solution:
Create a stable environment where only ONE priority 1 exists at a time.

#3 - Waiting for environments

Consider the "Developer's bill of rights" - if your organization isn't willing to invest into the best possible technology, you lost the game anyway.

Likely causes:

• Managers who forget the opportunity cost of saving a few measly bucks on tech. 

Possible Solution:
It's essential that technology is an enabler for developers, not an impediment. A company that doesn't let their developers maximize the value of their time is paying high-cost talented people for twiddling their thumbs and getting frustrated instead of delivering results.
Developers must create a plan how they would solve this and what they need, then management must grant both the procedural and financial way to move forward.

#4 - Priorities keep changing

It's very, very simple for managers to change priorities - yet very hard to get things "Done" when the priority is different before something is. 

Likely causes:

• This is the same as #1 and #2. 
• Manaers who are unaware of the cost of change.

Possible Solution:

Make the cost of change visible. Enforce a strict policy that any change to work which is currently in progress requires the requester to sign off the investments up to this point as "burnt money". For example, if you sunk 20 dev days into a feature already and priorities change, the requester of the new priority causes a loss of 20x10 dev-days, e.g., $20k to the organization. Ask them if that's what they want.

Accumulate burnt costs, when they approach hundreds of thousands (which they quickly do) ask if it wouldn't be better to hire more people.

#5 - Demand without enablement

There's a memorable quote, not sure I get it verbatim: "There's nothing more cruel than setting a goal without providing the means" - yet this is exactly what's described here.

Likely causes:

• Organizational structure
• Separation of accountability and responsibility
• Separation of Planning and Executing
• Management philosophy

Possible Solution:

This is a tough nut to crack and will definitely take a long time. It requires management to reconsider everything they are doing. At a minimum, managers must move from controllers to enablers - even this step can take years to be fully anchored.

#6 - De-humanization of workers as "resources"

That's entirely a mindset issue occurring in organizations where people aren't being treated as people.

Lean thinking is built on "respect for people". "Resource" in regards to people is a very dis-respectful concept that needs to be banished out of the organization, without any form of replacement. That alone will have a positive effect on motivation, morale and therefore, ability to get things done.

Summary

The good news: Those aren't many problems. They are all somehow different faces of the same coin. There is only one problem: a communication gap between managers and developers. Everything else is a consequence thereof.

At the heart of it, managers need to stop "doing manager stuff" and start talking with their people. Try to get NEAR.

A good coach can help here.

The 4 drivers of a holarchy

Concluding the introduction to the basis of a holarchy, let us explore briefly what drives a holarchy:

The 4 drivers of a holarchy

1 - Interaction

Interact with those around you. Build relationships.
It's not enough to interact once. You must continuously interact and communicate.

2 - Inspiration

Give others reasons to want to do what you do - or even more.
Likewise, let yourself be inspired by others.

3 - Participation

It depends on you. If you don't participate in what needs to be done, nothing will change.
Participation is not an individual matter. Align with those who pursue the same goal.

4 - Growth

You're not perfect. Make experiences, learn from others. Seek enlightenment.
Grow as a person and help those around you grow as well.

Act!

You must constantly work on all these drivers. They depend on nobody except yourself. Maybe you will be the person with the most drive in your holon, maybe not - that's not important. Important is that you drive.

10 Principles of a holarchy

How can you make a holarchy happen? First, you need to establish the values of a holarchy to create a foundation, then you must establish the principles to make it "tick". Here are the principles of a functioning holarchy:

The 10 Principles of a holarchy

1 - Care

Care for True North. Care for what you do. Care for people around you.

2 - Leadership

Everyone leads in anything: what they do, how they think and what they believe. Servant leaders never stop to serve, enable or inspire others.

3 - Engagement

Participate. Contribute where you can. Engage others. Take responsibility.

4 - Decentral

Every holon is autonomous. There are no directed dependencies. There is no "HQ".

5 - Informal

Everything is subject to the current need. There is no prescribed form for anything.

6 - Practical

Do what works, don't what doesn't. What works in your holon may not work in another.

7 - Respect

Everyone has something to contribute. You may need to discover what that is.

8 - Non-judgmental

Just because you disagree doesn't mean they are wrong.

9 - Openness

Everybody's perspective is limited. You grow by seeing through other's eyes.

10 - Voluntary

Everything you do is your choice. Nobody must agree to anything.

Conclusion

These principles are not open to customization or "adjustment for pragmatic purposes". If a single principle of holarchy is broken, the entire structure is threatened. Holarchies are fragile and require continuous attention.

Establishing these principles takes years. There will be a lot of setbacks. Failure, getting up and improving are the normal. Regardless of what you see or what happens - never abandon these principles and do your best to keep them.

The 8 core values of a holarchy

In a recent post, I introduced the holarchy as an alternative organizational structure.
Let's look at the core values required to build and sustain a holarchy:

8 Core Values of a holarchy

A holarchy requires shared values. They need to be applied and maintaned without compromize, both on an individual and a corporate level.
If you do not share these values, your holarchy is already set out to fail:

1 - Clarity

First, you need a "true north".
This true north is a transparent, shared set of beliefs and a compelling vision. Everyone must be clear and aligned on the vision and these beliefs. As the vision grows out of sight just by time passing by and life taking it's course, you must continuously invest time on recalibrating yourself.
Shared beliefs need to be clearly articulated and should be as free from ambiguity as possible.

Constantly communicating these beliefs and the vision in clear and simple terms is essential to keep the holarchy going.

2 - Humility

Nobody is better than anyone else, we all are where we are. We do have different responsibilities and different perception, but that doesn't mean mine is more or less valuable than yours.
We all always lack some piece of the puzzle - and we're seeking out more pieces instead of insisting that we got it right. Be willing to be corrected at any time, by anyone, through anything.

3 - Scrutiny

Everything is up to scrutiny. Everyone should be free and willing to say "I could be wrong", or even "We could be wrong" at any time. Nothing and nobody is exempt from being questioned, by nobody, at no point in time.
That doesn't mean we need to have all the answers: It can be that we simply don't know. New information or evidence may imply that our past understanding is no longer adequate or appropriate. When this happens, we must be swift and willing to update ourselves.

4 - Purity

A holarchy relies on following the vision without compromize and being consistent in what you do.
Scrutiny should expose inconsistency, and purity means that you consequently deal with inconsistencies by resolving them to the best of your ability.
True North guides the measurement of the direction you should take. Deviation from True North is an inconsistency that you need to deal with.

5 - Equality

"Rank has its privileges" - and that creates problems. Therefore, there are no ranks and no privileges. Discrimination of people based on any factor beside their actions creates inconsistency and must be subjected to scrutiny.
Roles are transient and subject to need and may change at any time. There are only functions and responsibilities. Not even "leadership" is a role - it is something you either do or don't. It is not a label attached to a person.

6 - Unity

Seek harmony with all those who are willing to move towards your goals, regardless of who, where or when. The rules and practices of the holarchy should be inclusive, yet without compromizing on the vision.
Tolerate no form of division, not even with those who are just at peripheral touchpoints, such as customers, relatives, or friends. Divisions create inconsistency, and inconsistency breaks the holarchy.

7 - Sincerity

Take a stand. Act on what you believe is right. Do what you mean and mean what you do. At the same time, be willing to be adjusted by those around you. You can't refer to "the system" or "the situation" as a reason for doing something you don't believe in, as both are shaped by your own influence.

8- Responsibility

Responsibility can only be taken, not given. If you don't take it, nobody might. You yourself are responsible, so do something. You have no excuse to point at anyone for saying "They should have ..." or "But they didn't ..." , but you do have the right to lead the change by yourself.

Conclusion

Nobody said Holarchy is easy. These core values are essential, yet incredibly difficult to maintain. and even more difficult to establish in the first place. They are the "magnet field" for your moral compass.

You can't just transform an existing system into a functioning holarchy without first defining "True North". Not everyone will join you in your pursuit of a holarchy, and many will find it too challenging to continue on this pursuit in the long term. A holarchy must be willing and able to continue towards their goals, even if their former leaders forsake these values course and it must be ready to leave those behind who choose to become impediments towards making these values happen. A holarchy can only persist with the people who are willing to share these values. Finding the right people is the first problem you need to solve.

Significant change is required to get a holarchy to work. For those who are not willing to work on themselves to live out these values, participating in a holarchy will remain a dream - insubstantial and intangible.

Product Owner: From business or from tech?

There's a never-ending debate: Should a PO be chosen from the business side - or from the technical side? Let's look into this question.

What's a Product Owner?

In short, the Product Owner is the person who is key to the product's success. They decide what is being built - and with that, they decide how the money is spent. The PO is responsible for setting the team's priority, thereby deciding how the product generates value.

This begs the question: What does any of this have to do with their position in the Org Chart?

Advantages of a business PO

The PO from a business background often tends to be closer to real users of the product, i.e., they might have a better understanding how the product contributes to the company's success. Also, due to their background, they might have a communication advantage when talking with non-technical people. This advantage can become even greater if they have already established a network with real users.

Advantages of a technical PO

The PO with a technical background might have a more sound judgment on the development cost of features. They may be better at asking the right questions which open technical alternatives to minimize the effort for meeting customer needs. Likewise, they are able to correct misunderstandings faster if developers and customer have different intentions.

What neither may bring

As mentioned above, the PO is about maximizing the value of the product. This requires a deep understanding of concepts like "value", "ROI", "cost of delay", "opportunity cost", "investment", "customer satisfaction", "growth potential", "priority" and "sustainability". 

On top of that, there are soft skills like dealing with conflicting interests, making tough choices and others. The PO requires more grit than anyone else on the team.

It doesn't matter as much what the PO did in the past - if they aren't good at the items mentioned in this section, you have the wrong PO. If they can do these things in the organization's best interests, the rest can be remedied over time.

Summary

The past of a PO, i.e. their background, doesn't matter all that much. What matters is: Does your PO have the right understanding, mindset and skillset to do their current job?

If the PO doesn't have these, they need some basic training and good coaching. That should help. Otherwise, find someone who can bring thse. Technical, business - doesn't matter.

Q&A: Our Customer says that our software is buggy?

Question: "When a stakeholder says to the Scrum team that our application has a lot bugs although the team has a good test coverage, what could be the team's take on that?" (source)

Dear Saad,

that's a good question.

The simple answer: Tests do not guarantee high quality software. 

Many Scrum teams feel that when their DoD is met and the Product Owner has accepted their Product Increment, they are "good to go". 

They might justify their behaviour based on whatever was agreed between them and the Product Owner. That might be quite revealing if the PO is the person who claims there are bugs. That would make a great team alignment&trust topic to discuss in a Retrospective. The key question here would be: "What does justification help - does it help us earn money?"

When another stakeholder (e.g, prospective customers) evaluate the team's success, this statement reveals that team has missed something important somewhere along the line. It might be in their approach, in their DoD - or in their understanding of stakeholder needs. 

We could now get into an argument of "defect" vs. "bug" vs. "feature", but that doesn't even make sense, because we'd still have the problem of a dissatisfied customer that we want to resolve.

How should you deal with that stakeholder?

Ask them to clarify what they mean with "a lot of bugs". Let them show you examples. Pay close attention. Learn how they use the product and what is important to them. Be open-minded.There's a good chance you made past assumptions that can't be held up any more. Try to discover what you can do different in the future. 

While we can never rule out the possibility of an insane stakeholder, they are rare. Most stakeholders want a good product, although their understanding of "good" may differ from yours.

Here are some items you may need to consider:

From technical perspective:

First, you could have written the tests "around" the defective areas - and second,  there's this difference between "works as designed" and "works as intended".

From customer perspective:

When you walk into a fastfood shop and get a Chicken Burger with a glove in it, you don't care how many hygiene checks ("tests") the company has - you care for what you experienced.

Keep in mind the Agile Principle #1 "Our highest priority is to satisfy the customer through early and continuous delivery of valuable software".

This leads to two questions:

1. Why all of a sudden "a lot of bugs"? Wasn't that stakeholder involved frequently?

2. Has the team aligned their definition of value and quality with the stakeholder?

I leave you with are a few extra questions:

1. Do you have good tests? 
2. Is your test approach adequate?
3. What is your defect strategy?
4. What's your approach to communication debt?

There are answers, but you need to find them by yourself.

All the best,

Michael