In yesterday's post, I joked a bit about the term "waste elimination," giggling at the connection between Lean's main focus and a bodily function. But the more I think about it, I wonder if there is indeed a connection?
Sometimes Lean's fixation on waste strikes me as almost pathological. There's a focus on controlling things that borders on being what Herr Freud might call anal retentive. Does anyone else think "perfectionism and a compulsive seeking of order and tidiness..." describes the general zeitgeist of the Lean world? 'Cause that's actually from a definition of what it means to be anal.
I ask these questions with some trepidation, not seeking to malign, make fun or insult anyone... nor to excuse myself from my own psychological fixations and shortcomings. And I'm also not saying I buy into Freud's whole theory of psychosexual development. I'm just wondering if the word choice is more than a coincidence. Might it represent an unconscious aspect of the Lean proponent's psyche? Because if the focus on eliminating waste is indeed connected with a particular stage of psychological development, might that imply that there is a more mature approach further along the spectrum? Perhaps something that accepts messy creation instead of pursuing efficiency and tidy expulsion of waste?
Guys like Gordon MacKenzie and Richard Branson are among the least anal retentive guys I've ever read about... and their approaches to work are worlds away from Lean (as I understand it). They're messy. Wasteful even. And joyful to a degree that is absent in Lean circles. And oh yeah, they're profitable too.
According to this article, Toyota's Chief Engineer Taiichi Ohno "created the seven wastes." Sort of makes him sound like the evil character in a fairy tale. ("And then, the hero had to cross the Seven Wastes."). The writer probably should have gone with "identified" instead of "created," but maybe that's just me. And because I'm still a 12-year-old in my head, I giggle a little bit every time they talk about the importance of "eliminating waste." (he he he).
Ok, I do have a point, so let's get to it. One of the seven deadly wastes is "transporting." Apparently, according to this Lean approach, "moving your product from one location adds no value to your product."
Really? To quote a source of wisdom far more ancient than the Lean Oracles, "a bird in the hand is worth two in the bush." I think this old English proverb means, among other things, that location matters. We might even say that location adds value. Sure, I like to get free shipping when I order stuff, but I am willing to pay for shipping when I need to, because the right thing in the wrong location is of very little value to me.
How about an example? I'd pay more for a pizza that's in front of me than a pizza that's a hundred miles away. And whoever moved that pizza from far away to a location within arm's reach has increased the value of said pizza. Hey, when's lunch?
Am I missing something here? Sure, transportation of materials from point A to B and then back to A might be wasteful, but just because some movements do not add value doesn't mean allmovements add no value. Seems like someone's fallen for a logical fallacy to me. I just don't see the evidence that moving a product never increases the product's value. In fact, I'm pretty sure location is the ultimate value. So transportation not only creates value, it unleashed all other sources of value. We might almost say transportation is the source of all value.
I'm hoping someone (Mark?) will enlighten me as to this particular aspect of waste. Did I misstate the case? Or did the article I referenced miss the boat? I look forward to hearing your thoughts.
I recently had a chance to have a little mentoring session with an old friend. We'd worked together a few assignments back, and he is now at somewhat of a career crossroads. So he stopped by and we spent about an hour talking about his past, his aspirations, his options... and I look forward to seeing what direction he ends up taking.
This meeting was probably the most important thing I did at work all week. Taking time to listen to and consult with a fellow traveler, to be there and help him figure out what he wants & where he's going... man, that's some crucial stuff. Of course, it'll never show up in a weekly status report or a metrics chart. Its impact on operations isn't directly measurable, particularly since this guy isn't part of my current organization. It might even be called "waste" in certain frameworks.
But for any who are tempted to call those 90 minutes "waste," let me respectfully suggest that such a label devalues people AND overlooks the positive contribution made by activities like mentoring. If you really need a term that means "anything that does not add value to the product," fine. But maybe "waste" isn't the right word...
We got some great discussions going on the previous post, and I'd like to continue talking about one particular point. Specifically, the human side of this thing.
When I first read the "Red is good, green is worthless" article, the part that really stuck in my head was the horrifying scene where a group of employees was described as going from "proud and excited" to "devastated," thanks to a brief comment by Mr. Watanabe.
Now, I don't know if that actually happened. With all due respect to my friends in journalism, I am well aware that reports of events aren't always accurate (and as a writer myself, I'm sure I've mis-written a scene or two). But whether it happened quite that way or not, the writer was clearly holding it up as a sign of Mr. W's keen insight and wisdom, his ability to see through the "worthless" status report and identify a hidden problem.
Let me be clear - the scene as written describes a travesty, a failure of leadership that most likely has negative implications for the organization - and certainly had a negative impact on the people involved. A good leader - a real leader - would have recognized his employee's enthusiasm and figured out a way to redirect it as necessary, without emotionally violating the people. They would have walked away with energy, direction and insight. And if he did leave them feeling devastated (deflated, demoralized, disrespected), the real story would have been the way he acknowledged and made amends for his mistake.
See, leadership and management isn't about metrics, stoplight charts, production rates or even profits. It's about people. It's about taking care of them, encouraging, empowering and equipping them. I don't think it's much of a stretch to say it's about loving them. And it really bugs me to see a story about a "leader" who puts people down (aka a tyrant) being used to show how wise and insightful that leader is. It's even worse when the writer glibly glosses over the scene where people get hurt, and instead focuses on which color he likes better.
Bottom line: the real lesson in that story has nothing to do with metrics and everything to do with love.
I recently came across this article about "lean metrics," which basically makes the case that reporting a status of Green ("things are good") is unacceptable, because it gives the lean guys nothing to do. The only good value for a metric is Red ("things are not good"), and if anyone reports a Green status, you should "send them back to the drawing board." Wow, I disagree with it so completely.
Yes, whitewashing (green-washing?) a program is bad. It's not helpful to report that everything is good simply because you haven't dug deep enough to find the actual problems. Deliberately hiding problems is even worse. But this article stinks of a hammer in search of a nail. "If you are green, they don't know where to focus improvement efforts." Um, isn't it possible to be green because you DO know where to focus your improvement efforts? Maybe the status is green because you know what you're doing and things are actually going well. Let's not assume that a set of green metrics can only be produced by dishonest or superficial assessments.
The article also makes Toyota's Mr. Watanabe come across as a monumental jerk. Sure, it's possible he responded to a set of Green metrics by saying "no problems, must need no managers" with an unmentioned twinkle in his eye. Maybe he was trying to be funny. For his sake, I'm going to assume that's the case. I'll just ignore the writer's commentary about how his comment "devastated" the managers who had previously been "excited and proud." There's something to be said for challenging people's assumptions and encouraging them to leave their comfort zones, but there's no excuse for devastating them. I wonder how effective they were after this meeting. I'll bet their metrics turned quite red for some time to come.
Bottom line - red-washing a metrics report is just as bad as green-washing it. Good metrics are accurate, timely and actionable. Green or red isn't the question. The real quality of a status report is based on whether it's honest, not what color it is.
I've been hearing a lot about the proverbial "70% solution" lately. It's usually in the context of having to chose between "a system that delivers a 70% solution and a system that provides a 100% solution." But let's take a look at what we're really talking about here.
It turns out, we're not choosing between a partial and a complete solution. It's actually a choice between a partial solution and no solution at all. And to be even more precise, we're choosing between a series of partial solutions and no solution.
Here's how it works. A developer can't give you everything you need right now. But they might be able to quickly deliver a system that does SOME of what you need... followed by an additional increment / block / spiral / release that does MORE of what you need... followed by another increment, and so on.
So let's keep in mind that the partial, 70% solution isn't the whole story. It's just the first increment. As a dedicated imperfectionist, I'm pretty cool with the 70% solution to start with. And as a guy-in-a-hurry, that's at least partly because the 70% solution is generally available MUCH faster than the 100% solution. It's cheaper too. But if you do it right, it's also not the end of the story.
On Saturday, 5 Dec, DARPA launched a contest in which they placed 10 red weather balloons at locations across the country. If you're the first one to submit the lat & long of all 10, you get $40,000. That's right, 40-grand just for finding 10 red balloons. Dude!
The catch is that submissions are due by 14 Dec - that's a little over a week to criss-cross the whole country and find these balloons. The idea is that you can't do it yourself. DARPA is trying to explore the impact of social networking and cross-country collaboration in the field of information collection. Which means whoever wins will probably have to share that $40K, but it's still a nice chunk of change.
It's always fun and fascinating to see what DARPA is up to.
A British medical researcher (and eventual Nobel Prize winner) named Edgar Douglas Adrian was doing some research involving the toad retinas. Hey, who doesn’t love experiments involving toads, eyeballs and electricity? OK, so having attached electrodes on the poor toad’s optic nerves, Dr. Adrian was surprised to hear repeated noises coming from the loudspeaker attached to an amplifier that was being fed by those electrodes. I don’t know what sort of experiment involves wiring toad eyeballs to loudspeakers, but there you go.
Anyway, the room was dark and the sounds were unexpected. Like a good scientist, Dr. Adrian set about to figure out what was causing these noises. He writes “It was not until I compared the noises with my own movements around the room that I realized I was in the field of vision of the toad’s eye and that it was signaling what I was doing.” The year was 1928, and this experience proved the presence of electricity within nerve cells.
The point of this story is that sometimes the most important discoveries come when we're looking for something else, so it's important not to be so focused on the problem you're trying to solve that you miss the problem you should be solving. As the great American philosopher Ferris Bueller once said, "Life moves pretty fast. You don't stop and look around once in a while, you could miss it."
One of the questions people sometimes ask about the FIST approach to systems development is about procedural waivers.
"What rules, regulations's and processes and procedures do we need waivers for, in order to do this FIST thing?"
I have to admit, I'm always a bit confused by that question.
See, FIST is a set of values that is designed to influence our decision making and organizational behavior. It says "It's important and good to be fast, inexpensive, simple and tiny." There generally aren't any regulations or requirements that forbid such a stance. Sure, some rules and reg's are less than helpful, and some interpretations of rules point us in the opposite direction of FIST... but in the latter case, it's generally because our values are pointing in that opposite direction anyway!
The bottom line is that FIST can be applied under just about any framework or set of guiding policies. Strictly speaking, no waivers are necessary and nothing is really stopping us from opting for the faster, less expensive, simpler and smaller option. Having said that, FIST can also be applied TO just about any framework or set of policies. We could simplify, shrink and accelerate our policies - I think that'd be good for everyone (because I think the FIST values are good).
And yeah, I'm sure just about every technology development environment has some policies, regulations, etc that are un-FISTy. But do you need a waiver or some sort of official permission to make decisions these ways? No - if you're making design decisions (about documents, technologies, organizations, etc), you can make them with FIST.
Had a great time at Disney over Thanksgiving - but instead of getting home at a civilized 3:00 on Sunday afternoon, we pulled into the driveway at 1am Sunday night / Monday morning. Why you ask? Because of a compressor that decided to let all its smoke out (and every engineer knows that computers, cars and other devices run on smoke, so it's important to keep the smoke inside. If the smoke gets out of the computer/car/space telescope, it stops working... and it's very hard to put the smoke back in).
So... less time + more exhaustion = a lack of posts for my friends here at RPL.
But I'm working on it, don't worry. More Rogueishness coming up soon (and for the record, I was using the word Rogue way before Gov. Palin picked it for her book).