Peace on Earth: Effective Development Team Management
If you're an IT manager, then your vision of "Peace on Earth" is probably a carefree existence where developers finish projects on-time and on-budget and who do only and exactly what you asked them to do. So it may surprise you to read that having your developers deliver "Peace on Earth" might be the last thing you want. In fact, it might just be the worst thing that can happen to you and your organization.
Any X-Files fans out there who were faithful to the end – the bitter end (but let's save that for another article) –may recall an episode during one of the last seasons where Mulder finds and releases a woman rolled up inside a carpet in a storage locker. She turns out to be a genie. (Yeah, I know, the show had really gone down hill by this stage).
The genie grants Mulder three wishes, as genies tend to do. Mulder's first wish is for "Peace on Earth". With a wiggle of her nose (or a flip of her hair, or whatever it is that genies do nowadays), Mulder's wish is granted. Mulder doesn't believe her until he leaves his apartment and runs through the empty streets of Washington D.C. He is now the only person left on planet Earth. It is very, very peaceful.
The equivalent scenario plays out time-and-again in our software development shops. An IT manager hands down his wish list (a set of requirements) and his developers duly deliver exactly what was asked for… but of course, it often turns out not to be what was actually needed at all.
Getting what you need rather than what you asked for
Of course, Mulder was undone by the fact that the fulfillment of his "Peace on Earth" wish was open to creative interpretation. As always happens in these stories, his second wish is used to undo the first. When, also true to form, he subsequently discovers that the genie is a slave, he decides to use his third and final wish to release her from her bonds. The outcome of his first wish has taught him that if he simply says "I wish that you were free" then it too might be subject to some strange interpretation. Mulder's solution is to type out his wish. By the end of the story his wish extends to several pages of legalese in which he has closed every loophole and accounted for every possible misinterpretation. He gives his wish to her and at last she is free.
Likewise, in software houses, the root cause of Mulder's "Peace on Earth" predicament is simply ineffective communication. Developers often do deliver what was asked for. It might not be what was wanted, but it is what was asked for…or at least, an accurate interpretation. This is basically a communication breakdown that can be solved by:
- Encouraging the client, like Mulder, to be as specific as possible in their requests, and
- Spending more time with the developers in communicating the client's intentions – or, much better – putting the developers in direct communication with the client.
Effective requirements gathering and documentation
The most prevalent cause of "Peace on Earth" is a poorly articulated or vague set of requirements. It's not that you have to describe your system in Mulder-style legalese, but you do need to work with the client to get a specific and accurate list of requirements, and you do need to directly involve your developers in this process. I describe how to do this in my previous article, Project Management 101.
Once you've obtained an initial requirements list, visually "play back" these requests to the client. Create a detailed flow chart. Build accurate screen mock-ups. Identify each process that the application goes through. When you have done that get all the interested parties (business owners, project managers, development team, test team and other relevant experts) in a room and walk through each process using the flow charts and screen mock-ups. Buttons will be moved and labels will be changed. Fields will be added here and there and perhaps your flow chart will be completely reorganized. Each time a major change is made, the process goes back to the beginning. At the end of the day everyone will have a complete understanding of each process and the screen involved. Get sign-off from the client and you are ready to start designing your system.
A number of years ago I had the privilege of working with the Metropolitan Opera in New York. The consulting company I was working for was hired to design and build their ticketing system. The overall business process they defined for selling a ticket had many permutations. You could just buy a single ticket. You could buy tickets to more than one performance. You could use multiple forms of payment (Visa, Amex, cash etc) to pay for a ticket. As part of the purchase process, you could also make a donation to opera and/or subscribe to the Opera magazine. It took us two days of conferences to walk through and revise the simple scenario of selling two tickets to the same performance using a single method of payment. But, by the end of those two days there was no doubt in anyone’s mind that we knew exactly what to do to sell a ticket. Even some of the client's own people learned subtleties of their business process of which they were previously unaware.
Fostering a strong client-developer relationship
The second cause of "Peace on Earth" can be far more lethal. Its root cause is the closing down of communication between the client and the development team coupled with a tendency for IT management not to back its people properly. The team tries its best to interpret often vague requirements and deliver what is needed, but credit is not forthcoming when they get it right. Blame on the other hand is speedily apportioned when they don't.
In this atmosphere, I’ve seen the developers turn into genies and deliver only exactly what was asked for, with no attempt to determine what was actually needed or wanted. It's counter-productive. It's passive-aggressive. And steering a team away from this attitude can be very difficult.
In one of my previous jobs, I was working on a product that was the primary line of business for the corporation. Credit for a job well done began and ended with the CIO; blame was spread evenly throughout the ranks. Every time I was asked to add a feature, or to fix something in that application, the attitude from those in charge was "I am granting you the privilege of touching my precious application; don't break it." As a result I always did exactly what they asked me to do. I never gave them what they wanted; I gave them only what they asked for – and only if they asked for it in writing. I learned early on that if I innovated and I was right I got no credit. If I innovated and I was wrong (and had no paper trail to back up what I did) then my job was on the line. I turned into a genie and delivered "Peace on Earth" every time. It was my only means of self preservation and I got out as fast as I could.
As an IT manger, if you encounter this problem with your developers please take a few days to have an honest look at the corporate attitude towards them. I have rarely met a developer who wasn’t willing to go the extra mile when given a free hand to innovate, when given credit for their accomplishments and, most of all, when given a sense of ownership in the product he or she was creating.
More recently, I've been fortunate enough to encounter such conditions. I work for ASPSOFT Inc in Orlando (Jonathan "Angry Coder" Goodyear’s consulting company) and it's the best job I've ever had. Why? Because each developer has ownership of the client for whom they are working, and it’s "sink or swim" based on how well you please that client. Jonathan monitors every client to ensure that they are happy with our work, but leaves the day-to-day operations to the consultant assigned to the client.
My primary client for ASPSOFT is the Aesculapius Research Group. I work directly with the president, Dr. Ollie Edmunds. He has given me a share in his application. This does not mean that when he sells a license to the application I get a bonus check. It means that he allows me pride in my work. If I go the extra mile, use my initiative, innovate, then the time and effort is appreciated. When I make improvements that fit his vision for his product, I get credit for my hard work and investment. Both my boss and Dr. Edmunds understand that this will drive further innovation and improve his product. And that's the real goal, isn’t it?
Isn't it amazing that this is often all it takes to get the most out of a developer? A good developer is like that all-powerful genie. He or she can make almost anything happen for you when they are motivated and understand exactly what it is you really want. When they are disenfranchised and disinterested, however, your wishes may be carried out to the letter, but the outcome may well not be what you wanted at all.