Here at DTS, we’re very focused on consulting-type software development.  As such, we have very direct access to our end users and customers.  Our work is “clearly” defined and prioritized by our customers and we receive direct customer feedback every two weeks.  We do not have a dispersed customer base, it’s usually a single organization.  However, last week I had lunch with a friend who does more “shrink-wrap” development.  His customers and end-users never define or prioritize their needs.  In fact, unless it’s by pure happenstance, the developers never meet or know their customers.  The functionality and feature set for the software is defined by an internal customer proxy who has his “finger on the pulse of the customer”.

Now a disclaimer:  I’ve never worked on a shrink-wrap team, I’ve always been on consulting development teams.  Given that little disclaimer, I don’t understand how a customer proxy can really define what an entire unseen, unknown customer base really needs.  I know that some organizations do prototype or “focus-group” type testing to gauge what their customers want.  But my friend’s team develops on a gut instinct of what their customer base needs. I’m not sure this ever can truly deliver quality and value to a wider audience.  I think it leads to Microsoft Word-type deals, with tons of functionality that only a few people actually use.  Don’t get me wrong, I think a lot of good things come out of gut instincts.  I think there is a lot of value to anticipating user needs.  It’s part of innovation.

Read more »

OK, don’t be too concerned, I’m not going to break into some bad Bob Seger karaoke.  Here’s the deal:  Today over lunch I planned on doing a quick 20 mile bike ride to refactor my wetware.  Based on my usual average speeds over flat terrain, I figured on about a 1 hour ride.  Before I headed out, I checked the weather and the wind speed was about 2 mph (not much at all).  So, out I go and I’m cranking all the way out toward the foothills of the Rocky Mountains.  I get to my turnaround point and I’m right on my usual average velocity.  I’m thinking, I’m getting back to the office right on time.  So, about a mile in on the return leg, the wind decides it’s time to blow.  And it really starts blowing a strong headwind.  I can’t get over 14 mph!  I get back to the office and it took me 75 minutes instead of 60!

So, what does this have to do with anything (except that now you know that I ride my bike at lunch)?  While I was riding back, I thought, this is a lot like a big software development project.  A lot of development teams start out thinking “This is a 20-mile ride, I usually do it in 60 minutes”.  They try to figure out all the dependencies (i.e., the terrain, the wind speed), and feel really confident that they’ll get the job done in time.  Then they start building the software.  The wind is at their back…they’re cranking through the work.  Then, one day, the wind starts blowing.  This project has complexities we didn’t think of.  We didn’t know it was going to be this difficult.  But we still need to finish the job (we still need to get back to the office).  We can’t work or pedal any faster.  We know we’re going to be late.  What do we do?  The project goes into panic mode.  Do we sacrifice quality to get it done?  Do we sacrifice schedule?  Do we go over budget?  The reality is, most traditional development teams do all three at one point or another.

Read more »

Read more »

In light of the recent news about American Airline’s maintenance problems, I sat down and talked with my Dad about aircraft maintenance.  You see, my Dad was a maintenance Crew Chief for Pan American Airlines for nearly 30 years and I wanted to understand how things got so bad for American.  My Dad explained the inner workings of Pan Am’s maintenance program to me.  The program dated back to late 1960’s and early 1970’s and was remarkably agile-sounding.  Here’s the program in a nutshell.

Aircraft are regularly called in for routine servicing.  The servicing was usually scheduled for about 3 days.  A QA specialist (or several QA specialists) examined the aircraft and used a set of cards to write up work orders for each item that required servicing.  The QA specialist then sorted the cards by theme (interior, engines, avionics, etc.), estimated how many items could be completed in 3 days based on historical data, and slotted them on a task board.  The crew chief for each “theme” area would pick up the cards for his team.  The crew chief and his team would triage the work items and prioritize them.  Then, the team members would select the work items they would work on and provided the crew chief with time estimates to complete each of the tasks they selected.  This allowed the mechanics doing the work to actually estimate the duration of their tasks.  The team would then commit to completing the tasks within the 3 day service period.  Each day, they’d check in with each other to make sure things were on track.  During the service period, the crew chief worked on some maintenance tasks, but he also made sure that everyone on his team had what they needed to get their job done.  At the completion of the service period, the QA specialist would come back and inspect each maintenance item and either accept or reject them (and FAA inspectors checked things as well). Team members were also encouraged to think about how they did their job and suggested new or better ways to do things (in fact, they received monetary incentives for coming up with innovative ideas).

Read more »