It’s the End of the Business Analysis World as we Know it? Part 4
Being the serialized story of Brian Allen and Ann Brady, business analysts, and their Adventures in the New Oder of Agile
Excerpted from the forthcoming book from John Wiley, The Agile Business Analyst due out the end of 2013
Chapter 4: Wherein the business analysts confront Dmitri and his curtains and provide a positive impact, and Verna phones in
Brian and Ann entered Dmitri’s office as he hung up from his phone call with Verna. He was still standing at attention behind his desk, his chair pushed back as though he had jumped to his feet involuntarily. He smiled at them and motioned them to seats in front of his mahogany desk while he pushed back the French cuffs of his shirt and sat down. Dmitri was slight of build and had longish blonde hair pulled back and parted in the middle.
Brian began the conversation. “Something is different in here than the last time I was in your office, Dmitri.”
“It’s curtains, Brian,” replied Dmitri. “I had them installed last week.”
“Not bad. I guess you are doing well, then.” Brian paused and Ann picked up the slack.
“What are the new projects that you are undertaking, Dmitri? Do you have a prioritized list with some timeframes?”
“Of course.” He pointed to a white board on the side wall where there were a number of what appeared to be user stories written in different colored markers. In front of the white board was a small round table and several chairs, “This is where I have my product planning meetings and sometimes the teams gather round for their sprint planning sessions.” He said with pride and a trace of superiority as though to say, “and you are not invited or needed.”
Brian felt somewhat annoyed if not betrayed. He had worked with Dmitri in the past. . He and Dmitri had spent hours evaluating impacts of new functions and features that Dmitri and his staff wanted to implement. Brian’s analysis of Dmitri’s proposed initiatives usually uncovered unforeseen impacts in other departments in the organization. Brian then met with the impacted constituents to mitigate or ameliorate the impact, allowing Dmitri to go ahead with this initiative. And now Dmitri preferred a white board to Brian.
Dmitri rose from his desk and walked over to the white board. He read, “as a sales person I want to have access to product line information on my mobile device, so that I can provide that information to clients on an as needed basis.”
Brian realized that Dmitri was just showing off his new toy but he just couldn’t help himself. “Are there enough sales personnel who use their mobile devices during sales calls to warrant this feature? Or are we going to have to have all of the salespeople trained on how to use the new feature?”
“That is not my problem,” replied Dmitri.”I provide the facilities; it’s up to Sales Management to make the salespeople take advantage of it. That is a management issue, and is not part of the agile development of this product.” He said dismissively and quickly turned back to the white board. “Here’s another one.” He read a user story written in red with a date marked next to it, “as a customer, I want to earn points for my purchases, so I can exchange them for additional free goods.”
Ann chimed in, “what is that feature all about?”
“That is one we’re already working on,” Dmitri answered with growing enthusiasm. “We are building a reward program for frequent buyers to increase our repeat customer percentage. We’re going to award points, based on price and volume of purchase, which can be exchanged for gifts from a catalog. It will be like the airlines’ frequent flyer programs, except we’re not going to call it ‘frequent buyer program’. We’re working on the name of the program. We will put our higher-priced or slower moving products in the premium catalog. Everyone wins. It’s a great program. We’ve been working on the supporting software for three sprints and already have user screens for point exchanges to add to the website, the programs and the database that accumulates the points for each customer, the maintenance screens for the Points Database, and the program that calculates the value of the points and the exchange. We are also doing the marketing program in an agile way as well. We have three graphics artists developing the user interface. Got a couple of copy editors writing up the copy. Everyone’s turning things around in two-week iterations.”
Dmitri’s excitement about the program was almost infectious, but both Brian and Ann saw warning flags.
Brian couldn’t stop himself again and asked: “you seem to be addressing the web-buying population. But what about the stores, the distribution channels and the retail outlets? Your user story does not limit to just web purchases. If you’re trying to attract more people to the web this might be a good program to do so, but it might enrage our distributors and retail outlets would perceive a loss in sales. If we lose our retail and distribution, we are doomed.”
Ann: “Did you consider that there will also be taxes to be paid on the gifts picked up with points? And if you order over the web, there is shipping. Will you charge the customer for that or absorb it?”
Brian: “Have you determined exactly who will be doing the maintenance and handling the customer support questions, of which there likely will be a lot? Corrine over in Customer Service has been complaining to me for a long time about how overworked her staff is. I doubt if they could take on this initiative at this time”
Ann, “Did you get together with the accounting people, to determine how this is going to be carried as a liability? Basically, you’re creating an IOU to the purchasing customer for goods you’re going to deliver in the future. Accounting won’t let you start the program until that is all sorted out.”
Dmitri seemed somewhat deflated, or at least as deflated as a marketing person can be. “The team didn’t bring the issue of liability. They only addressed how the information would be transferred from the Points Accumulation Database to a general ledger interface.”
Ann interrupted: “That’s because they talk file layouts, not accounting principles.”
Dmitri looked at Brian. “We didn’t discuss anything but the web-based interface and how it was going to be created. The team should have thought about this and brought it up during the discussion of the user story.”
“It’s not their job, Dmitri,” said Brian. “They assume that you will take care of all the business impacts. They want to know what they need to do to implement the user story. If there are other impacts, they need to see other user stories. For example, have you considered how the points are going to be awarded at the cash registers of our stores and in the retail outlets that are selling our goods? And, how about inventory? The first time an item is taken out of inventory as an award the inventory will be out of balance. Since there will be no sales order to charge against and our current order entry system requires a sales order for inventory removal.”
Dmitri slumped noticeably and went back to his desk. He flopped into his chair. “I don’t understand. We never had to worry about such things before. We just come up with programs, see them through from a marketing and sales perspective, and then we do them. Who is taking care of these ancillary issues now?”
“This apparently is the New Order of Agile, Dmitri. What did Ken say to you about this?”
“I don’t think he did. He just said the product backlog is my responsibility. We have been using the user stories successfully for a number of iterations now. Are you telling me that when we finish all the work we are doing now that we still won’t be able to put the rewards program into operation?”
“I think, Dmitri, that you will run into a lot of production problems if you tried. Not to pat our own backs, but in the past Brian and I have handled the impacts and initiated projects for other departments to accommodate the marketing initiatives. We defined the capabilities that were necessary for your initiative to be successful, and you didn’t have to worry about it.”
“But there are no business analysts in agile. Ken and Vince say so. And I certainly don’t want to meet with all the other departments and business areas. They are all so retrograde.”
“Yes,” warned Brian in a whisper. “But interruptions and impacts to operations come under Verna’s purview.” They observed a moment of silence staring down at the phone on the desk expecting it to light up with a call. The phone remained silent.
“Well,” Ann stood up and walked over to the whiteboard. She turned around with a wry smile on her face. “If the business analyst worked directly for you and was your emissary to the rest of the business he or she could identify the impacts and interfaces with the other business units and business processes. The business analyst could define what would be necessary to allow a successful implementation. The business analyst could bring back new user stories, or modified user stories that you, as product owner, could add to the product backlog in whatever priority order you desire. Then you can present the stories to the Development Team. So the business analysts aren’t really in agile, they’re not between you as product owner, and the developers.”
Brian chimed in, “not only that, but the business analyst assigned to your projects could meet with the business analysts who were still on non-agile projects and make sure that all impacts are resolved and all the projects are in synch. After all, Ken was quite adamant about the problems of still having waterfall projects in place with which his agile projects would have to interface. He wants the world to be agile and only agile, so he has no prescribed means of dealing with the non-agile teams.”
“I like it,” said Dmitri. “So you will assign at least one of your business analysts to work with me as impact analysts on all of these initiatives to make sure that all impacts to other business units and departments will be accounted for?”
“I think that can be arranged,” said Ann.
“Looks like we dodged another bullet,” breathed Brian as they walked toward the cafeteria for a cup of coffee after the meeting with Dmitri.
“Do you think we got Dmitri on our side?”
“What side is that?:
“In favor of business analysts. Realizing our value.”
“Not quite. He is using ‘business analysts’ as ‘impact analysts’. He clearly does not equate the two. He has been brainwashed by the New Order of Agile zealots.”
“Well, a business analyst by any other name is still a business analyst.”
“Let us keep that to ourselves, shall we?”
As they lined up amidst a crowd of caffeine lovers to get their coffee, Raj intercepted them, having to shout over the numerous mid-morning-break conversations around them. “Scott is looking for you. He seems desperate.”
“Wonder what that’s about?”
“Oh, and Ken is looking for you and he does not seem happy. Oh, and Verna’s secretary told me in the hall that Verna is also looking for you.” The cafeteria went silent.
Will the business analysts be able to remain business analysts in the New Order of Agile or will they have to change their names to protect the guilty or worse? What do Scott and Ken want now? Will Verna finally appear and put them out of their misery? Tune in next time when you will hear Scott say “there’s no crying in software development”, and see Brian sling his backpack over his shoulder.
Don’t forget to leave your comments below.
My local news station had a story that made me think of how easy it is to get performance measures wrong. The Atlanta Police Department recently announced to police officers that revenue from traffic violations will be used for police officer pay raises. Early backlash from residents and police officers from the announcement is that officers will begin enforcing more traffic violations than they have in the past since more violations means more money for them. Department officials later stated that officers will not change the way they decide to enforce the laws. They just want to incent officers to appear in court more to prevent cases from being dismissed. 
Why is it we often don’t get objectives right? Leaders conduct their general business, approving and kicking off initiatives with good intentions to make people, systems, structure and processes better. However, when it comes down to the setting of objectives we are often crippled during the latter stages by misalignment between objectives, deliverables and performance. The setting of objectives is also impeded by limited organisational readiness, change management, scope, economic drivers, time, and resources. Correspondingly, success tends to be emphasised by the “delivery on time and within budget” mantra.
The benefit of using this approach for business leaders is self-assurance in setting a clear vision with reliable measures for performance; and traceability from strategy through to delivery. A good alignment between SMART objectives, solutions and benefits will empower business leaders to make informed decisions and measure performance with confidence.
A year ago I wrote the blog