(C) 2015 Hank Wallace

PREVIOUS – Embedded System Design Library: Simplicity

Scan the employment boards for software jobs and almost all of them list some sort of agile development experience as a requirement for employment. The HR people have no idea what that means, and I suspect most of the engineering VP’s have no idea either, but that’s what we do here and, well, the new guy needs to know when to show up for the daily scrum.

Now there’s a huge problem in industry regarding software development. Most programs are delivered late, over budget, and marginally functional. The customer is disappointed, the CEO is angry, and the shareholders are restless. The software development industry experts know there is something wrong in a big way, and agile methods are their effort to fix the problem and calm the torqued CEO.

Having worked with agile methods and developers (even before the terms were coined), I understand that there are benefits. But I want to warn you of some fundamental truths.

The most important thing about agile methods, and teams in general, is that your team will only be as good as your best team members. Probably not even that good. So if you have B- software or hardware engineers, there’s no way you will be delivering A+ products. Can you say “Microsoft”?

You might have some really smart people on your team, but if they are not thinking about the customer, then you are headed down the toilet. I’ve worked with many an engineer who geeked out on NASA space videos and quantum mechanics, while having no understanding of what to do to make the customer smile. Smarts aren’t everything, but are only the starting point.

Sitting two mediocre software engineers in front of a lousy Windows PC, using the lousy Eclipse IDE, remixing lousy open source code off of SourceForge, well that’s not the recipe for success. It may be “free” software, and you might be paying those Indian guys $12 an hour (Use two! They’re cheap!), but your product is going to suck.

Say you are starting a new team. How to proceed? You need to find software engineers who can write working, functional, bullet-proof code on their own. Only then, when you build your team will they crank out killer products. The agile methods are only the cherry on top. You’ll hear comments like, “Oh, I already do that. No big deal.”

I’ve said it elsewhere, and it bears repeating. Quality products are created by quality people. I’ve had the good fortune to work for a bunch of those in my career. The lazy, the liars, the cheats, the BS artists, none of those people ever produced a quality product. Look for team members who are honest, have quality friends, seek challenge, treat others with respect, are good parents and sons and daughters, and your team has a chance of succeeding. You’re not going to get good code out of a geek with $30,000 in credit card debt, no matter what agile dogma you promote.

So I was working with this one agile team. My code was to talk with their code. I would find small bugs in their code that blocked my progress. When I asked them to fix these small bugs, they responded, “We’ll do that in our next sprint.” When is that, I asked. Two weeks. Does this make any sense? I just fixed the bugs myself, and continued my work.

And since the software engineering group is just a smaller part of the larger enterprise, serving the gigantic business group, to what corresponding business system does the agile software system interface? Isn’t there a general business agile method paralleling the software agile method? No? NO?? Then it appears that we have quality, under budget, on-time software being pumped into an old style, fly by the seat of your pants wasteful business model. Is that an improvement? What good is it if the engineers have got religion when the sales force is out on another two hour lunch? (Isn’t that enough questions for one paragraph?)

Please, please understand that sometimes agile=stupid. If you are following a system and doing stupid things as a result, then you are doing stupid things! Stop it! Get the job done! What an abomination is the word agile if your teammates have to wait two weeks for you to fix a simple bug that you could repair in 10 minutes (even without pair programming).

Let’s not sacrifice common sense in our quest for cheaper software.