English | EN Bring Back Intrinsic Quality!
Jul 29, 2014
The effect of intrinsic quality on Agile
Intrinsic quality, I put the terms together to imply that quality is best when it is an essential part of the product or work. It is part of the essential nature of “a thing”.
When we think of quality we think of how good “a thing” is.
If I ask people my parents’ age how they perceive quality, they often refer to how things used to be sturdier and better when they were young. My imagination often goes to Victorian age quality, the kind you find back in movies like Harry Potter where the sturdy hinges of big travel chests are near indestructible. I do realize that:
- My parents aren’t THAT old
- Quality does not necessarily mean something has to be bulky.
When something is bulky is it going to withstand the test of time? Is that intrinsic quality? I doubt that is what makes things sturdy, of higher quality.
I am active in Agile circles and there is a big influence in Agile from Toyota and the Toyota Production System (TPS). In addition to TPS being the source of Lean manufacturing and many ideas within Lean can be traced back to TPS, it has also been an influence of Agile and Agile methodologies and frameworks.
In TPS there is something called Jidoka. According to Toyota (I reference the TPS Brochure of Toyota forklifts[1]):
Jidoka translates as “autonomation” and can be described as “automation with a human touch”. Quality is monitored throughout, with each team member being responsible for performing quality checks before delivering the goods-in-process to the next point in the production line. If a defect or error is identified it is addressed immediately – even if this means temporarily stopping production.
So you FIX a defect or error when it is identified, EVEN if this means temporarily stopping production.
This is very important to Toyota, fixing errors when they are identified. What kind of quality does this give “a thing”?.
Example: You are writing a blog post and you notice that you typed a word wrongly. What do you do?
- Ignore it, if you do not fix it in your final read-through your editor will most likely fix it for you
- Make a note of it on a piece of paper, count the lines where the error is, what kind of error, mark the type of error on a separate list where you count the severity of the error and check your list of allowed severity to decide which you will fix first
- Fix it now!
Though I know most people will think B is ridiculous, I would like to remind you of this later in this post. I will start with A.
Will ignoring save you time? Do you think you will find the error when you read over your blog again? How many errors will go through anyway, even after it has been reviewed by your editor, your colleagues and the first readers of the post?
I do not claim you won’t find any errors in this blog post, but I do claim that this mentality is what I see a lot with developers. But Latin mottos sometimes say “amat victoria curam”, Victory favors care.
You probably guessed it already, I favor the last answer. If you fix errors now it will lead to better quality, quality now, and it will lead to Jidoka.
Fixing errors now, Is that intrinsic quality? The simple answer to that is No. But the mindset that when you encounter a problem you fix it immediately is what I mean with intrinsic quality.
We all get older, and when we are asked “what is quality to you?” you might remember that bike you got for your 10th birthday, one that had been fixed many times by you and that always took you everywhere. Or the car that was part of your youth for many years. It might be a bit overshadowed by nostalgia. You may not remember all the frustration you had having to fix the damn thing. But you may remember that you perceived that as being quality.
A product that has that feeling of sturdiness, what was the defect count? And did you tolerate 2 Major defects, 10 Minor defects, 50 Trivial defects?
Did you keep a list of the defects?
Did you contemplate fixing your breaks and then ignored it as the costs for fixing the slightly worn out breaks outweighed the chance of crashing into other traffic users?
When I train people in Agile and mention Jidoka to my students I sometimes get the question “but why does Toyota have so many recalls? “.
I like to answer the question with a counter question, “Why do other car companies have so little recalls?”. I can refer to cases, even recent ones, where car companies did not recall cars even though they did know about the life threatening problems with some of the cars parts. Why did they not recall those and let deaths occur?
Legal costs is a plausible answer, and so is Image name. Some companies apparently weigh these and decide if they do a recall or not. Are you driving in a car like that?
Maybe the sense of quality that Toyota displays in their recalls, despite the damage to their name[2] has led them to decide to replace their robots with people [3] as people learn and robots do not…
Intrinsic quality does not ensure there will not be errors, “errāre hūmānum est”, to err is human. When you are a customer you DO expect that there is quality, especially when you buy something on which you will rely. Some of the most common causes of skydiving fatalities are issues with a person’s landing or malfunctions with the skydiving equipment[4]. Landing is a skill, but skydiving equipment is your lifeline.
In Agile and specifically Scrum I EXPECT intrinsic quality. It is most likely the biggest misunderstanding of Scrum that I know. And I do understand that when you move from a control focused way of working, where metrics and directing people on numbers is important, that you rely on numbers.
What does that mean, Intrinsic quality in Scrum? It means that when an error, defect or problem is identified, the team FIXES it! It means that the Scrum team has a focus on delivering quality. We’ve been teaching this for a long time. Scrum gives you constant quality. Then lets live up to that.
This also means we are not going to keep defect lists, nor are we going to accept known bugs. As far as I am concerned, there are no bugs in Scrum. There is only work. To quote my mentor Jim O. Coplien in our trainings together “Fix it!”.
Bugs are work, just like the features that the development team in Scrum builds. When defects are detected they are pulled in by the team and fixed. If they cannot be fixed right away they are put on the backlog so the Product Owner can look at it.
“Isn’t that the same as known bugs?” It is inasmuch the same that known here means visible. All the work in a product backlog is visible. There is no special list for defects, so defects are picked up by the team when work is picked up. The right person determines if the work is important, not the person who found the defect. All the work is important.
This does change work for the testing world. After all, the tests that are carried out by the whole team also include detecting defects and fixing them right away. But I know how many in the test world still expect a defect list.
Agile in itself is a mindset, it is reflected in the Agile Manifesto and it means there will be a paradigm shift. Intrinsic quality for me is part of Agile, and most specifically part of Scrum. We know what it means, it’s having heart for the product you work on, it’s making it something of your own. It’s being proud of what you create the same way master crafters of old were proud of what they made and it usually made them famous. They usually gave their clients a lifelong guarantee on the product, especially when it came to production issues. I’d also like to see that kind of trust back, trust in the product or work that you deliver.
References:
[1]Toyota Forklifts Toyota Production System Brochure (Page 10): http://www.toyota-forklifts.eu/SiteCollectionDocuments/PDF%20files/Toyota%20Production%20System%20Brochure.pdf
[2]Toyota recall: Reports of Runaway Cars: http://abcnews.go.com/Blotter/RunawayToyotas/runaway-toyotas-problem-persists-recall/story?id=9618735
[3]Toyota is becoming more efficient by replacing robots with humans: http://qz.com/196200/toyota-is-becoming-more-efficient-by-replacing-robots-with-humans/
[4]What Are the Common Causes of Skydiving Fatalities?: http://www.wisegeek.com/what-are-the-common-causes-of-skydiving-fatalities.htm
About the author
