By Brian Lucas
This one is for sweet Penelope.
“Keep your friends close, and your enemies closer.” –Sun-tzu
The quote is a tongue-in-cheek reference to the fact that many in IT feel the user community is the enemy. This post started when I got a call late one night from Lee, a friend of mine from my high school days who is a CIO at a firm located in the southwest. They were rigidly following a scrum methodology. The users were in revolt. Despite some good numbers, the CEO was breathing down his neck hotter than the habanero chili that Lee normally downs for lunch.
After a sigh and a groan, I accepted the unkind and intrusive goddess of fate once into my life. I put my Droid Bionic on speaker, laid my book down, got up, dumped my nightly cup of tea in the sink and headed for the secretary desk that contains my bottle of Scotch and heavy old fashion glasses in the bottom cabinet doors. I have to admit I was not listening to him as he was babbling out what he felt was pertinent information, but I let him vent as I poured a drink and began to sip.
About 9 months ago, Lee had started an agile initiative on my advice. It was my recommendation as to how he could address a staff downsizing they were experiencing. In their boom time, they had over 30 IT personnel, now they were down to 13 with just 5 developers because of a shrinking market for their product and resulting budget cuts. They did not have money for training or consultants, but I suggested a series of books and some websites and forums where there was free information and support as well as a local agile group. In typical fashion, Lee, like Jim Bowie at the Alamo, waded into the fray of getting his organization and the user community to start using agile. His method was effective because, in less than four weeks, they were beginning to crank out their first iteration.
They did make progress. Some of it was quite good, but the user community was complaining to the CEO, and Lee became worried. Two basic problems were plaguing the initiative. The first was weak business expertise in the user community. The users were used to changing their minds all the time and not being held accountable for asking for the wrong thing. They were complaining that they were not given enough time to decide what they needed. They felt that the IT department was exceedingly adversarial. The second is they also felt the agile process was single streaming the development too much. They also wanted to make progress on multiple fronts. Both complaints were valid.
When I made the mistake of telling Lee that both his user’s complaints might be valid, he started yelling about how one of the rules of agile development was to focus on only on one thing at a time, and I should know that. When he finally settled down, I asked Lee what the problem backlog was like. He said they had over 60 items in the queue. So I asked him how they were prioritizing the items for work and Lee retorted that was the user’s responsibility. I, of course, agreed with him.
Then I asked him what they are doing when the user starts changing their mind on what they need or resets priorities. Lee responded that they either defer changes to the next iteration or stop the current iteration and start a new one. All of which come from the standard play book of scrum. I asked him how much this starting and stopping was affecting the velocity of his team. He admitted it was having a significant effect.
So I suggested that Lee consider triaging the backlog with the users. Because of layoffs, they had lost all but two of their analysts. The remaining two were terribly busy. They did however, have a developer that was a long term employee. He knew the systems in and out and was able to speak to the users in purely business terms. I suggested that he transfer this person to the user community and have them own his pay card. His responsibility would be to work with the users to write better user stories (something he was only marginally better at than they were). He would also help them analyze their backlog and prioritize and group the items based on what made the most sense to develop either directly sequentially or in tandem from a software development perspective (something he knew quite a bit about).
Flash forward nine months. Lee emailed me and said things were perfect! The users were happy; his development team’s velocity was up and most importantly the CEO was going out to lunch with him for chili. The users felt more in control of the development. The momentous change came because they were able to simultaneously develop user stories that were remarkably similar. This gave them an almost 2 for 1 payoff. By looking at the user story a little more abstractly they were able to write more generic code which reduced their code base. Everybody was happy.
The moral of the story is that agile is a group activity. Everyone must have their oar in the water and be rowing in the same direction. It is also necessary that everyone understand the principles of agile in a deeper sense. They must not get hung up on the terms or the process of any particular method. Agile is about adapting. Lee could have also brought someone from the user community into the IT Department. However, since the user community had more budget than Lee, it made more sense to transfer the cost of his most expensive developer over and put him in a new role.
Success for Lee’s company will remain a trial, since they face so much competition from foreign markets. He will constantly have to look for new ways to innovate and cut costs. The challenge of being agile is constant and achieved only a day at a time, so remember to keep agile!
 For him it was only 9 PM for me it was midnight. I swear he does this on purpose, because he feels if I am half asleep I will be an easy mark when he hits me up for something.
 Not his real name.
 Journey to the End of Night by Louis-Ferdinand Céline translated by Ralph Manheim in 1988 is rather a heavy tale. It is said to be semi-autobiographical about an antihero, Ferdinand Bardamu. It chronicles his experiences in Africa during World War I and later America where he works for the Ford Motor Company. Then follows his life to France where he becomes a medical doctor in a poor Paris section.
 This is a very common problem. If your users don’t know what they are doing, agile will only enable you to turn out junk faster. You need to hire subject matter experts (SME)s in cases like this.
 Balvenie DoubleWood 17 Year Old.
 One of the first lessons of listening to someone in trouble is to LISTEN and don’t speak. Even if you know what the solution is before the person with the problem finishes the first sentence, they won’t appreciate it if you interrupt them. They simply have to vent their emotions and frustrations. Eventually they will learn that you are always asking them a different set of questions or coming up with answers that are different from what they are spouting about in the beginning. At that point, they will begin to simply state their problem and then let you guide the conversation from there. I have never found a short cut to be effective. More’s the pity.
 If you knew Lee, you’d know how apt the image of him swinging a rifle is as he battles with any resistance.
 Heck by now it was 1 o’clock in the morning! Who’s at their diplomatic best then?
 Yep I got smart! Amazing what a good drink of Scotch can do for your diplomatic abilities.
 His actual words though while extremely descriptive and colorful are most probably biologically impossible and certainly not printable.
 This is not a new concept by any means it is a fairly common practice.
 He always emails me good news during the day and phones bad news late at night, good grief!