Sparking joy with Agile – Are You Committed?

One day I got this quote

And I did not get it.

So, I had to find out who Marie Kondo is, and why is this so funny?

Marie Kondo is a tidying expert, bestselling author, star of Netflix’s hit show, “Tidying Up With Marie Kondo”. She has spent years tidying up homes. Starting with her home growing up and later on as a professional.
She has made many experiments to see what works for her, and along the way, discovered this is her calling.
You see, Marie loves mess. She does. And tidying up is her kick.

As a mother of 3, my house looks like a war zone. Stuff everywhere. So you might understand what brought me to explore more.
I realized that KonMari for tidying up in my personal life, is like Agile in my professional life.
Sparking joy in my home life = adding value in my professional life.

Let me share some insights with you.
The KonMari method has 6 basic rules.
(Of course there is a lot more to it when you come to practice it. Same as in Agile.)

These are the 6 rules of KonMari:

  1. Commit yourself to tidying up
  2. Imagine your ideal lifestyle
  3. Finish discarding first
  4. Tidy by category, not by location
  5. Follow the right order
  6. Ask yourself if it sparks joy

This time I would like to focus on the 1st rule – commitment

In her Netflix series, Kondo is invited to American households to coach them how to spark joy in their life by decluttering their homes.
Wendy and Ron Akiyama, provided one of the most dramatic ‘before-and-after’ episodes of the series by utilizing the KonMari method.
At the beginning of the episode, Ron is a no show. He may be there physically, but he is absent.
He arrives late to meetings, he just sits there. And he says “she decided…” familiar?
In order to understand the context, this is Wendy’s pile of clothes, but here is also Ron’s baseball cards collection, located in their bedroom.

Personal commitment, in my view, means you will be changing the way you do things. And you will need to step out of your comfort zone and do this for a while before it will get comfortable again. This takes hard work.

In the episode, Ron is sitting there… sorting his cards, for days. He falls asleep in the middle of his work. But he gets it done. Then he learns to appreciate the cards he chose to keep.

It is amazing to see how we have things that bother us, but we are reluctant to take action.
Action is driven by true commitment to make a change in our own behavior.
Take a moment to reflect, in your daily life, what are you committed to?
Where do you find yourself stepping out of your comfort zone for a clear purpose you would like to achieve?

There is a difference between personal commitment and organizational one.
How many times did you have people in your team saying “management decided to do [XYZ]”?
I heard – “Agile is for managers to have better control by planning detailed work into 2 week sprints, for the next 6 months.
Who Makes the commitment?
In many cases, the people that commit for an Agile transformation do it on behalf of the organization, but as a coach you need commitment from different people in different roles for an effective change.

On the Netflix show, it is not visible to the viewer who made the commitment, but it is clear that Wendy wants this more than Ron, and part of the process the couple goes through is realizing their mutual vision and committing to tidying up. I can only assume that part of their commitment was to invest a lot of time and effort in this process.

Organizational commitment, in my view, means that management needs to know what they are committing to and be willing to invest in it. When I start working with an organization, I do not intend to “fix the development” or “change people” . I strive to make the workplace a better place, for the people and for the products. In order to achieve that, we (the people of the organization and I) need to have the environment that supports that.
Same as personal commitment, the organizational commitment is about stepping out of the comfort zone and taking risks. Allowing people to make decisions in spite of knowing there will be some mistakes along the way.
Organizational price could be time and budget. For example, you will need to slow down before you speedup. Because learning takes time. Is your organization willing to afford that in the short term?

Additional price could be organizational changes. Since culture follows structure  (according to Larman’s laws of organizational behavior),
In some cases changing the organizational structure enables better flows in your system (aka the organization). This is a hard step for most organizations. That requires a lot of managerial courage before, during and after the change. Since we have people involved, it is a very delicate and complex network of interests that needs thoughtful management. Naturally, this translates into time and effort are required during the change to create an impact in the desired direction.

Although I differentiate between personal and organizational commitment, it’s important to understand that both are crucial to drive learning and improvement in organizations.

I invite you to reflect, are you and/or people in your organization committed to go act on taking your organization to the next level?

Next time I will elaborate on rule No. 2 – “Imagine your ideal lifestyle”, which I refer to as: Your vision.

Technical Debt – Will hit you 3 times

“Look, it’s critical that we meet our deadline, and I know that we are already running behind. So please, we need you to push faster no matter the costs. And I don’t care if you need to cut some corners on the way. I’m totally aware of the costs, we just need to meet the goals for the deadline and after that we will have more time, to go back and fix what’s needed”

Sounds familiar?

Funny enough this kind of conversation have been happening to me on many of the projects I’ve worked on, usually on several occasions. And to be frank, I totally understand where this is coming from, and I’m also aware there are times in the life of a product that this is exactly what needs to be done.

What I did find is that, even if stated otherwise, many seem to be quite unaware of the real costs involved in such a move. So let’s try clearing those up a little.

Technical Debt – Will hit you 3 times

The first time you get hit by technical debt relates to the subtle fact that organizations usually like the reckless speed a technical team can go at. Once the team stop doing many of the things that needs doing, suddenly, everything seems to be going much faster. And after a few weeks of showing an increased productivity, everyone starts believing that this what we should expect.

Wrong – what actually happens while we are working in such a way is that we are digging holes, and when you find yourself in a hole, first thing to do is to stop digging. That is, the first thing the team needs to do is get back to working the way it should and do everything that needs doing. Still, from the outside, the perception is that suddenly everything is slower. Even though we are just back to normal pace.

Try it next time you watch a talk on YouTube. Increase the speed to x2 for 30 seconds. Revert the speed to normal. It now feels that the speaker has some speech impediment. But the impediment is actually with the viewer, who needs to readjust to normal speed.

Technical Debt – will hit you 3 times

The second cost involved, is the one that many grasps as the only cost. The cost of going back and fixing what needs to be fixed. You took a loan by skipping out on a few things, you need to pay it back and do them, it’s as simple as that. If, for example, you didn’t write test automation for new code, you need to go back and write it.

Technical Debt – will hit you 3 times

And last, but not least, is the “interest” involved. Like any type of loan, a technical debt also incurs an “interest”. Yes, once you start cutting corners and compromising technical standards, more mistakes tend to creep in and over time the need for dealing/fixing those things will also take an extra cost. For example, let’s say, that for the sake of speed, a piece of logic was duplicated instead of properly refactored to a single shared place.  Now, every bug or change in that logic needs twice the effort to get done. Not to mention the chance that someone may forget to fix both places and now you get another new bug to deal with.

The Numbers

Ok – so 3 times, what’s the issue with that? It’s just going to cost me a little more, I probably won’t be able to notice it anyways.

Let’s try looking at some numbers. Let’s assume that for a period of 8 cycles (weeks, sprints, months or whatever) the team has decided to take a loan of 10 “units of work” which allows them to go 10% faster (again it can be days, hours whatever). And let’s take the number of 10% as our interest rate.

Side note – Some may argue that 10% interest number is too high a rate. Personally I think its quite a conservative number.

Here’s the table showing the loan performance over these 8 cycles:

Cycle 1 2 3 4 5 6 7 8
Total Debt . 11 23 36 51 67 85 104 126

Note – after just 8 cycles, the interest alone (46 units), is going to cost about half of the base loan amount (80 units – 10 units per cycle).

Ok now what? Now comes the hard part of deciding how to pay back this debt.

One strategy is to just stop everything and pay the debt. In our example, it will take about a cycle and a third. Since the overall capability is 100, in one cycle the debt will drop to 25, add the interest to that, and we need almost a third of the next cycle to pay the rest.

However, in most contexts, that’s not something an organization will do. Stopping everything is not an option and there’s a need to repay the loan gradually over time (like most other types of loans). The underlying logic usually goes like this: If we got a 10% increase in speed over these 8 cycles, let’s go 10% slower and after 8 cycles the debt will be paid.

Sadly, it’s not that simple. First, 10% slower from the current state just bring you back to normal pace (first hit). So actually, in you want to pay 10% of the debt, from the organization perspective, it will feel about 20% slower than current state. Second, since now the overall debt is 125, the interest alone (third hit) is more than the payment itself of 10 units.

Actually, in order to close the original debt (second hit) in about 8 cycles, you need to pay 20 units per cycle (30% slower from organizational perspective, compared to current speed) and then the debt left will look like this:

Cycle 1 2 3 4 5 6 7 8
Total Debt . 116 106 95 82 68 53 36 18

What does it all mean?

Not much. Mainly it means that taking a technical loan is a risky business, and it helps to be fully aware of the implications of doing that. Be aware that a 10% speed increase, implies that you will need to go ~30% slower for about the same amount of time. Be aware even that is assuming you don’t do it for a very long time, otherwise interest tends to explode:

After 11 cycles in our example the overall debt reaches over 200 and going 30% slower pays off just the accumulated interest alone.

And finally, while crunching numbers is always fun, in a real context, you usually don’t have the ability to control or even quantify the debt you are actually taking. In addition, in contrast to a loan from the bank, with technical debt you don’t get a balance sheet, or a forecast of the accumulated debt. You don’t get to see the real interest rate either.

When the team is told to run, they run as fast as they can. It doesn’t take that long time reach the point in which just paying “interest” causes a reasonable team to feel like it’s going in circles. Whenever you can give your team enough slack to prevent unintentional debt from creeping in. and pay your debt as early as possible.

Agile processes promote sustainable development – tl;dr

I recently published a blog post on Agile Manifesto tl;dr
One of my readers suggested I make it into a series, going through the agile manifesto principles. Great idea – I thought – where do I begin?
In the end I chose this one:

Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

Here’s why: If the Agile Manifesto is tl;dr for you, chances are you have no time to spend to read it thoroughly.
If that is the case, chances you are in, or en-route to, a state of burnout.
Not wishing to stress you out, but you should know that burnout can have catastrophic consequences:
The term burnout is borrowed from rocket technology. Yes, it’s rocket science, but you don’t have to be a rocket scientist to understand its implications.

What is Burnout?

Burnout rate is how fast a rocket is burning fuel. In normal rocket launch fuel burnout of one stage triggers separation and the start of the next launch stage. 
When, however, an airplane reaches burnout, people physically die. As in the Chapecoense Crash

In humans, burnout, or occupational burnout, is a condition in which a person is depleted of energy, efficacy and empathy. Since WHO’s ICD-10 (released 1994) and in more detail in ICD-11 (To be released 2022) Burnout is classified as a disease, although not a medical condition.

In medical care, burnout has been identified as a major problem. In “Physician Burnout: A Serious Symptom, But of What”, by JAMA, The Journal of American Medical Association, the authors conclude: ״The profession has violated the very way it has taught, and been taught, to approach the care of patients. The profession can and should do better.״

Why does this matter?

At the end of the day, a CEO cannot be held responsible for the well-being of each and every employee, right?
Not so.
In a “A Message To Our Fellow Health Care CEOs”, a consortium of CEOs of the leading U.S medical institutions say that “Physician Burnout Is A Public Health Crisis”. They concluded that:
“The consequences of physician burnout are significant, and threaten our U.S. health care system, including patient safety, quality of care, and health care costs. Costs are impacted by burnout in direct ways (e.g. turnover, early retirement, less than full time work) and indirect ways (e.g. poor quality , including medication and other errors, unnecessary testing and referrals, greater malpractice risk, and possibly higher hospital admissions/readmissions).” emphasis added.

Just substitute health-care with customer care, medication with h/w & cloud resources and hospital admissions with unplanned support calls. There is an almost 1:1 analogy to software development groups.
In Agile Manifesto speak that’s like saying that burnout eats all other principles for breakfast, leaving behind a mush of formerly brilliant employees and a trail of occupational-hazard lawsuits and other social benefit liabilities.

Note that the authors are not doctors or other medical practitioners. These are not CEOs of some dollar hungry, revenue driven institutions. These are the CEOs of the world’s forefront institutions of medical care: Mayo Clinic, Cleveland Clinic, Johns Hopkins, Duke University, etc. If you’re an executive of a medical-care organization, you cannot choose anything more prominent that one of these.

Imagine what Colombia’s football, journalism and national history would look like if flight 2933 would have taken off with enough fuel, and Chapecoense team would survive the flight? This specific flight would have been a non-event, just like any of the other ~100,000s commercial flights taking place every day.
But it didn’t. And as a direct result it crashed.

Back to the agile manifesto

Sustainable pace means that “The sponsors, developers, and users should be able to maintain a constant pace indefinitely.” 
That is, you must refuel. Regularly.
Otherwise, the results may be catastrophic.

What is Sustainable Pace?

So far I’ve discussed unsustainable pace. 
What is the desired state? What is sustainable pace?
Think of the difference between commuting to work on a highly congested day, during a good flow of traffic and on Boxing Day.
When traffic is flowing you feel you’re making progress, it feels healthy.
On a highly congested day you feel stuck and frustrated.
And driving to work on Boxing Day you know you’ll be alone at work, under-energized.

A Sustainable Pace means you could work at this pace indefinitely – it’s not overly frustrating and it’s not below your skill-level. 
It’s just right, most of the time, as in 90% of the time.

What to do?

You don’t have to do anything. Quoting Prof. Deming: You don’t have to change. Survival is just an option.
If you do plan to change, here are some ideas what you can do to bring yourselves from a collision course towards burnout back to a state of sustainable pace:

  • Hang out with people who maintain a sustainable pace, and learn what they do. Copy their behaviors until you master them yourself. There is (almost) nothing more impactful than being “infected” by people who respect their right to be healthy
  • Ask people who maintain a sustainable pace how they do it? What do they practice daily to maintain that state?
  • Read The Four Fold Way by Angeles Arrien. Or better – listen to it
    Or read/listen to The Four Agreements.
    Or The Power of Now.
    Any book that helps you internalize the importance of being mindful.  
  • Practice mindfulness, meditation, Tai Chi or any activity that soothes and suits you to refuel your mental capacities
  • Under commit
  • You probably spend a lot of time in meeting.
    Read Don’t Just Do Something, Stand There by Marvin R. Weisbord and Sandra Janoff. In particular, pay attention to “Learn to say No, if you want Yes to mean anything”
    And then practice their teachings.
  • Find and develop your own path to sustainable pace

So before attending to any other principle of the agile manifesto:
If you don’t have the privilege to take the time to study what “sustainable pace” means, consider the alternative.