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[1] from Lee[2], 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[3], got up, dumped[4] my nightly cup of tea in the sink and headed for the secretary desk that contains my bottle of Scotch[5] 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[6], 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[7] 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[8] 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[9] 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[10] effect.
So I suggested that Lee consider triaging the backlog[11] 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[12] 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!
[1] 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.
[2] Not his real name.
[3] 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.
[4] 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.
[5] Balvenie DoubleWood 17 Year Old.
[6] 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.
[7] If you knew Lee, you’d know how apt the image of him swinging a rifle is as he battles with any resistance.
[8] Heck by now it was 1 o’clock in the morning! Who’s at their diplomatic best then?
[9] Yep I got smart! Amazing what a good drink of Scotch can do for your diplomatic abilities.
[10] His actual words though while extremely descriptive and colorful are most probably biologically impossible and certainly not printable.
[11] This is not a new concept by any means it is a fairly common practice.
[12] He always emails me good news during the day and phones bad news late at night, good grief!
Keeping Agile™ with Brian Lucas 
Nice article Brian. Do you advocate having the business system analysts or subject matter experts be located in the user community as well?
Ha, ha Brian! Another tale told with your dry wit. I love reading your blog. I can verify that as a member of the enemy camp having someone working with us whose time we controlled would smooth relations. You always explain things in terms I can understand. That’s rare in my experience!
Brian sounds like you are a miracle worker and certainly a good friend. Do you or your friend Lee have any statistics to share on what the productivity was like for their development staff under agile and downsized as opposed to the previous staff size and what I assume was waterfall?
If you could expound more on how you handle changes in direction from the product owner, I would appreciate it. It does not seem to be acceptable to lock down the development or be in constant flux. How do you decide what is an acceptable change and what is not?
Hi Brian! I really enjoy when you write with humor and share a little of your personal life. My father who was a lawyer always kept a bottle of Scotch in the drawer of his desk in his bedroom. Your mentioning your nocturnal nightcap brought back this memory. My father was also a very wise man and people were always turning to him for advice at all hours of the day and night. He always told me knowledge should be shared. I see you believe in the same philosophy. I get a little confused with the executive mandate required for agile adoption and the need for agile to be a group activity with team voluntary buy in. Were do you draw the line on each? They seem mutually exclusive approaches. I read every article you post!
You are implying here Mr. Lucas that it is not a good idea to follow scrum rigidly. What are the acceptable variations from the standard scrum method in your opinion?
I always thought that it would be a funny twist if the business people or users learned agile first then taught it to the IT people. What do you think of that?
Another winning post Brian! I have been thinking about creating hybrid teams of IT and business users that just create functioning prototypes in advance of the agile teams to help the business users understand their needs better. These were potential solutions that I was going to also expose to our customers via social media (haven’t figured that out yet) to see how they reacted. what do you think of that idea? Your loyal reader!!! -Jack
Hi Brian: You made this sound so simple. Do you think most agile solutions are simple answers? Is agile by nature always a simple solution or system something that is obvious?
Interesting tale Brian. I wish all agile stories ended this well. Since they don’t that makes me ask what is in your opinion the most critical success factor for being agile?
Why can’t I find intelligent friends like you who are gurus and give great advice late at night. Everyone I know is an idiot and wants to change me an arm and a leg for talking to me between 9 to 5.
Hi Brian! I am new to agile and just found your blog. What a wealth of information!!! I have a question here, Is it better to implement a few agile concepts and be more traditional on other aspects. Like using user stories for documentation, but still having work assigned by a project manager and basically doing a waterfall in 8 weeks? Or do you have to implement pretty much all of something like scrum to make it work? Please answer! I could use some guidance.
Darla, I know you are going to not like this answer, but it all depends. Much of agile’s benefit comes from team motivation! If you just change to implementing user stories and yet the team is not motivated or not acting as a team, you won’t gain benefit. Unfortunately, I have observed far too many organizations implementing agile in really a name only manner and then claiming it failed to produce results. Worst still is when outside consultants come in and unscrupulously begin an agile effort under circumstances they know will fail just to get a temporary pay check. This gives the organization the out in that they had engaged experts and it did not work. I am not a supporter of strictly adhering to a process for process sake. In fact, that is the exact opposite of being agile. However, there are many aspects of popular agile methods like scrum that as just plain good practices. Having brief daily meetings, promoting team integrity and ownership by having them sign up for work rather than be assigned, working in smaller increments and verifying the results against the stakeholders and the target audience, spending more time developing and testing and less time specifying needs in formal documents – these are all good practices. Just implementing user stories, unless they are really great user stories, will not buy you much if anything. If they are not good user stories it will actually hurt. The most successful agile implementations I have seen are the ones where the organization made a mental and philosophical shift to agile before actually starting to practice any agile methodology. I hope this helps you can email me if you need more. Take care!
Hi Brian I just discovered this post and I think it could help us resolve a similar conflict at our company. I am going to share this with others on my project team.
I just read this post that Karen sent me. From a project management perspective it seems you are giving up a valuable software development resource when personnel are already scarce. How do you justify that when resources are already short? Its great this worked out for your friend, but realistically no IT department would ever agree to this.
Karen sent this to me as well and I believe the idea has merit. We have been wasting too much of our time explaining things that are common enough knowledge in our inside sales department. If we owned an IT resource like [name deleted by administrator] it would save us time and help avoid confusion. I believe we should explore this possibility. Thanks Karen for broaching this.
Thanks for finding this article Karen and interjecting this thought into our discussion. I have glanced through several post here and this blog has some very impressive content and will be a good resource for us as we become “more agile.” I am not sure that I can embrace all the ideas here, but they are good points for a healthy discussion. At this point, I suggest we take this conversation out of the comments here.