Agile for Business Analysts

Posted by Robert Merrill on March 2, 2010 under Agile BA | Be the First to Comment

I finally got around to conducting a half day of training for some local colleagues who bear the title “Business Analyst,” and whose organizations (and in some cases careers) had been shaken up by the arrival of the Agile Methods (most commonly Scrum) in the Early Majority. There were only four of us all together, so it was delightfully conversational.

Here’s what the whiteboard looked like when we were done. (Click for a full-size view).

We started out by describing our own encounters with various Agile practices and knowledge of Agile methods in general.

I explained my concept of the Load-Bearing Walls, and shared my opinion that the ignorance, or politically-forced disregard, of these is going to lead to the failure of many Agile initiatives in Early-Majority adopters.

This led to a discussion of the concept of technical debt, and how it presents itself to the non-technical parts of the organization. Automated testing is the key to technical debt management on an Agile project, and can be a point of resistance. On the business side, I’ve sometimes successfully countered the assertion that it’s “extra work” by likening it to double-entry bookkeeping.

I also tried to convey the “feel” of an Agile project to the non-technical people. On a Waterfall SDLC project, the turbulence starts low and rises sharply at the end. On an Agile project, the turbulence starts relatively high, rises to a peak through the first iteration, and then steadily dissipates. Being in the middle of helping two clients set up Agile projects, one for the first time, this feeling was fresh in my mind. I can understand the angst of those new to Agile. “If this project is this bumpy at the beginning, what’s it going to look like at the end!” I always explain the turbulence curve, and remind people that this is a stage we’re passing through, like the Storming of the “Forming-Storming-Norming-Performing” sequence of team formation. Many non-technical people are familiar with this model, and it seems to help them ride out the turbulence.

We then touched on some general Requirements Analysis concepts I have found useful. Even Agile projects benefit from an initial product backlog, or user story set, that isn’t full of gaps. I drew the “Requirements Merry-Go-Round” of

• User stories (functionality),
• Logical data model, and
• Wireframes (user experience),

and explained, “You jump on wherever the customer wants to start, but you have to go around at least twice” to find the gaps. Every entity in the LDM must appear in at least one user story, and must have a known source, either in another story, or from another system. The user stories should be traceable through the wireframes, and every wireframe must fit into at least one story. Finally, each entity must appear on at least one wireframe, whether for entry (a form), or viewing, or both. I explained how I had learned this technique while learning Function Point Analysis, and that if you stick to a low level of detail (whole entities and relationships on the LDM), it can be done very quickly. This follows another Agile principle I emphasized, that of diminishing returns.

We finished with a user story and functional test template, and practiced writing a few stories. We also ran an idealized version of the Agile “planning game” of

• Relative effort estimation by the implementors
• Prioritization by the users and people who write the checks
• Initial commitment based on the implementors’ subjective judgment, and
• Subsequent commitment based on extrapolation, not estimation.

I explained that the concept of variable scope was often another major point of resistance, even though it fit well with the reality of highly utilized software developers, uncertain initial requirements outside an obvious core, and the tendency of release dates to acquire a symbolic significance among senior management (and sometimes a very real business significance as well). This led us back to a Bob Martin quote from early in the talk, about “Abandoning the illusion of control at the beginning” of a project as being integral to Agile and also a stumbling block.

Throughout the presentation and conversation, I emphasized the importance and value of Business Analysts, not because of the deliverables they produce (which are fewer and less weighty on Agile projects) but because of the combination of analytical and people skills that they typically possess. On Agile projects, I usually find myself

• Analyzing initial solution concepts and finding missing stakeholders
• Facilitating requirements workshops—taking sponsors, subject matter experts, and developers through a couple of turns on the merry-go-round
• Analyzing the results and adding missed stories to the product backlog (feature list)
• Leading “estimation parties” that don’t just put points on the stories, but also help jell the business and technical people into a combined team through a story-by-story dialogue, and
• Calming everyone as the turbulence rises through project set-up and into and through the first iteration

It isn’t that these things must be done by a person with the Business Analyst title—that’s contrary to the agile principle of specializing generalists, and makes the project more brittle—it’s that these things are often done most effectively by people whose talents, skills, and experience have led them to the Business Analyst role in pre-Agile days.