Finding the right unit of work

Size matters.  No I’m not making an off-color joke, but I did get your attention.  One thing that seems to get lost on people is the idea of opportunity for a defect.  For example, my computer crashed today.  My wife’s computer did not.  Is my computer unreliable?  Not necessarily.  Yes, my computer did crash once, but due to my job, I also use my computer almost 12 hours a day (let’s ignore the fact that I probably work too much).  My wife, by comparison, just checks her email for a few minutes, let’s say 30 minutes at most.

In any given day, I use my computer 720 minutes, my wife uses hers 30 minutes.  Because I use my computer more than she does there is a lot more chance that my computer will crash.  If your computer is off, you can’t crash it.

When we talk about improving processes, we discuss the problems in terms of defects per million opportunities (DPMO).  DPMO is useful because it allows you to compare disparate volumes.  If I make a million widgets and have 2 defects and you make 100 widgets have have 2 defects, who’s worse?  We both had 2 defects.  By having common denominator, you can tell.  One could assume that if you had made a million instead of a hundred widgets that you’d have about 20,000 defects.  Now we’re talking apples to apples.  My 2 defects per million or your 20,000 defects per million.

In most types of process work, the unit of opportunity is obvious.  It might be defects per order filled, or defects per transaction processed.  Software, well, that isn’t so pretty.  What exactly is an opportunity to create a defect when it comes to code?

In fact, I had an experience over the past few days that brought up this exact issue.  I was asked “are we getting better at delivering this software?”  In other words, are we getting fewer defects in production?

First off, in terms of pure defect counts we seemed to be getting worse.  There were simply more defects over the past few months than we had ever had before.  Oh, the sky was falling, I tell you!  More defects!?!?  The world was ending!  Ah, not so fast, I argued.  What if there were more opportunities to have a defect recently?   Maybe things were getting better, or at least not getting worse.

Of course, if you’re the person who is on the receiving end of being told that your software development process is a problem, you’re pretty ready to listen to someone who tells you that it might not be as bad as it seems.  So, they said, let’s look at defects per transaction.  We ended up with a control chart that looked something like this:

To me, looking at this chart, there are two populations.  There’s a population hovering around the lower control limit (LCL) and then a second population around the upper control limit (UCL).  Between observation 8 and 9, something appears to have changed, even though nothing is different about the process we thought.  What it seems to me is that defects per transaction caused the data to be segregated into two populations.  Since the process was believed to be stable, this seemed odd.

I decided perhaps a different denominator would be appropriate.  Maybe a transaction wasn’t the right measure of an opportunity for a defect.  This seems to make sense, since software is one of the most repeatable processes we have.  It’s digital, after all.  Given the same inputs, absent any funny memory leaks, the same input to code should generate the exact same output.  Therefore running more transactions is unlikely to yield more code defects.

Instead, I proposed we look at defects per hour of coding effort.  Yes, like lines of code, function points and any other measure you can think of, there are problems with “hour of coding effort” as a measure of opportunity.  Fear not, I’m just using it to illustrate a point.  When I created the control chart using that denominator, I got this:

Ah ha!  A process that appears to be in statistical control if I look at defects per hour of effort.  Now, for my unhappy manager who was being yelled at about the code quality, this wasn’t the best story in the world.  I saw no evidence of “good” special cause variation.  They didn’t appear to be getting better at delivering software, but they didn’t appear to be getting worse either.  Crisis averted!

Here’s my proposal.  If you don’t know what the correct unit of work is for the denominator, simply throw out a few ideas.  Then, create control charts using each as the denominator.  If using that denominator doesn’t bring what is supposed to be a stable process under control, it’s probably the wrong choice.  In my example above, we discarded defects per transaction because it seemed to create two populations we didn’t expect.  And instead, we went with defects per hour of coding because it did stabilize the process.  Now, I’m not suggesting you should allow your own bias to find some complicated way of showing there is or isn’t variation, make your denominator something simple to count.  And it’s likely that more than one denominator would probably work.  In my case, not only would hours of effort worked, but number of lines of code changed, function points created or even requirements filled would probably have had the same effect.  The point is to find a good, not necessarily perfect, denominator to normalize for the amount of work being done.

Now, when we go to change the process, you’ll have some way of knowing whether we’re getting better or not, even if we do more or less work.

Agile, day, uh… well…

Not that long ago I wrote “Agile, Day 1” which was my personal introduction to what being on an Agile software team might be like.  I wasn’t impressed, and I get this funny impression that nobody else, including the boss was either. 

Why do I say that?  Well, other than a brief hour long exercise a couple days later to try and finally get our stories prioritized, nothing has happened on the topic since then.  I, of course, hesitate to bring it up since I really was not a fan of it in the first place.

I’d like to say I wonder what happened, but I have some inkling.  See, not long after Day 1, Bob went to an offsite to hear all about Agile at big companies.  The presenters, Bob tells me in a later phone conversation, explain that as a professional services company they have discovered that Agile doesn’t actually work all that well.  In fact, they themselves have given up on it and use a hybrid approach, something that’s neither really Agile nor strict waterfall.  Having not seen it, but liking to claim victory for my position all along, I’d call it LEAN software development.

In fact, this company went on to say that they’ve had clients who like more documentation or more rigid process.  As the vendor, this company provided services that met their client’s view of how projects should be run.  So, I’m wondering, if they could do pretty much whatever process the client liked and still found the project to be profitable, I’m guessing their original adherence to Agile wasn’t the key difference in their company’s success.

Anyway, I think this all disheartened Bob, who was so convinced that Agile would be the future (by the way, Barry Boehm has long since presented that the Agile fad is over and companies should move to a hybrid approach) that he just couldn’t bear returning to the team and having to share this news with us.  Ok, an unlikely story. 

The sadder, and probably closer to true, story is that Bob probably doesn’t actually care all that much about the process.  OK, listen to what I’m saying… Bob, my boss, the boss of a group of process people, the person who is responsible for an entire organization’s process work, doesn’t have the time to figure out his own team’s process for getting work done!  Hello?  To quote the movie Zoolander, “I feel like I’m taking crazy pills!”

I hate to say it, but Six Sigma or any other process discipline you may like cannot be above the law so to speak.  We are not special!  We are not different than any other disciplined, scientific approach to dealing with a problem.  And yet, if your boss can’t be bothered to enforce a process just mere days ago he believed (for right or wrong, let’s just assume Bob had good reason to believe Agile was worthwhile) would have a significant impact on our productivity, I think that might pretty much sum up the problem.  Of all people who should be striving and obsessed with continuous, measurable improvement, we should be.

Boston Market fails to select the right CTQ

Today I went to Boston Market for lunch.  Well, I tried to go to Boston Market, but I gave up.  Actually, on the times I succeed on going I like their food compared to most other fast food garbage choices I have.  Don’t get me wrong, I’ll still eat fast food.  In fact, I resigned myself to McDonalds, which I wasn’t really in the mood for, but it’s right nearby.

See, I stepped into Boston Market, fairly hungry, but not so desperate as to have chosen the company cafeteria for lunch.  Yes, I know it’d be far more economical to either eat at the cafeteria or to bring my lunch, but I like my lunch break to be outside the office.  It’s basically non negotiable for me.

There was a line, like there is most days.  Boston Market employs a single queue service line, which is different from McDonalds.  McDonalds, and most fast food places, use multiple lines and you can choose the fastest line.  Also different is Boston Market uses a batch queue for food service while McDonald’s is more of a single piece flow.  See, when you go into McDonald’s, primarily the person behind the register takes and fills your order.  They complete the entire transaction, from taking your order to getting the food onto your tray.  Behind the scenes they have a bit of a batch processing too, pumping out a few hamburgers, cheeseburgers, etc, but not many more than they can readily use.  It’s sort of an interesting hybrid.

By comparison, Boston Market is entirely batch based.  The person takes your order and places your selections of sides onto the plate.  They then hand that tray off to the carver, a single guy who is responsible for carving and placing the choice of main dish onto your plate.  He then queues up filled plates which are picked up by the cashier who asks you if you want a drink with that and totals your order.

And of course, with this batch process, there’s lots of hand-offs compared to the McDonald’s model where there are essentially none.  Add to that the confusion that each order is communicated verbally and the carver has to remember what goes on each plate, leading to some out of order fulfillment and some extra communication back and forth on what was needed where.

On most days, though woefully inefficient, it doesn’t matter all that much to me.  Because volumes are relatively low, even a minor backup at the carving station doesn’t foul up the works (pardon the chicken pun).  But today was different.  See, someone had come in with a large order – maybe 8 or 10 different entrees all with the necessary sides.  I admit, I came in after this chaos had started, so I can only imagine how long some of the people in front of me had been waiting.

Batch processing seems to make sense, since the carver only has one job – carve up chickens.  But in fact, all his work is not the same, since some people want a half chicken and others want a 1/4 dark and other a 1/4 light meat.  The order taker/side dish person is pretty efficient, but that creates a queue in front of the carver.  Of course, with 8 to 10 different things to remember all at once, the carver gets confused with what plate gets what.  And suddenly nobody’s order is getting filled.  See, once the carver couldn’t handle the volume, the order taker ground to a halt.  There was no more place on the carving station to put more plates, so the line of customers began to build.  At least, there were no more places that wouldn’t result in precariously perched (pardon the chicken pun again) plates.  The cashier was also at a standstill.  Since the carver was confused as to what went on which plate, no orders were getting completed.

I watched in frustration for about 5 minutes from the place where I had been standing ever since I walked in the door.  I hadn’t moved a step, not one, because the queue was not moving.  And the customer queue wasn’t moving because the carving queue wasn’t moving and the whole thing shut down.

I didn’t actually leave the restaurant because of their queue failure directly.  I mean, actually, it makes good fodder for my blog.  I left because I lost patience with standing in one place and was unwilling to wait 5 minutes and make no progress. 

See, the batch queuing might be better if the carver could remember the orders, but it probably would still be unacceptable.  I doubt Boston Market actually has a measurement system for their restaurant delivery process, but if they did, I suspect their big performance measure would be something like order completion time.  In my mind, this would be something like the time from when the customer’s order is taken until when the customer departs the register.  This would be an OK measurement, but isn’t actually aligned with my customer experience.

My satisfaction is measured from the amount of time I get in line until I reach the register.  Specifically, I’ll leave the queue if I don’t perceive the queue is moving.  I actually don’t mind if it’s 5 or 7 or maybe even 10 minutes to wait, but I want to make progress.  Having seen a total standstill, I assumed my wait would be too long and therefore I got out of line.  In fact, they might have cleared that customer’s big order in just a minute or two more, but in the meantime I had already given up because I was still waiting.

Believe it or not, this is a well known problem at retail establishments.  The single queue for customers is in theory actually faster since it serves everyone equally.  There’s no more guessing about which is the right line to get into.  In fact, the multiple queues at McDonald’s annoy me because I find myself gauging which line I think will be best.  I’m always on the lookout for old people or the mom’s club who came with 10 children in tow.  They are a disaster for the line you are standing in.  So, up to the point where you reach the front of the customer queue, a single queue is best.  Beyond that, your actual servicing should be multiple queues.  Now that I’m being served, I want to be taken care of.  And if I’m the customer behind you, I don’t want to wait around for your huge order just so that I can give mine.

Could you imagine being at Best Buy around Christmas (well, maybe not this Christmas what with the dismal sales forecasts) and having your cashier go help another cashier get someone else’s order complete rather than checking you out?  That’s essentially what’s happening at Boston Market.  Everyone focuses on getting that first customer complete before going onto another.  And frankly, that just makes me impatient.

What’s the takeaway?  Well, if you’re a Boston Market executive vice president reading this, hopefully you’ll change your process to have each order taker completely fulfill the order of just one customer instead of having these crazy queues.  Yes, that means each order taker puts on the side dishes, carves the necessary chicken, adds the cornbread (it’s not that good, maybe you could keep it warm and serve it with butter as well), and then maybe hands off a completed order to the cashier.  It’d probably be better if the cashier just did it all.  I’d be most appreciative if you could fix that.

If you’re anyone else, the takeaway is, if your factory (whatever you’re producing) interfaces directly with customers, a single piece flow might be more than just a good manufacturing idea.  It might feed directly into what satisfies your customers – a sense of progress.

“If only we had more time…”

Ah yes, the “if only’s” have come to call.  One problem with having so many people working on process improvements is that I have to sit through innumerable meetings listening to people and their ideas on how to solve the problem they have.

Of course, most of this stems from a bad understanding of process work, and this particular instance was no different.  Bob (yes, I’m going to continue to use Bob as my generic name) was talking about his work in improving the quality assurance testing activities.  And from his mouth came this nonsense: “If only we had more time, we could test everything that needs to be tested.”

Great… Let me translate that:  “if I had unlimited resources and time, I could test this system so thoroughly that it’d be suitable to fly the space shuttle.”  Here’s the problem.  You DON’T have unlimited time or resources!  You customers won’t be happy if you test the system so thoroughly that you never deliver it!  Yes, while the department name “quality assurance” hints at the idea that quality may be a key part of their responsibility, it is definitely NOT the only need from that organization.

Typically, we look at three aspects of a process’ performance:  cost, quality and speed.  This is a maximization opportunity.  People view quality as a counterbalance to cost and speed.  Getting quality means spending more money and/or more time. 

First off, that’s wrong!  If the only way to get better quality stuff was through exorbitant expense, Toyota would be out of business.  Instead, they’re a market leader, providing cars that a) cost a reasonable amount of money, b) beat their competitors in quality, and c) people actually want to buy!

Are Toyota’s cars invincible?  No.  Do they require maintenance and even break down?  Yes.  But that’s the point.  There’s a balance between multiple needs for their customers.  It isn’t just a good quality car, it’s a good quality AND reasonably priced car!

Our friend Bob was taking the one CTQ view of the world – quality!  It’s all about the quality!  Reality is, it isn’t all about the quality.  People won’t pay limitless amounts of money for the quality.  If Bob actually understood what his customer’s needs on quality were, he could be striving towards that goal, and not the ridiculous goal of perfect quality.  And then Bob should also bother to understand what other goals his customer’s have – like how much are they willing to pay for that quality.  Then, and only then, solve for both issues at once.

If you focus on just one goal, your other goals, which may be as important if not more, suffer.  So, Bob, if only you spent more time to actually think about your customer’s needs then you’d know that just asking for more time wasn’t going to make your customer happy.

A measurement system failure

There’s a reason why you ought to do a measurement system analysis before you take measurements.  For example, I didn’t sleep a wink last night due to my measurement system and how badly it had screwed me up.

My home energy usage has been a favorite target of mine for optimizing.  Why?  No, it’s not because I’m particularly environmentally conscious.  Yes, I recycle everything that’s recyclable.  I’m certainly not the worst offender out there, but I’m no Ed Bagely Jr. either.  However, with the rapidly rising oil prices over the past year (despite the sudden decline), I decided it was worth investing in my furnace.  I had a new tekmar 260 boiler control and indirect fired water heater installed over the summer.  Based on my calculations, the expense has between a 2-4 year ROI.  And there’s some feel good value from burning less oil.

All summer I waited, giddily practically, to see how the new system would perform once the heating season came.  Then, late September came and I finally was about to get to see the benefits of the change.  I’d been waiting for some time to pass so I could go down to my basement and get the first rough reading of my oil use, which I tried to do yesterday.

That’s where the problem with my measurement system started.  I don’t think there are many people out there who are as obsessive as I am about data.  Certainly, most people just want to know approximately how much oil is left in their oil tank.  As a result, most oil tank gauges, including mine, are pretty basic.  It’s essentially a float and a little empty-1/4-1/2-3/4-full scale inside a 3 inch high cylinder.  There’s nothing high tech about it.

Based on my data, I figured I should have about 3/4 of a tank of oil left.  Imagine my surprise, and then pure panic, when I went down to the basement to look and saw I had a meager one quarter of a tank of oil left!!!  I had just had 139 gallons added to the tank on September 3rd and just 266 degree days had elapsed since then.  According to my calculations (yes, I have a regression formula for my oil use), I should have used just about 46 gallons of oil (about 20% of my tank)!  Was there an oil leak?  I didn’t smell oil.  I didn’t see any patch of oil around the furnace or the tank, so that couldn’t be it.

Somehow I’d used almost 170 gallons of oil in just a month and a half!  And thus, I didn’t sleep a wink.  The last time I bought oil, it was $4.04 a gallon.  I’m sure it’s gone down by now, but that’s almost $700 in oil!!!  I really don’t want to spend $700 on nothing.  Immediately, I reacted to what’s changed.  My new furnace equipment!  It must be wasting lots of oil.  I’m have a full fledged fit now, tossing and turning in bed, running over and over in my head how I’m going to get the installer of my equipment to pay for their screw up.  How dare they sell me equipment that made my oil use four times WORSE than what it was without the new equipment.  I started to wonder if I knew a good lawyer.

A note to myself, and anyone else who’s obsessive like I am, don’t gather data that might make you unhappy if you can’t do anything about it until the morning.  In the morning I phoned the furnace company.  I explained to them my observations and asked if they’d send someone out.  They said they’d never heard of anything like that and would call me back.  I spend the morning pacing, calling back at 10am for an update.

They tell me that they’ve run the numbers and they don’t see any way my furnace could have burned that much oil in that time.  I feel a little better, but not much.  My oil gauge still says my tank is mostly empty.  I go back down to the basement.  I tap on the sides of the tank trying to listen for the change in tone where the oil level would be.  It sounds hollow to me, an unsettling sign.  I wonder if the gauge is working.  I tap on the gauge, but it doesn’t budge.  I start looking on-line for other ways to measure my oil use.

I call the furnace company back and ask them if there’s a way I can check if the gauge is working.  They tell me that they don’t know of a way, but suggest I call my oil delivery company and see if they have any ideas.  So I call them.  The guy there tells me the gauge I described can be unscrewed and a thin measuring tape can be slid in the hole to measure the depth of the oil.  Heartened that I now have something to do besides sit on my hands, I head back down to the basement with the tape measure in hand.

Upon reaching the oil tank I unscrew the clear plastic tube that the float gauge sits in.  And no sooner than I have loosened it two or three turns, the float gauge bobs up.  Ack!  There’s nothing wrong at all, except that the float gauge was stuck inside the plastic tube and so couldn’t move.  I’m half relieved and half embarrassed that I’d called all these people for help and there was nothing wrong at all. 

Still, I finish unscrewing the gauge and then press down on the float a couple times to make sure it comes back up like it should.  Sure enough, it does.  When I put the plastic top back on, it now reads 3/4 full.  I call both companies back, apologize for the inconvenience and thank them for helping me out.

So a simple mechanical failure (friction of the float on the gauge) and my own hyper focus on this measurement led to a miserable night and day for me and two very confused companies who couldn’t figure out how I’d burned that much oil in a month and a half.  In retrospect, thank god I had not had people out for a service call to look at the problem.  I would have been paying $65 or more an hour to have nothing wrong.

And that’s where my story collides with process improvement.  Simple float gauges aren’t that accurate in the first place.  The tank isn’t square (it’s more like an oval), so the gauge doesn’t accurately measure the contents of the tank anyway.  A linear measurement doesn’t take into account that the first 1/4 of the tank in height holds substantially less oil than the 2nd and 3rd quarters.  Secondly, my measurement system failed anyway.  Being ridiculously simple, the gauge simply got stuck rubbing the inside of the plastic tube.  If I’d just checked my measurement system the night before (and I suppose it would’ve helped if I knew that plastic tube unscrewed), I would’ve slept soundly and had a good day.

I’m feeling much better now, but doesn’t it make you wonder how often your measurement system had led you to take corrective actions when there were none to be taken?  I’m not saying you can’t have some measurement system noise.  After all, I would’ve been happy with any measurement between 3/4 full or more.  I just had a rough idea of where the gauge should be.  But when the noise outweighs the signal, like the noise of a stuck gauge no longer measures the oil in the tank, you can’t make decisions on it anymore.  Well, you can make decisions – like to toss and turn and fret over the data and make unnecessary phone calls and potentially pay hefty fees for nothing at all.  I’d just suggest learning from my mistake.  Check your measurement system.

If you can do it, they don’t need it

So I was sitting through this meeting today because one of my peer black belts had been asked to do something about a problem.  The issue was that a development team was producing (in the customer’s estimation) too many bugs.  So, the customer said “we want you to shore up the testing process so the bugs don’t get into production.”

What!?!?  The customer went on to admit that they realized it would be better to address the root cause of why the issues were being created, but they didn’t want to spend the effort on that, so instead they just wanted to have more testing done.  So, the sponsor instructed my peer to create a new process to add more regression tests.  Of course, what my peer should have done is quit the project.

Not that we ever do that, unfortunately.  People forget that solving a problem doesn’t necessarily mean doing as they ask.  My wife said to me the other day “I need you to watch [our daughter] for an hour or two, can you take off work?”  Don’t get me wrong, my response was “yes, dear” but the point is, my wife didn’t actually need me to watch our daughter.  Her real need (go with me on this one), was to be in two places at once – at home, watching our little one, and at the doctors.  The point is, there was more than one way to solve her problem if I really wanted to get into it.  We could’ve gotten a babysitter, she could have taken our daughter with her, she could have rescheduled the appointment, or I’m sure I could make up other things.  She simply had a need to resolve a conflict and the easiest way was to tell me what to do.  And I did it.

But at work, this isn’t a good solution.  Unlike my everyday example, work problems are rarely so basic.  They’re dangerously intertwined, and solving one problem, like the quality of the development team via extra testing may just create another problem.  In this case, the addition of an enormous amount of non-value-add activity that going to cost the company a small fortune and yield few results!

Alas, we do as we’re told, because it can be hard to distinguish between a real need and a solution.  Sure, more testing sounds like a need if someone says to you “I need you to add additional regression testing to the development process.”  It even has the key word – NEED – in the message.  Clearly, this must be a need, right?  Wrong!

The common way to figure out what the real need may be is to ask the question “why?”  It goes like this:

“I need you to add additional regression testing to the development process.”

“Why?” you ask.

“Because shoring up the testing process needs to be done.”

“Why?” you repeat.  The person you are talking to is starting to get red in the face.

“Because we have too many defects, and we need those defects to not get into production.  And if you ask me why again, you’re fired!”

Honestly, I’d be mad too.  I’m sure when my little one gets old enough to incessantly ask “why,” it’ll drive me nuts as well.  For now, I’m safe.  In the meantime, I think there’s a better test for whether you have a real need or a solution.  If you can do it, it’s a solution.

For example, I can “watch my daughter.”  I know how to do that.  No seriously, I do.  My daughter and I have a good time together, and aside from the instance where I dressed her in a purple shirt and rainbow striped pants, I’ve made few mistakes.  And hey, let’s be honest, the pants had red, orange, yellow, green and blue stripes already in them, so a purple shirt clearly made sense to complete the rainbow.  Not so, says my wife.  I’m still arguing my case.

You can “add more regression testing.”  That’s pretty actionable as well.  However, you can’t “make fewer defects” in some straightforward way.  It’s not directly doable.  Instead, you have to do related things that might end up with that result, like improve the analysis and design phase, or elicit better requirements or even be more effective at testing.  Those are all things you do to make a difference in the thing you can’t directly control.

If someone is asking you to do something and you can say “yes, I can do that” and can go back to your desk and either do it right then and there or at least lay out the plan on how to accomplish it, you don’t have your customer’s need.  You have your customer’s action items, and as I’ve said before, if your customer had been choosing the right things to do in the first place, they wouldn’t be needing your input.

Agile, Day 1

Well, I’ve been subjected to my worst of nightmares – having to work on an Agile project.  OK, I should be fair, while I have argued against Agile it isn’t because I think Agile is particularly bad, I just don’t think it’s particularly different.  I’m sure Agile works fine, but it annoys me that those who support the philosophy can see no other way

Anyway, our team’s boss (Bob, hereafter), decided to start us on Agile.  First off, we aren’t a development shop.  The only person who does any development is me.  And I only do it because I need to write queries and scripts to collect measurement data.  Coding isn’t my job, it’s just a means to an end for me.

We begin the day with our first error – we write our own stories.  Stories should be written by the customer.  Why, you ask?  Because you don’t want the developers (oh wait, we aren’t developers) to impose their world view of the solution on the need.  Stories are just like requirements otherwise, except they’re called stories.  The use of natural language is more imprecise, so I guess you could call them high-level requirements.  Call them whatever, customers write requirements, because customers know what they need.

Why are we writing our own stories, you ask?  Well, it really stems from a prior issue, which is we have several customers, none of which have expressed interest in us doing our work in an Agile fashion.  Therefore, we’re acting as a proxy for the customer, and probably not doing that good a job.

That becomes evident when we try to prioritize our stories for our first iteration.  Since we have many customers, none of whom are present, we have to argue amongst ourselves which is more important.  Of course, even if we had customers, we’d have the same issue, because customers are terrible at prioritizing.  I can’t recall how many times I’ve had a backlog of issues for a product and asked the user to prioritize them so we know what order to fix them in.  They just label them all high priority.  So then I ask for force ranking, and of course they tell me they can’t do that.  So I’m not particularly surprised that we can’t prioritize them either.

Anyway, we’re told to write tasks for the stories.  I submit one task per story, since that’s what I know so far.  I ask “how granular does a task need to be?  Is a task ‘figure this out’ or is a task ’set up a meeting with Joe’?”  I’m told tasks can be as granular as I like them to be as long as I can estimate them.  I stick with the ‘figure this out’ level of tasks, since I don’t manage my time in terms of checking off lists of things to do.  While other people are talking, I review the deck one of the scrum masters has given about estimating.  The recommendation is clearly a form of wide-band delphi, wherein several people estimate the task and attempt to converge on an agreed upon result.  The ideas seem ok for a development team, but I wonder about our tasks, since my tasks involve coding and nobody else is a programmer.  Who is going to estimate my tasks besides me?

Having done not so admirably at that, even with 2 scrum masters there to advise us, we turn to protocol.  Specifically, the daily scrum.  We’re a distributed team, so someone is going to have to call in to the daily scrum sometime.  We debate whether we should have all in-person (not possible), all on the phone, or a mix of phone and in person.  We decide that the mix of phone and in person would marginalize people on the phone, but since the scrum is supposed to be just 3 questions – what’d you do yesterday, what are you doing today, do you have any obstacles – that there’s really no need to do it all on the phone to level the playing field.  I ask “what do you do if someone brings up an obstacle” to which one of the scrum masters replies “take it offline.”  Bob gets upset and says “you mean I can’t ask questions?”

“No, the scrum is just for people to answer those three questions.  If there are issues to be dealt with, they should be done outside the meeting.”  Bob frowns.

“So, then the scrum is a peer pressure thing, ” I ask.

“No, it’s meant to share status.  Everyone’s responsible for the team’s success, so if you aren’t getting something done the team would have to pick up the slack, ” replies the scrum master.

“So, it’s a peer pressure thing, ” I ask again.

“Yes, ” he admits.

“Couldn’t we just send a daily email, ” I ask.  After all, I can either listen to a group of people talk at me or I can get the same information by reading a bunch of short emails.  Seems like it’d be about the same to me.

“No, it’s inefficient to read a bunch of emails,” the scrum master tells me.  That seems odd to me, since emails can be sent asynchronously and on a phone call we all have to sit around while another person talks.  I’m pretty sure I could get through a handful of emails in less than 15 minutes.  I do it every day.  I’m pretty sure this is part of the hippie commune mentality… we need to talk and be a team, and hug, and get to love each other.

OK, now that we have that settled, Bob says “well, maybe I need to have multiple scrums each day with each of the work streams.”  I don’t think Bob gets it.  Bob wants a daily status meeting, not a brief peer-pressure meeting.  I hate meetings either way, so the idea of meeting daily with my boss or the whole team sounds unpleasant.

By the end of the iteration planning meeting, I’m feeling pretty unimpressed.  I’d summarize as follows:

1. Stories are high-level requirements and will require more requirements in order to make them come true.  Except since the requirements aren’t written down, it’ll be a bit like prototyping or JAD, both of which are totally acceptable methods of iterative development.  Acceptable, but not new or different.  Couldn’t you guys just call them one of the accepted names like “requirements” or “scenarios”?  I can’t wait until I get to go to a ‘reflection session’… hippies… it’s called a post-mortem.  Renaming stuff doesn’t make it better or different.
2. Scrum meetings are for peer pressure.  On the plus side, they’re not status meetings.  On the minus side I now get both scrums and status meetings since Bob wants status meetings too.  I’m reminded that I got a “needs improvement” in grade school on the “plays well with others.”

I admit, I’m coming in cynical, but putting lipstick on a pig doesn’t make me want to take it out on a date.

Agile for the incompetent?

Barry Boehm laid out a series of factors by which one should decide whether Agile software development is appropriate or not.  One of those factors was experienced developers vs. inexperienced developers.  Given the somewhat free flowing nature of Agile, having experienced developers makes sense.

However, at one time folks were trying to sell Agile as the method of doing software development to our business customers.  The comment about using experienced developers came up as a key point of the agile-or-no-agile decision.  And one of our astute members of the business team pointed out that pretty much any process would work better if you had experienced resources.  Touche’.

For the most part, the rise and fall of Agile at the company I am at has been a quick peak.  The business has dismissed it as nonsense (which in my opinion it mostly is), and without their buy-in, it is effectively dead.  And yet, it crops up again here and there.  And with it the ‘experienced developer’ constraint rears its head yet again.

One conversation I overheard about it was essentially “the great thing about Agile is that it exposes who isn’t getting their work done immediately in the daily scrums.”  And for some reason, the whole “use experienced developers” suddenly made sense.  On the business side of things, figuring out who isn’t contributing and doing it quick is a good thing.  On the people side of things, going to Agile might be a management nightmare.

If you have experienced developers and something isn’t getting done, it is probably due to lack of effort instead of lack of capability.  Now, on one hand it’s a good thing to encourage a sense of urgency to get work done.  After all, if you want to deliver anything to the customer, things have to get complete.  On the other hand, I can totally see myself showing up to a daily scrum and saying “yesterday, I did nothing, I wasn’t in the mood.”  How would that go over?  I digress…

If you have inexperienced developers, however, capability might be an issue.  And frankly, I’m thinking that exposing a person’s capability issues in a public forum on a daily basis might be in extremely poor taste at best.  At worst, you could get yourself into serious HR trouble for singling someone out for public humiliation.  People deserve a fair opportunity to improve their performance and get the attention and training they need.  And if they suddenly stop showing up for scrums because they’re on an action plan and can’t get things done, I’m thinking it’s going to be more out in the open than is appropriate.

While Boehm suggested experienced team members might be better for Agile, I’m starting to think it might not be optional at all.  While I believe in the relentless pursuit of perfection in process, and that may mean helping someone who can’t do the job find something they’re good at, the path to get them out cannot be a public gauntlet.  It’s a strike against scrum, for sure.

“You get what you pay for”

I work from home from time to time.  Mostly I choose days that I can keep to myself and do things with data or charts or presentations or whatever works well when I’m alone.  But it isn’t uncommon for me to have to call into a meeting or two while I’m at home.  No day ever goes undisturbed.

Being obsessed with data about my own life (see my post on my oil company), I do what I can to optimize my spending on just about everything.  One thing we decided to do was switch to Vonage for our phone service.  I’m not going to rave about Vonage’s service.  It’s quirky, but mostly reliable.

I pay about half what I used to pay for Verizon, maybe a little less.  Verizon was pretty much 100% available, while Vonage isn’t.  I’d say it’s 75-80% available.  It’s common that the connection isn’t that good and I have to call back or that if I’m using my computer to download or upload at the same time that the connection breaks up.  But most odd of all, and I don’t know why, Vonage and my company’s conference bridge don’t seem to get along.  I break up worse than anywhere else on conference bridges.

First off, a little diagnostics, in case you came here looking for it.  The key to Vonage not dropping my incoming calls is to make sure the Vonage box is in the demilitarized zone of my router.  That stops my router from treating calls like denial of service attacks and solves most of the problems I’ve had.  In fact, you probably can’t blame Vonage directly for the poor service.  It’s a combination of Vonage and my internet service provider.

Anyway, point is, I was on a conference call and my connection started breaking up, so I mentioned that I use Vonage and someone said “well, you get what you pay for.”  Fair enough, in the case of Vonage, that’s true.  The service isn’t that great all the time and the trade off is I don’t pay as much for an inferior product.

Does it really have to be this way!?!?!  “You get what you pay for” suggests what should not be a universal truth.  Low cost does NOT have to equal low quality.  In fact, it’s the ultimate paradox that every company should be seeking to solve.  In many industries, it’s hard to pick out the better competitor because all things are not equal.  Is Windows Vista inferior to Mac OS?  Hard to say.  It’s a monopolistic oligopoly.  Products are very different but serve the same niche – home computing.  Vista runs on a vast array of low cost hardware, but is kind of ugly.  Mac OS, very pretty, only one choice when it comes to hardware.  There are trade offs.

Phone service, not so much.  I make and receive phone calls, have caller id, call waiting and voice mail.  If the services work, I’m happy.  If they don’t, I’m not.  Vonage attempts to make up for their lack of service with some other features – Simulring (ring my home phone and cell phone at the same time), and call forwarding (call my cell phone if my home phone is down).  Nice, but honestly, I just want to get phone calls that work.

Phone service, most of my power tools, my watch, my clothes (you didn’t think I was fashion conscious, did you?), most groceries (I’m not brand loyal), in fact, most of what I consume - perfect competition in my mind.  Everyone makes the same thing, every competitor has the same set of features.  I want to pay the lowest price for the highest quality.  I want a product or service where “you get what you pay for” isn’t applicable.  The processes I work on strive for the same thing.

If the only way for you to get high quality is exorbitant expense, you’ve missed the point.  You can’t focus on just one characteristic of your customer’s needs, like quality.  The miracle is not improving quality at any expense, it’s improving quality AND cutting cost.  Strive to do what everyone says is impossible and change “you get what you pay for” into “you paid how little to get that!?!?”