The hidden dangers of Process Debt

Most of us involved in software development are familiar with the term “technical debt”.

As a quick reminder, it was introduced by Ward Cunningham to describe the phenomenon that occurs when we use code that is easy to implement in the short run instead of applying the best overall solution we have identified.

It is by definition a conscious decision to take a shortcut for short term gratification (like taking out a new credit card for a holiday) that in thew long term will cost us to spend extra time in development when improving the system (like paying interest on the credit card debt).

Until the capital is repaid in full we will always pay interest when adding features to the system as the debt creates obstacle to adding new code efficiently.

Ward suggests that when we are in a situation of rushing something out we need to be conscious that we will have to pay the capital in the future or the interests will cripple us.

Ward suggests refactoring as a solution to paying off technical debt.

I really like Ward’s vision and I want to expand the metaphor one level up.

Now if we change the word “software” in my description of technical debt above with “processe” we can define Process Debt.

Replacing we get:

Process Debt is the phenomenon that occurs when we use a processes that is easy to implement in the short run instead of applying the best overall solution we have identified.

Let’s look at one example

You notice that lately the system seems to be more unstable than usual. You know this because there are more calls from customer care and more defects get raised.

Option 1: You want to get to the bottom of the situation and believe that a root cause analysis with 5 whys could get you there. If you use this approach you will probably identify a change in your process to help you prevent some defects in the future.

Option 2: You implement a better policy for developers to select the defects to work on reducing the time the defects are in the unresolved queue while maintaining new features creation throughput relatively stable.

You know Option 1 is better in the long run because it will generate a change in the process to reduce the amount of rework. This will mean less time spent fixing and more time spent on new features that as a consequence means higher throughput and lower lead time for new features.

Option 1 requires some investment. You need to hold one or more root cause analysis sessions, identify the problem(s) experiment with solutions until you find a solution that mitigates your problem.

If you are under pressure, because the new product needs shipping and the old defects need fixing, you are likely to choose option 2.

By doing this you have introduced process debt

The capital of this debt is the lack of change in the process  you could have identified if using Option 1.

Oh, yes, I forgot, change is difficult.

The worst part of it is the interest on the debt you will pay forever until you pay the capital. This interest will appear in the form of.
1. bugs keep on coming, we seem to be fixing bugs all the time
2. new features get delayed because now the queue is in the new features to be delivered
3. the lead time of any new feature is expanded by a factor X
4. the customers continue on complaining because of your defects in production
5. your product owner starts being annoyed at the amount of work spent by the development team on defects
6. developers are tired of always fixing defects
7. …
n. need I say more?

This interest will be paid for the rest of your life if you don’t fix the problem.

Months after you are covered in defects, are stressed by your customers and change job.

Is this healthy? Certainly not.

Is there a cure? Oh yes, indeed.

Continuous improvement has the same effect on process that refactoring has on software. It repays the capital of your process debt.

With small changes in the form of experiments you will be able to clearly discuss the problem that the team is having and make small tweaks continuously.

My esteemed colleague and fervid innovator Claudio Perrone presents his continuous improvement model called PopcornFlow saying

If change is hard, make it continuous

I could not agree more.

By making process change a continuous activity, we enable behaviours that will stay with teams forever and we unleash the power of people’s creativity in improving their own way of working.




A short report on my agile experimental talk

Last week I asked the community for help on designing an agile talk rather than a talk on agile .

If you don’t want to read the full article here’s the TLDR: Can we embed the agile values in the format of a beginners talk so that people will learn by breathing them rather than hearing about them?

I received quite a lot of encouragement from a lot of people. I love the agile/lean community, thank you folks, you are incredible!

I got some great suggestions from Patrick Steyaert that recommended looking into Lean Coffee and Fish Bowl.

Both formats are highly participative and pretty much agendaless and gave me a great point to start at.

My goals in priority order:

  1. Do not bore an audience that for the first time hears about agile. Don’t push them away!
  2. Identify a format that embodies the values I believe to be the most important in agile and make sure the attendees feel and recognise them while they are attending
  3. Make sure people actively participate
  4. Have fun

To me the most important values in agile are: people, customer and responding to change.

The People

I asked 3 fantastic practitioners to help me on the day. The 4 of us were “the agile product team” that was going to deliver the product (learning) to our customers (audience)

Thank you so much to Claudio Perrone, Andrea Baker and Lisa Hickey for accepting to help with less than 24 hour notice and no details whatsoever on what i needed them to do (isn’t this ability to respond to change? :-))

my teammates.png
My Fantastic Team Mates: from left to right Claudio, Andrea and Lisa

The Customers

I told the audience that me and my team mates were going to give a product to them, they were our customers and as such they were extremely important.

To start we needed the customer help to understand what real value is to them.

We asked them to select with dot voting some agile topics from around 35 different agile topics (I took a subset including mainly basic concepts).

The topics were taken from ‘s wonderful Agile Topics card deck that I printed and laminated (for the quite steep price of €50)

The customers immediately queued towards the table where the cards and the markers for voting were. We time boxed the activity to 5 minutes. Claudio, ever the lean man,  immediately identified a bottleneck as the table was too small and only 2 to 3 people could vote at the same time.

Customers queuing to dot vote (bottleneck)

The activity had to be extended to 6 minutes to allow everybody to vote.

The team took 6 topics with highest number of votes and put them on the wall in dot voting ranking order.

We started with the first topic.

It happened to be BDD: First thing, I asked the customers if they knew what it was. One of the people in the audience started giving us his take. When he finished, I spoke about it a bit, then my 3 team mates took turns in adding their perspective.

Responding to change

This lasted for 5 minutes when the timer went off and i asked the audience to tell us by using thumbs up or down whether they wanted to continue talking for 5 more minutes about BDD or if they wanted to move to the next topic.

People voted for sticking to BDD for 5 more minutes

After 5 more minutes we voted again and we went to the second topic.

We made sure that the team swapped activities, everybody took turns in talking about the topics, we alternated roles like time keeping and pulling the cards from the wall.

We wanted to show team collaboration and cross functional abilities.

The topics selected by our customers

I got loads of feedback from the people in the audience and the team.

Claudio suggested that when talking about topics, the first couple of sentences need to describe it in a easily understandable recipe format, this is true in particular because of the audience low level of agile knowledge.

Davide Lovetere an enterprise Architect among our customers gave me a lot of incredibly valuable feedback around some contradiction in terms he had noticed during execution.

Other customers said that they enjoyed the format and want to use it for some of the meetings they do in work (yay!)

Other customers said that they enjoyed it but it finished too early, we only had time to talk about 4 topics and they would have loved to touch more

That’s me having a ball as usual when I speak at conferences 🙂

I loved doing it, received valuable feedback to improve it and can’t wait for the next time!



Continuous improvement is an infinite loop

This morning, at home with the flu, I thought about visualizing a continuous improvement process (that’s what crazy people do when they are sick). So I took markers and paper and I started to draw. Looking at it I realised that I was drawing an infinite loop. With my developer hat on I thought: WTF? There is a problem. I need to fix it.

Then I looked again, and it hit me. No problem at all, continuous improvement IS an infinite loop, and if you think you are done improving your process you are doomed!

You might say that the word continuous should have tipped me, yes you are right, but I find that looking at a graphic representation of a concept always makes me discover new things, that’s why I draw things even though any 5 years old could do a better job.

Markers + A4 paper + MsPaint + phone cam + Gliffy created this thing

Continuous Improvement

5 Reasons why best practices are bad for you

That’s me after talking to a best practice guy

1st reason: The hardest conversation you will ever have is with somebody that blindly believes a practice applies to every context and it is always valid, no matter what. There are 2 ways out of the conversation, agree with your interlocutor or kill him. I don’t like either option (even though I am often tempted by the second) so I end up trying my utmost to use reasoning and examples, but I miserably fail in 99.99% of the cases, eventually become exhausted and retreat in a personal comatose space where I refuse to discuss the issue any longer. #WinByExhaustion

2nd reason: Think religion. If you are roman catholic like me, then the Bible is your best practice manual. The Bible thinks for you, you simply follow and if you doubt something then you are an infidel that should be excommunicated (who cares?) or worse silenced and sometimes burnt at the stake, don’t you love it? Some names come to mind including Galileo Galilei that was intelligent enough to refuse his own belief, but  if you want a more detailed list have a peek here:

Burn him at the stake!
Is this what you do to different thinkers?

The thing is, you cannot innovate if you believe in best practices, because according to the best practice you don’t need to innovate. Did the roman catholic church evolve? Did they innovate? Fuck no! They are stuck to the day that poor Jesus Christ (God bless his soul) died on the cross and his followers started writing about him. #NoInnovation

They have them, they are very well hidden and they are too nice to use them against us: TRUTH

3rd reason: Best Practices are your #1 personal growth enemy. I see extremely intelligent people that have best practices so ingrained in their DNA that refuse to accept every valid reason, no matter what the evidence is. These people are the ones that will lag behind, because for example 20 years ago they might have said “what’s the fuss with this Internet thingy, business is run in factories and shops, you won’t make money with it, unless you are a porn site provider”. Today I hear financial experts saying “Forget about Bitcoin, money is money and people want it in their wallets and regulated banks”.

4th reason: Best practices are the antithesis to kaizen, do I have to say more? #YoureStuck

Become Better, be the change

5th reason: Best practices deny men the greatest pleasure of them all, discovery. The day that you switch your brain from following the best practice is the day you might discover something awesome about yourself. The day you start listening to the person you are talking to without having the mental block of the best practice that doesn’t allow you to agree with him. That day you will grow. The day you will say “eureka!”. The day you will discover you are FUNDAMENTALLY WRONG. I love those moments, they make my brain go at 200 miles an hour and in a day I grow more than in 10 years.   #NoEureka!

Everything’s squared away

To finish I wanted to thank a few people that helped me reach the “eureka!” moments, you are the reason why I have evolved and I am a better person today than I was before.

In no particular order:

Monica Campardo, Emmet Townsend, Diego Armando Maradona, Roberto Lo Giacco, Gojko Adzic (twice!), Don Gabriele, Aunty “Zia” Enrica, Lisa Crispin and Janet Gregory (books), Mary Coyle, Giacomo Leopardi (poems), My high school Maths teacher (I don’t remember his name but was known among students as “il Roscio” => “The ginger”), Eric Ries (books), Barry O’Reilly and the other guys in ThoughtWorks, Jayne McCormack, My Brother Duccio, Evariste Galois (books), Gianluca Perazzoli, Gerard M. Weinberg (books), My lovely sister in law Luana, My Nana (highest amount of times), Martin Fowler (blog), Gandhi (life and quotes), Auntie Ada, Massimo Troisi (movies), Roy Phillips, Roberto Benigni (movies), Dan North, The “Dude” in the Big Lebowsky

I thank you all with all my heart for proving me FUNDAMENTALLY WRONG that day, and inspiring me to become a better person. I might have forgotten one or two, sorry folks.

Do you want to be in the list? Prove me FUNDAMENTALLY WRONG and give me a “eureka!” moment, I will love you forever!

the dude teaches
The “Dude” proved me wrong when I thought I had to be a serious and stiff arsehole to be liked by people