Which came first the fun or the fun committee?

The other day someone asked me if I’d be interesting in joining the team’s fun committee.  I declined.  For a couple of reasons – one, I don’t find being on fun committees much fun.  I don’t get any of my normal work taken away to plan events so it is just extra work.  I don’t need extra work.

But more importantly, it dawned on me why the idea of a fun committee was intrinsically doomed to failure.  When organizations aren’t performing well, people often (correctly) recognize that the ability and willingness of the team to work together is lacking.  Work gets reduced to a series of cover your a** conversations, documents, email trails and so on.  We exchange productivity for busy work.

And thus people dawn up the idea of improving morale and helping the team work together.  They form fun committees!  The thing is, if you team was having fun, you wouldn’t need a fun committee and the fact that you have one means you’re already in a tough spot.  Why did you create a fun committee?  We don’t do it because we genuinely believe it is fun.  We do it because we think the organization will get value from it.  And thus the goal is all wrong.

Yes, the organization does get value from a team who likes to be together, but you can’t make teams more productive by forcing them to have ‘fun’ together.  Sure, people may even enjoy the free lunches, beer or whatever else.  They may show up and socialize with each other, but it doesn’t build what you a really looking for, a shared sense of purpose and trust in each other.

People who have common mindsets form groups all the time in the real world.  They’re called friends!  But these friendships stem from the fact that the people in them want the same types of things – whether they rally around a certain sporting event, a hobby, or even just a good stiff drink.  And having found friendship, these people are inclined to do more for each other and also receive personal satisfaction from doing it.

But there are lots of cases where people get together, have a good time for a moment and never interact afterwards.  They’re called parties.  The relationship is fleeting, and while I may enjoy your company, once the party is over I am unlikely to think of you again.  Fun committees make the equivalent of parties, not friendships.  We may be all in the same place together sharing an experience, but I don’t feel more strongly for you from having done it.

If you’re thinking about a fun committee, I think you’ve already gone down a bad path.  Think instead about the things as a leader you are doing to prevent your team from gelling.  Are you isolating them, suppressing them, enforcing an hierarchy that need not be there?  Do you berate them for their failures but never reward their successes?  Do you over-reward (patronize) them for minor wins rather than great things?

Teams can function without gelling.  I still believe that good process is critical, even in a well functioning team.  However, it can only help to have a well functioning team, so why act to destroy it?  And that’s what is most important to understand.  You can’t make a team gell by having a fun-committee, but there’s a lot you can do to destroy them coming together on their own around whatever it is they feel is fun.

Bound by the speed of paperwork

While the speed of light may represent some theoretical maximum, I have discovered a speed which is much more important at work: the speed of paperwork. I am not opposed to an appropriate amount of forethought to be put into changes, but sometimes it is just too much with little to no added value.

Take for instance, freeze exceptions. A freeze exception, where I work, is an instance where you make a change into a test environment in the narrow window prior to the roll to the next environment. It occurs at the end of every month and lasts about a week. If, during this time, you want to add new code to the environment, you have to get a freeze exception. The release team believes changes during this period “destabilize the environment” and therefore extra paperwork making sure the change must go through is justified.

I have some issues with this. One, most freeze exceptions are approved, the vast majority of them in fact. If you aren’t going to say “no” to changes then why make people jump through hoops to make changes at the last minute.

And more importantly, nothing about code intrinsically requires a minimum of a week of warning. The weeklong freeze period is arbitrary. Consider if I was building a house. You go to pour the foundation and then you have to wait a week or two for it to cure. You most certainly don’t want to build on top of a just poured foundation, even if it feels hard to the touch. Concrete takes a long time to reach full strength. Waiting for that time is fully justified.

But code? When it’s ready it is ready. Freeze exceptions assume that when you put something in during the last week prior to the environment roll that you are “rushing” and therefore scrutiny is desirable. However, there’s no reason if you put in code during the acceptable window that it should be more stable than code put in at the last hour. If the code is written properly and checked adequately, I don’t care if it is a day, and hour, or even a second before the start of the environment roll, it is safe to go. What freeze exceptions assume is that developers can’t make changes quickly and correctly, and that’s just not true. There’s nothing physical about coding which binds you to a certain minimum time.

As a result, can you even justify this extra paperwork? Does it really make a difference at all? At least in the research I did, it did not. I could find no evidence that freeze exceptions led to more production incidents. While the two had a moderate positive correlation, the r-squared was ridiculously low (where freeze exceptions predicted production incidents), indicating that it was a poor predictor of production incidents. Much more likely is that both production incidents and freeze exceptions share a common cause, which happens to be the number of bugs you are fixing this month.

Yes, bugs fixed this month are a great predictor (r-squared > 88%) of the number of bugs you will have next month. It shows serious auto-regressive characteristics in trend analysis as well. And that makes sense, because if you have lots of bugs to fix in a short period of time, some are going to have to be fixed during the freeze window and thus you will have to generate freeze exceptions. And secondly, if you are really sloppy about fixing bugs, then you end up in a fix-one-break-two kind of shop. But if you just dealt with the cause – why do you have so many bugs to fix and why can’t you fix them correctly – then the freeze exceptions would go away all on their own.

Don’t let your processes get bound by some arbitrary expectation of a timeframe to get things done. You may think a week is about right, but if the upstream process can get it to you capably in an hour, learn to adjust to the rate that things really come into your queue. It’s ridiculous to have a process which encourages people to go slower if they’re capable of safely going faster.

Excited about nothing

Lately I’ve been doing a lot of work with the Quality Assurance department to try and lean out their operations. If I haven’t said so in prior posts, I thoroughly believe that the entire QA department (at every company, not just the one I’m at) should be figuring out how to get rid of itself. No matter how you slice it, QA’s job is to find defects and that means rework. Just don’t create the defects in the first place! Ok, I know that’s not realistic, but it at least means that you have to do whatever in your power to minimize the necessity of slow and relatively ineffective testing.

At any rate, I’ve been working on measuring the organizational efficiency and I was comparing their test case execution patterns to that of a known sample from a whitepaper I had gotten from IBM. IBM had recognized that there is an S-shaped curve to the cumulative execution of cases. That is, you start off slow, ramp up, and then as you reach the end, the last few cases take a longer time to get done. I don’t know why this is particularly, but I wondered if the same applied here.

And that reminded me of a story about a college professor. Professor Reid was a geology professor at my college, and the way my college curriculum worked, even if you weren’t majoring in the natural sciences you still had to either take a certain number of courses or do a project in the natural sciences. I opted to do a project, though I had no idea what that project was going to be. Fortunately, someone lined me up with Professor Reid.

Professor Reid told me that he had taken a bunch of high school students (on some sort of outreach program) to Shapiro Brook, a generally unremarkable brook which ran down the side of a nearby mountain. At the top of the mountain where the brook sprang from the ground was a quarry.

Now, I’m probably going to get this wrong, so if you are a science buff, I apologize. If you are a science student looking for information on conductivity or pH, this is NOT the place you want to look. You’ve been warned.

Anyway, apparently, the behavior of “normal” brooks is that when the water springs from the ground it has relatively high pH and low conductivity. This is due to there being lots of free H+ ions in the water. As the brook travels over the surface, the free H+ ions are bound by Potassium (K) and Sodium (Na). As a result, this causes the water to become more neutral in pH (pH drops) and more conductive (conductivity rises). As I said, that’s the “normal” behavior.

What Dr. Reid and his students found was the exact opposite. For some reason, pH rose and conductivity dropped. He found this fascinating and wanted me to repeat the experiment, bring back results and finally even put some of that stuff through a Plasma Mass Spectrometer. The Plasma Mass Spectrometer is the kind of equipment that GRAD students wait in line to use, so I was super excited to have the opportunity. Dr. Reid thought, by the way, that the active quarry at the mountaintop was somehow impacting the pH and conductivity of the brook, though he wasn’t sure what the mechanism was exactly.

Anyway, early that fall, I walked up the mountain with a conductivity meter and about 40 little plastic vials which I had properly cleaned with DI Water… blah, blah, blah I won’t bore you with the details of my proper experiment preparations. Every 50 yards or so I took a vial of water and a conductivity reading. When I got back to the bottom of the mountain, I pulled out my map that I had been given. I don’t know why I did this AFTER, but I did. And that’s when I realized I had walked the WRONG brook. Now, I was a college student who was just trying to complete a coursework requirement. I could’ve just used the data I had, forgetting whether the results were honest or not. But, no, I felt guilty doing such a thing, though it crossed my mind, so I went back to the lab, cleaned 40 more vials and trudged back up the mountain this time with my map out in the first place.

Again, I went down the mountain collecting samples every 50 yards or so. Once winter fell, I returned to the same brook to repeat the experiment. We did this to make sure that little feeder streams weren’t influencing the main brook. Of course, this time instead of walking down some of the mountainside, I fell and tore up my hand and wrist pretty good. Determined to not have to go back and make yet another trip, I ripped off some of my shirt, wrapped my hand and wrist (that was probably melodramatic of me), and proceeded to complete my measurements.

When I got back to the lab, I carefully tested the pH of every vial and recorded the data. Then, I brought all my results and readings back to Dr. Reid. I couldn’t really make heads or tails of it, but he could. He literally started bouncing up and down in his chair with excitement. Not in some sort of ridiculous way, but just a little more spring as he talked to me, and his eyes lit up, and a big smile came to his face.

“NOTHING! Shapiro Brook behaves just as it should!” he exclaimed.

I was heartbroken. How was I supposed to write a college paper on nothing? Dr. Reid was undeterred. He proceeded to tell me how great this is, to disprove that there was anything special about Shapiro Brook at all. To in fact find that the world worked exactly as we would expect it to work was, to him, joyful. “You could be a science guy,” he said to me, “have you ever considered switching concentrations?”

And that stuck with me through all these years. When Dr. Reid passed away in the early 2000s, it was this story that first came to mind, and the story that came to mind when I pulled together my data for Quality Assurance.

Sure enough, our QA teams experience the same patterns of progress that IBM had observed. The S-shaped curve wasn’t just some IBM myth. I’m not a QA person, just as I wasn’t a “science guy” back in college, so maybe all QA people know this, but I didn’t. There was excitement discovering that we were just like everyone else, so I sent an email titled “so cool!!!” with the details of my findings to a good friend who I knew would appreciate it. There is satisfaction in finding out that we are not special or different, that despite what people believe, things that the outside world experiences can be applied to us. It gives us hope that what we learn elsewhere is transferrable knowledge.

The End is Near!

Wow, it’s been a thought provoking day for me. I’m on post #3. I’m sure it’ll be a rare occurrence to post this much at once. As a matter of fact, this last post was somewhat motivated by the fact that I can now make new posts to my blog via email and I wanted to try out the feature. I’ve never been much of a fan of going to a site to do one specific task and I like the integrated nature of this. Plus, using Outlook, I get better spell checking capabilities for free.

On to the topic at hand! The End is Nigh!!! No, I’m serious, the Agile iteration that the team I’ve just joined is coming to an end. Surely you recall my less than stellar review of my own first Agile experiences. On the plus side, that entire team I was with was broken up and my misery brought to a prompt end. On the negative side, I just got dropped onto another team also trying pseudo-Agile. This is to say, they do daily meetings and stories and iterations, but no software development to speak of.

Anyway, I got dropped in the middle and we’re apparently about one and a half weeks away from the end of this current iteration. It’s triage time because the owner of this (what do they call it in Agile? Group? Stream?) team (for lack of a better word) realized that they weren’t going to get any of their stories done. So, rather than say “hey, we’ve got a deadline here people and things need to get done” they’re saying “don’t worry, we’ll just move it to the next iteration.”

Ah, the double edged sword. The reason for iterations is so the business doesn’t over ask. They learn to trust development and to have them deliver a small piece of useful functionality rather than requesting the world all at once. In theory, since there will be more iterations in the future, there will be another chance to ask for more features. On the flipside, which seems to be happening on this team, and probably others, the development teams ALSO know that there will be more iterations. And why do today what you can put off until tomorrow?

Sure, the end is near, but on a single-big-realease project, what goes in is what goes in. You get you chance and you need to deliver. With iterations, even if today’s end is near, there’s always tomorrow. I’m not saying this is endemic of Agile, but it is a risk that needs to be addressed. In any methodology, there’s still a need to commit and deliver and having chopped the commitments into smaller blocks should not be an excuse to procrastinate. But it appears to be that way.

On the goal of being lean…

It is to some degree a strange coincidence of events that I am writing this post:

1. I was reading EvolvingExcellence blog post regarding the author, Bill Waddell, who has committed to stop complaining and actually do something about the loss of manufacturing in the USA.  As his first salvo, Bill writes a well thought out article about the fallacies being spread by the BLS and both sides of the aisle in congress.
2. I recently read “What Happy People Know” by Dan Baker.

It’s times like these that solidify my position as Democrat more than a Republican.  Coincident events like above that make me understand why I don’t agree with the capitalist position. 

Bill’s post focuses on the loss of manufacturing jobs in the United States as being a warning sign to the US failing.  He argues against the use of cheap labor elsewhere as being valid globalization, noting ridiculously low productivity and the oppression of foreign people as not good ways to build wealth.  He believes that wealth building manufacturing jobs in the US are being lost in exchange for a false value.  And he argues that sending more people to college to become more skilled isn’t going to fix it.

On most of these accounts I agree with Bill, except one.  “Wealth building.”  I’m not saying that manufacturing jobs aren’t wealth building.  I’m not qualified.  I’m arguing that the goal of building wealth is incorrect, regardless of how it is built.

See, I told you I was going to disagree with capitalism.  But why, you ask?  Because of the book “What Happy People Know.”  Dr. Baker’s book is very well written, and I’d recommend reading it (I get no kickback for saying so), but it is simple to summarize.  Money DOES NOT equal happiness.  It isn’t a Dr. Baker idea.  It’s a saying that’s been around forever.  It’s true.  It’s been studied.  Rich people are not, on the whole, happier than the less fortunate.  Having more stuff doesn’t take your worries away, it adds to it.

There are even joking retorts such as “money may not buy happiness, but give me the opportunity to prove them wrong.” or something like that.

It takes some introspection, but consider your life for an hour or two.  I’d say a minute, but let’s be honest.  Go for a walk, think about what truly makes you happy or what would make you happy.  Most people will tell you that they’d be happy if they made twice what they make now.  And yet, when people achieve that, they’re still not happy, and again believe that twice what they are now making is the magic number.

I have a good job, I make a decent living.  I can afford our house, our cars, food and health insurance.  And yet, if I made twice what I made today, how different would my life be?  I’d have a bigger house and take up more space.  I’d eat more expensive food.  I’d still be able to afford everything, and yet it really isn’t a different thing.  It’d just be more of the same.  The thing is, even if I had billions of dollars, though I could buy pretty much anything I wanted, I still only physically occupy so much space.  I still only need so much to eat.  What would I be getting for all that money?  I sleep well at night, my health is good, I love my family.  More money isn’t going to change the basic factors that make me happy.

Wealth building as a goal is misguided in my mind.  Being LEAN has a very important value aside from making people rich (and creating disparity).  Being LEAN means being able to provide everything I need to survive PLUS something that can improve the value of society as a whole.  If I can become twice as efficient and make 2 chairs in the time it took me to make one, then I can have a seat and so can someone else.  If I can figure out how to eat less food, or use less resources to get something done, then it is freed up for someone else to improve their lives with.

Being leaner doesn’t mean doing it to improve my standing.  No matter how much money I earn, I will never grow to be taller than trees, bigger than mountains or able to spontaneously fly.  My change in stature from being richer is quite insignificant in the big picture.  Being happy, however, has immense value to me.  And, freeing up the resources that I once consumed means being able to provide them to the less fortunate.  While giving my money (or resources) away, won’t make a rich person happier, it does have value to those living in poverty.  Some amount of wealth building helps those less fortunate meet basic needs.  And being lean means helping bring up the standard of life for all to a level that more people can be happy.

Happier people, not wealthier people, is the goal I want to accomplish.  Vibrant health, a comfortable place to live, enough (not an excess) to eat, and the freedom to enjoy a beautiful day is what LEAN could accomplish.

While I appreciate where Bill is coming from, if the USA weren’t the world leader, the world still wouldn’t end.  If I can continue to be happy, I’m pretty sure that’s what matters, not how much the US dominates the world’s wealth.  After all, you can’t take it with you…

Thoroughly considered or just the way it is?

I can never tell if my educational trips actually change mindsets of the people I bring along with me.  Sometimes I think that although people intuitively get the ideas being presented that it never affects behavior.  It’s like emotional intelligence (EQ).  Sure, you can know what the right answer is, but will you actually behave that way when push comes to shove? 

At any rate, though I wonder about the value I’m providing to people I often learn interesting things about my students.  In some ways, the teacher becoming the student is my favorite part of teaching.  Accepting that I know nothing (or at least very little) is what inspires this blog.  If I thought I knew all the answers, I wouldn’t be mulling them over in my head and writing my ruminations in this blog.

So I return to the scene of a recent trip to 5 Guys Burgers to discuss a student who came along.  This student, is an interesting sort of person.  I find that in some cases he’s really thoughtful and in others he doesn’t want to make the leap from “hey, if it works in a burger joint, could it work in a big company?”  It’s the power to extend a learning to a bigger thing, and I don’t think the inability is unique to him.

The interaction went something like this:

“Bob, see what they’re doing with the fries?  First they take a Styrofoam cup and load it with fries and then they put that in the bag and throw MORE fries on top.  What a waste.  Why do they need the cup?  Or why isn’t the cup the right size?”

And Bob’s response was “well, it’s part of their value proposition.  You get a lot of fries for your money.” 

Now, I’ll grant you that there were a lot of fries in the bottom of my bag, but I’m not sure that’s the issue.  The question in my mind is, did they get this way (of throwing excess fries into the bag) because they thoroughly thought it out or did it get that way by chance.  In effect, they bought cups that were too small and always intended to provide a larger order of fries than the cups could hold.  If they had bigger cups they’d just use them without the tossing of fries in on top.

It reminds me of a commonly told story about a woman who is preparing a roast for her family.  She takes the roast out, cuts off the end of it and discards it.  Her son, who is watching her, asks “mom, why do you cut the end of the roast?”

“Well, that’s what my mother did.”

“Why did your mom do it, ” asks the boy.

“Because that’s what her mother did.”  But it turns out that the only reason the boy’s great-grandmother did that was because her pan was too small to fit the roast.  The rest of tradition handed down is nonsense.  It doesn’t make the food taste better.  It wastes a part of the roast which could be eaten.  It’s not  a deliberately thought out thing, it’s just a thing she does.

And so it goes with french fries.  We find reasons in the things we see every day to believe we’re doing them for a valid reason.  And that we must continue doing those things hereafter because clearly they were well thought out.

It’s a form of superstition.  Just like wearing your team jersey on game day because you believe your team can’t win without it, continuing to do something without questioning why we do it at all is foolish. 

But it is also troubling.  LEAN thinking is a mindset to challenge the way things are done, and yet we find that it is our evolutionary misfortune to see cause where there is none.  To be leaner, you are going to have to fight against your urges.  While superstition may have saved us from being eaten by lions, it no longer serves the same purpose.  We have the luxury to be able to step back, think about the issue and make intelligent change.

The next time you look at something that needs fixing, you should be able to ask yourself “is this a thoroughly considered way of doing things, or just the way it evolved?”

You know it isn’t training if…

Two days ago, while I sat through the first horrid day of “training” I came up with a bunch of thoughts about LEAN that will eventually turn into entries.  I also thought about something else, which was how terrible the training class I was sitting in was.

Not that this is a new idea, but it’s an important example of “Know Your Audience.”  Whenever presenting any material, there must be some consideration made to who you are talking to.  A deeply technical presentation to non-technical folks won’t work.  A high-level gloss over to deeply technical people probably won’t work either.  And last but not least, a rehash of what your audience already knows, whether it is at the right depth or not, won’t work!

So why in god’s name, would this team of 3 people invite 50+ black belts and master black belts into a room and try and talk to them about single piece flow, TAKT time, value stream maps and the 5s’ like we’d never seen them before?  Every person in that room had gotten almost 5 months, maybe more, of training on all this stuff.  Why did they walk us through a 2 hour process simulation that we’ve all already seen?  OK, if they had walked us through the simulation so we could see their proposal on teaching these ideas that’d be one thing, but having us sit through the simulation like we have no clue was insane!

In my mind, training means learning something new.  It isn’t training if the audience already knows the material.  It’s insulting to our intelligence.  It’s certainly a waste of time.

If you are going to “train” someone, you must:

1. Offer new information.  Now, if one attendee already knows the material, that’s not your fault, but the majority of your audience should be getting something new.
2. Offer it at the right level of detail.

If you’re not doing at least that, don’t invite me.  I wouldn’t mind a well put together training, but I’d settle for the two criteria above.

Agile not acting LEAN

This is a continuation of my manifesto against big-A Agile software development.  It stems from a training class I was in today regarding LEAN. 

First off, LEAN… Six Sigma, they’re not that different from each other.  Philosophies for continuous process improvement.  LEAN has a bent towards removing NVA work while Six Sigma has a bent towards quality.  But Six Sigma, at least the Six Sigma I was taught, is capable of addressing both problems of product quality and problems of product performance.  Again, it’s not that I’m saying one is better than the other, they’re similar.

Anyway, I digress.  While I see LEAN and Six Sigma as two sides of the same coin, a lot of people in the class were comparing LEAN and Agile software development in the same manner.

I do take exception with this comparison.  In fact, many of the things that some variant of Agile software development proposes are decidely un-lean.  I figured I’d run down a few I thought of while sitting through that dreadful training.  I guess I owe them a thanks because the training effectively freed up 8 hours for me to think about things and may inspire the next few posts.

1. Teams choose process.  This is a people-empowerment thing.  Potentially there’s nothing wrong with it from a LEAN perspective if you have just one team.  Otherwise, it’s counter to standardizing so that you have a basis from which to improve.  You can’t just change the process each iteration because the team would feel better about it.  If the deviation isn’t better, don’t do it, and if it is better, then every other team must also do it until something better yet is found.  But I don’t get the impression that Agile’s “teams choose the process” attitude came from what would be the most lean thing to do, but instead from what would make the team happiest.  Those two things might have the same end result, but you can’t be sure.
2. Fail Fast.  Decidedly better than “fail slow” which is the argument against Waterfall.  But let’s be honest.  Failing is bad!  Failing results in defects which is which of the 7 wastes people?  Rework.  If you know of a low cost way to avoid failing, say peer review, then do that instead.
3. Refactoring.  Um, duh, this is decidedly rework.  Agile considers this an entirely valid way to design and develop software.  Again, it’s better than band-aids when your design doesn’t pan out, but if a little forethought would have avoided refactoring later, then rework is avoided.
4. Daily Scrum.  Waiting, Over-processing, Motion.  Yuk.  If you have an issue, don’t wait 24 hours to deal with it.  Daily Scrums are too infrequent of a way to raise and solve a blockage.  Projects miss deadlines by losing one day at a time.  Over-processing.  It’s clearly NVA.  Meetings DO NOT tranform the product towards the customer specification.  Especially meetings where you say what you did yesterday, what you are doing today, and the possibly one useful piece of information – what’s blocking you.  And Motion… unless you’re having the meeting where you sit, you are wasting processing time by having everyone gather in some location.
5. Pair Programming.  Duplication of effort, thus overprocessing.  If one person can do it, why would you have two people do it?  I know, there’s some claim that pair programming is a form of inspection on the fly so in some way it might be aligned to fail fast, but again, the assumption that failure is going to happen is a problem in my mind.  Code is a very terse language and doesn’t do a great job at expressing ideas, which is why a lean natural-language specification would, in my mind, be better to write and be reviewed.  The cost of changes on paper is cheaper than the cost of changes in code.  Restructuring poor logic flow - painful.  Restructuring a little logic on paper - easy.
6. Test Driven Development.  Rework, but I already covered that in “We’ve Decided to do it the Wasteful Way.”
7. A Product backlog.  Inventory!  Sorry people, but this is unserved customer demand.  It’s inventory of requests that are not being processed.
8. Iterations.  Waiting.  This is a conversion from single-piece flow to batch flow.  One story in your backlog is waiting for a bunch of other stories so that they can be packaged into a release.  How do we get from here to a constant flow of new features making it to production when they are ready to go?

Look, I know what you’re thinking… “bugs are inevitable so we might as well accept that and figure out how to deal with it.”  I, for one, am unwilling to accept that we should allow failures.  Yes, they happen in my world, but we look for ways to pokayoke the development process so people don’t keep making the same mistakes.  So that people don’t have to appraise the system looking for the same stupid error that people always make.  Patterns of behaviors can be changed at the source.

A simple example.  Most IDEs today, when you start typing a built-in function, and sometimes even one of your own defined functions, immediately provide you with the arguments necessary for that function.  Other IDEs, such as Microsoft’s VBA, check syntax validity as you type each line and warn you right then and there.  Other’s automatically beautify.  When I started programming, they didn’t do diddly.  They weren’t any better than a notepad.

This is errorproofing.  This is dealing with the kinds of things that people do every day that are just dumb, avoidable errors that nobody should wait until a compiler has to run to find out.  And if they can think of these things, then I imagine I can think of enhancements which would errorproof other kinds of errors in the development process.

Will we ever get away from appraisal and rework totally?  I don’t foresee that day anytime soon, but we can be further down the line if we wanted to.  So, yes, while many of the things that big-A Agile has done are leaner than the strictest waterfall, they are still an acceptance, nay, an endorsement, of not lean behaviors.  I object.

Why bother iterating if you don’t have to?

Iterative development make sense because it allows you to deploy functionality more often.  It’s that deployment which represents a switch from a continuous stream of work to a batch process.  Once you deploy the new software, gets downloaded en masse.  For that reason, it makes sense to iterate.  Yes, you get more downloads or updates to your software but it also delivers small chunks of functionality quickly.

But should you always iterate?  This isn’t a post in favor of large batch-style development.  This is actually a post in favor of not iterating at all.  One of the things we are working on is a series of improvements to our Quality Assurance process.  There are several teams and each team is responsible for a set of features within an iteration.

For some insane reason, the manager of the project wants to treat this improvement work like an Agile project.  Not only do they have iterations and sprints but they have iteration planning and releases!  This is dumb.  Any remotely frequent reader knows how I feel about the hippie aspects of Agile anyway.  The reason iterative development is better than batch development is that it allows you to deliver small amounts of functionality quickly but feeds nicely into a distribution/update model which are almost always done in batches.

When we upgrade the software of our customers, we don’t want to serve it like McDonalds where each person gets their order in turn.  We want to blast it out there.  With software we can launch it like tossing a million burgers at the crowd all at once.  That’s certainly true for anything we deploy internally, since you don’t want one customer service rep to have the old software while another has the new software.  Installation is always big-bang.

But process work doesn’t have to be that way.  It doesn’t even make sense to do it that way.  Each process improvement, assuming no dependencies, can be rolled out when it is ready.  Creating iterations and releases artificially adds waiting to the process.  If it is ready to go, then just go.

And I’m sure this applies to any centralized system as well.  Why have monthly installs?  If something is ready, roll it.  Why batch it up to install it at the end of the month?  Those features could be waiting 30 days to get out there.  And don’t tell me that ITIL or ISO demands it.  It’s just plain not LEAN to convert from single piece flow to batch processing when you don’t have to.

It’s true for software development and it’s true for process work.  When it is ready, go!

You’re a 5 out of 10

No, sorry, it isn’t a comment on your physical attractiveness.  It’s actually a comment about an assessment that was recently done at my company.  It was a “LEAN assessment” and apparently it was conducted as follows:

1.  Select about 100 people to talk to.
2. Interview them using a series of questions that have open-ended answers.
3. Review the interview with a couple of your peers and decide how their answers rate compared to benchmark answers.
4. Reduce their detailed resposne into a 1 to 5 score.
5. Average all the scores and spit out a number.
6. Call this your LEAN maturity rating.

Where to begin?  Well, we can start with the methodology.  I have nothing against interviewing.  I have nothing against talking to a lot of people.  I do have an issue with an arbitrary translation of a free form answer into a score.

It’s a relatively unscientific process.  It is being conducted by an individual who may have biases.  In fact, we can be certain they have biases.  After all, if our organization was a 5 (on a scale of 1-5) already, then what job would the interviewer have?  They’re somewhat inclined to downplay any positive aspects.  After all, they want to improve our scores on a LEAN assessment.

Two, where’d the benchmark answers come from?  How do you know if the answer your interviewee gave is equal to, better or worse than the benchmark.  How come you didn’t just ask the interviewee for a rating of 1-5 on the various aspects?  I don’t fault anyone for wanting to get additional information for the score, but interpreting someone’s language to arrive at a score?  I don’t think I’d do that.

And finally, even if you can arrive at a score, who cares?  You’re a 6, he’s a 4, that guy is a 9.  Scores, regardless of how high or how low they are don’t make our customers happy or sad.  A good score, in theory, has some relation to something that our customer cares about.  So where’s that data?

Well, I asked for all the data that the team used to “score” the group and they didn’t have it.  Look, I don’t care if you score a one bajillion out of 10 on the rating system.  If the rating system doesn’t relate to an actual goal, who cares!?!?  Score me any way you like, because unless it holds some predictive value, it doesn’t matter.

• The questions may be irrelevant.  Even if you answer the question correctly there’s no evidence that it results in greater profits, customer satisfaction etc.
• The questions may be relevant but don’t represent real behaviors.  This is the oft stated problem with tests of emotional intelligence.  You might know what the right answer is, but you don’t necessarily behave that way in real life.

So instead of this nonsense of scoring people’s answers, how about you go to the gemba, watch people work, and draw your own conclusion about where we stand on the LEAN maturity scale you made up.  I’d like to offer, in return, a grade on this assessment – 0 of 10.  Inherently flawed.