…it would be funny (Lost the Dilbert strip during the move, sorry – 01/31/2009 CEN).

In many big companies, the people who are allowed to bring about change are people who have titles like Director, VP, CIO, CMMI auditor, Black Belt – you get the idea.  One of the things that is so exciting about the Agile software development movement is it turns this idea on its head – it asks the people who are doing the work, how they want to change things. The last of the 12 Principles behind the Agile Manifesto, speaks specifically to improvement.

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

This is an application of the Lean concepts of continuous improvement (kaizen) and relentlessly eliminating muda, mura and muri on the short time scales of Agile.  Each iteration, we ask the people participating in the process on how to make things better and then implement the suggestions.  Management (and other outsiders) need to avoid the temptation of telling the teams how to fix things and just genchi genbutsu.  The people doing the work know what needs to be changed, all we need to do is listen to what they have to say.

Just wanted to wish everyone peace, glad tiddings, good times with family and friends.

I also wanted to share one of my favorite (and best) Christmas spoofs out there - Futurama’s Xmas.  How can you go wrong with an evil Santa who delivers retribution instead of toys?

When the random number generator reaches zero (23…45…86…3…167…9…51…0), Bender’s execution will commence – now that is funny.

This movie shows everything that is wrong with Hollywood – I think the only people who would be pleased with this movie would be 15-year-old teenage boys.  They so ripped off Supernatural, all the way down to the creaking sound of the dog opening – so lame!  Oh, Corey Feldman, how low have you gone?  Everytime this guy was on screen I was LMAO.

Majel Barrett-Roddenberry died today after sucumbing to lukeima.  She was 76.  Star Trek was one of the first sci-fi shows I got into when I was a kid (the stories from the original series follow many of the classic sci-fi themes).  I always remember her being so glamourous and beautiful.  She also had a sultry voice as the ship’s computer.  It looks like a bit of my youth is fading away.

I want to use this post to talk about the concept of design debt (or technical debt) to describe the variety of “shortcuts” software developers take to compromise design quality in order to gain a short term boost in productivity.  While there may be many good reasons to take these “shortcuts” at the time, from that point forward any future design changes to that section of the code are more difficult, i.e. expensive to make.  In almost all cases, most well-meaning software developers really do intend to return to the code and fix these shortcomings, but due to schedule pressures they rarely do.  The cumulative effects of these “shortcuts” are called design debt and are very toxic to your software.

Much like credit card debt, a small amount of design debt is acceptable.  Unfortunately, due to the nature of software, if real attention is not spent “paying back” the design debt, eventually the system in question collapses under the weight of its highly coupled design.  I created the list below to help you spot the four stages of design debt in your system, so to avoid a “repo” of your software.

1. Impulse Buy - Not doing the right thing today or having the attitude of “I’ll fix that tomorrow”.
2. Late Payments - Adding new features to new code begins to take longer and longer.
3. Notice of Default - The project stops adding new features to enter a “refactoring phase” or “just a week for clean-up”.
4. Foreclosure - It simply becomes easier to re-write the system rather than modify it.

As you get into later half of Stage Three, more and more of your resources go into paying back debt and you cannot extend the functionality of your system to keep up with market demands.  The competitive advantage your software provided the business falls to the wayside as all your time is spent in maintaining a brittle system your customers don’t even like anymore.  Like most ailments in life, the longer you wait to apply a remediation, the more “painful” the cure.  It is far more economical to apply an ounce of prevention, by taking your vitamins in the form of daily refactoring, than wait for the “foreclosure” process to overcome your business assests.

I know – not the most profound insight or the most original.  I think I am finally beginning to understand the relationship between the two after studying all this Lean Six Sigma and Design Six Sigma stuff.  Agile is simply a co-evalent instance of the Lean concepts and principles applied to software development.   I don’t think there really is a “Lean software development” – it is just “Lean applied to software development”.

While I respect the Poppendiecks, and they have been thinking about this WAY longer than I have, I think Lean software development misses the mark.  IMO, they have tried too hard to build the bridge from Lean manufactoring to the software world.  It seems to me that some of the subtleties of Lean are lost with the Poppendiecks’s books, Lean Software Development and Implementing Lean Software Development.

OK, that is a serious charge to make against some of the most respected thoughtleaders on Lean software development by a guy who has, admittedly, not that much experience with Lean.   Now, it is very likely I am completely misundertanding their writings or what they are saying has evolved from their writings.   What is missing from their writings is much of the innovation the Lean Six Sigma and Design for Six Sigma world has brought to the table.  Alan Shalloway seems to be pushing the Lean envelope further than the Poppendiecks.  I think that he gets there is really no such this as Lean software development, but that it is all just Lean.

I stumbled across Agile Shrugged today and read a post on how the author experienced a lot of variation in their team velocity.   The author did not seem too concerned with all the “sawtooth” behavior of velocity chart because they felt the velocity graph was a “fairly accurate measure of our teams velocity”.  Let’s see if this qualitative assessment matches up with statistical process control, one of the Six Sigma tools.

In Six Sigma, a common tool Green Belts and Black Belts use to monitor their processes are control charts.  The control chart is an objective measurement tool to determine if the process under inspection can reliably produce what is expected of it in the future.  By examining the patterns of the data on the control chart we can understand if the process is “in control” or “out of control”.  If the process is “out of control”, then we need to inspect the process, discover the cause of the variation, “mod” the process and monitor the changes with…a control chart.

The diagram below is the velocity data from the team.  You can see the “sawtooth”, or oscillation, in velocity over the course of ten iterations.  The team does seem to have improved their velocity over time, but we still have an order of magnitude difference in the completed output of the team from week-to-week.  Is this significant?  Should we care about the oscillation?

To make a control chart, we need to run some basic statistics on the data: compute the mean, standard deviation (σ) and determine the upper and lower spec limits (mean ± 3σ).  Here are the results for this data set:

 mean: 6.6 ideal days    upper spec limit (USL): 24 ideal days
 σ:    5.8 ideal days    lower spec limit (LSL): -10.8 ideal days

Next, we will plot the data on a control chart showing the mean (green line), the USL (red line), 1σ and 2σ (purple lines).  I have eliminated the LSL because a negative velocity is meaningless.

Now here is the interesting part: looking at the patterns.  Using the Nelson Rules, we can examine the patterns in the control chart to see if the process is “in control” or “out of control”.  Here are the rules that I think are relevant for this chart (please review all the rules if you are interested in learning more):

1. One point is more than 3 standard deviations from the mean. Nope
2. Fourteen (or more) points in a row alternate in direction, increasing then decreasing. Only 8 points so far; maybe something to watch out for.
3. Four (or five) out of five points in a row are more than 1 standard deviation from the mean in the same direction.  Only 2 out of 5 data points.

What do we find by creating and examining the control chart?  Statistical confirmation that our qualitative opinion that our planning process is indeed fine.  Great!  Keep up the good work!

I liked this romantic comedy.  I normally do not like these types of movies, but it was recommended by a friend and I am glad I watched it.  It was a thoughtful, adult movie about a guy who gets his heart “broken in a million pieces” and how he moves on.  The dinner scene is absolutely hilarious for anyone who has gone to that awkward dinner you never thought would happen in a million years.

I think the real star of this movie was Mila Kunis.  Can you say drop-dead gorgeous?  Her hair, make-up and lighting were perfect and she had a role which suited her professional persona.  I look forward to seeing more of her.

Spanish has an interesting word to explain the concept of “excessiveness” or “too much” – demasiado.  It can be used to talk about things, such as “Tenemos manzanas demasiadas”\”We have too many apples”, but interestingly enough it can also refer to people, as in “Él es demasiado”\”He is [just] too much.”

Today, Jeff Attwood was talking about how you can do too much logging in an application.  I know exactly where he is coming from because I was once told to implement the type of logging he describes in his post.  I found the usefulness to be about zero (well…not exactly zero, but more on that later) and they cluttered up my code with something worse than comments.  IME, this type of logging comes from a development environment where people spend more time in the debugger than they do writing tests.  If you have a system described and constrained by tests, you really do not spend time using the debugger.  In fact, I use the debugger so rarely, in order to use the debugger, I need to look up on the Internet how to use it or I need someone to show me.  Talk about feeling foolish – a developer with over 8 years of experience and I don’t really understand how to use the debugger, but that is life.

Why?  Because if I have a problem, I can debug through my tests or just hit Ctrl-Z enough times and get back to a “good place”.  The times when I reach for the debugger are the times I am lost in my own code and I find I just need to step away from the keyboard.  The desire to use the debugger becomes a warning I need reconsider what is it I am trying to accomplish, return to first principles and take smaller steps.  When you are lost in your own code, you need these trace statements sprinkled everywhere to understand what is going on.  When you need to debug your application while it is running, because you have not spent the time to unit test the application during development, these statements are essential.

Now for the obligatory ancedote that highlights a glaring exception to my dogma: I was once working on an application where I was the only developer using TDD and we were having the application fail during system testing.  Not just any part of the application, but MY part of the application.  The part implemented doing TDD, so it couldn’t be MY part of the app that was failing.  Unfortunately, it wasn’t clear why the app was failing from the exception logging, so our architect had us turn on the trace logging.  The root cause of the failure: a method of mine was being fed an empty string that I did not anticipate.  Bad me that I did not guard against an empty string; good me that I can now write a unit test for it & prove the bug is dead.  So where did the empty string come from, a part of the application that didn’t have any tests.  My fellow developer never considered an integration test where his part of the app talked to mine.  Just proves yet again that if you want to find defects in your application, look for the parts that don’t have tests.

Dave Nicolette posted an interesting blog post about using function points (FP) as a means to compare productivity between IT projects using different processes.  I understand the concept – find a metric that speaks to the audience we are trying to communicate with that allows an apples-to-apples comparison.  However, why do I find this still an unsatisfactory answer to the productivity issue?

I tend to think this metric would only be useful for academic types or a research paper.  Sure, it is create more evidence that “Agile is great and waterfall is bad”, and how long do we have to wait for this evidence?  One business cycle?  Since I am on a roll smashing your good idea, I also think the barrier for entry is too high for people wishing to make the case Agile would be good for their organization.  Not only do they need to understand Agile practices & techniques, they now need to become FP counters.  Now we need to start counting FP on all our IT projects?  Is this something our industry has the skill to do?  The evidence I have seen shows we do not.

Yes, FP are “good” because ISO has made them the standard, there is clear way to count them (for the people who know) and academics (and attornies) love them.   There are real reasons why FP are not used in US business today.  I work with the ideal organization (large Fortune 500 company) for FP analysis, they are always hungry for metrics and they do not use FP.  I wonder why that is the case?  It is not due to a lack of education.  There are well-placed, knowledgable individuals aware of this metric, so there must be something else preventing FP.  We need to understand why people who know about this metric, can afford the consultants to do the analysis and still do not use the metric.  When we overcome those issues, then let’s talk about pushing this metric on Agile teams.  In the meantime, let’s stick with “basics” like throughput, takt time or use EVM (as much as I hate it – it is comprehensible to business folks).