A Slightly Softer Wimper

As a follow up to my missive on Agile Failure in my organization, I must point out that a recent planning session with another team led to some useful activity in rating the stories in the team backlog. That said, the previous avatar of the Scrum Master was in the form of a PMI certified project manager from a Waterfall shop. Those skills were very much in evidence during the meeting. It seems more and more clear that the training, experience and quality of the team members deteremine the outcome of a project far more that 5x7 cards, stand up meetings or manifestos.

With a Wimper

The other day I ate lunch with a colleague. She argued that training the entire company on The Oz Principle and having each employee participate in eight two hour evaluations each quarter was worth the expense and bother even if only she and I were inspired to demonstrate responsibility-taking behavior before our co-workers. My position was that not a single management fad I have ever witnessed emerging from the executive suite had had any impact on corporate culture or effectiveness. The Oz Principle walks like a duck, quacks like a duck and, more to the point, smells like a duck. The most disappointing part is that seasoned businessmen and women actually buy these books.

I have made no secret of my doubts about Agile Development. To be sure, my company showed all the signs of an Agile Failure environment - top heavy decision making, Agile by mandate, lack of top-level buy-in, a culture of just-get-by. You can't just flip a switch and change the corporate culture. Now, after only a few months, the course of events is unfolding exactly as I anticipated based on my two decades experience at various companies.

First, at the sprint planning session, the so-called User Stories are written based on the steps required to complete some system design that each developer holds in his or her head. Instead of "As a call center rep, I want ..." every card begins, "As a developer I need to ...". Since our product owner comes out of IT instead of the user organization (she says she KNOWS what they need) no one blinks. When I brought this up, I was told that according to some Agile books, this is allowed. I shut up after that. Next each user story is assigned a complexity based on an unstructured discussion in which the senior members of the team dominate - no input from the underlings. Finally, the programming manager, who is on the team, provides the task estimates and then assigns each task to a developer before the first sprint has even started!

Here's what has happened: the manager nixes any self-organization and the focus remains on IT delivering the functionality that they believe the user needs. To top it off, the higher-ups are demanding hard deadlines and treating every problem as a fire, yanking team members around like manic chess pieces. This process reflects the exact sequence of events that went into planning a project before we went all Agile. As I expected, the members of IT have found a way to do exactly what they were doing before but pay lip service to being Agile. It was that way at the phone company and it's that way now.

The challenge to management is to cancel their Management Book of the Month subscription, do some real research in organizational behavior, look hard at the culture they have to deal with and find creative, insightful ways to move the company out of the 1980's. Good luck.

COBOL Rules!

Having taken a position with a firm that recently launched an Agile Development initiative, I have been giving a lot of thought to how software is developed.

First off, I will say that I don't hold out much hope for Agile. Every company has its own work culture which is entrenched and not easily shifted. Some may be ripe for accepting an approach like Agile Development but most are not. If Agile is launched an AVP with a memo and training program, just sit through the seminar and wait. It will go away just like Who Moved My Cheese.

More generally, I think we spend much too much time and effort in agonizing over organization and methods instead of producing quality programs. I don't mean we need test-driven development or a million test cases in the QA group. I mean that little attention is paid to the actual code that is produced. Is it efficient? Is it secure? Is it robust? Is it easy to understand and modify? I believe W Edward Deming said that the problem with management is that it reads too many management books and not enough statistics. Same with programmers. My last organization did a Lunch-and-Learn series on best practices in coding specific situations. It was nice. Most of what I see, though, is google-the-problem/copy-a-sample-from-a-blog/compile-the-result. And that is when they aren't trying to stay on the bleeding edge.

I have rediscovered an admiration for COBOL programmers. I have to assume that the senseless dash toward "progress" seen in Java programming circles is less an issue in COBOL, which is considered a dying computer language. These guys and gals receive a request or specification and then code a solution. End of story. No need to impress anyone with the latest framework, there.

I read a comment thread recently which mentioned the "80% of anything is crap" rule with regard to programmers. Why don't we attack this statistic by attempting to make that crap a little less aromatic? What we need is a movement to improve the quality of programming by teaching theory and best practices. We all know that well written code is less prone to errors. But do we pay any attention to coding? No! We spend most of our time talking about patterns and pair-programming. Perhaps with enough theory and programming philosophy, developers might recognize that moving something from the Java source file to an XML file does not reduce the code, it merely translates it into XML. Or that using JUnit increases your code-base because your test modules are programs too that may need to be tested themselves.

I have been a programmer my entire working life but I trained as an engineer. I often wonder when will the time come when software "engineering" lives up to its name and drops the hacker culture and becomes a true discipline.

Speaking of Protocol Droids ...

In my previous post, I might have inferred that protocol droids are annoying. If that is the case, then: Good. That is what I meant .

In reflecting on this further I remembered a train of thought shared back in the misty past of this blog: is it possible to create artificial intelligence without designing in some level of artificial neurosis.
I realize that C3PO's function in Star Wars is as comic relief. His quirky personality might be further justified by the fact that he is indeed a homemade droid built by Anakin Skywalker (in the heretical Episode 2 - or was it Episode 1 - who cares!) . I choose to think that C3PO's sometimes role go between for machines and people has required that he be designed to understand the weird thought processes of the human side of this transaction.

To be sure, C1PO was quite conversant in the binary language of moisture evaporators. Yet his designers (C# programmers no doubt) foolishly assumed that human communication could be achieved following the same simplistic assumptions required to understanding the ramblings of Obi Wan's toaster.

C2PO proved completely inadequate to deal with even the sarcastic utterances of an R2 unit. Only when the development team (having ditched Agile Droid Development in favor of actual forethought) watched the home movies of Anakin hiding his Halloween candy from Leia did they fully appreciate the possibilities of cyber-paranoia.