In the cool logical realm of technology, we find no shortage of passionate “movements” that take on the fervor of religious wars or fanatical political ideologies.
Mac vs PC was the big brawl back in the 80′s. Then it was Java vs Microsoft. And then we had the web browser wars. And then the Human / Cylon wars. Oh wait, that’s the SciFi channel. Now we have Android vs iOS. (a quick search yields over 24 million entries). But of course, it’s never really about the technology per se, it’s about the values behind it. In the above examples, it really comes down to a battle between different business models.
In the even more insular world of the Software Development Life Cycle (SDLC), a debate of near equal fervor has been brewing for a decade or more now, and the business analyst has been caught in the crossfire. I’m talking about the world of waterfall vs agile, of traditional top-down “Big Spec” driven development vs the wily iterative circular one that builds, destroys, rebuilds and destroys, and rebuilds again. A quick search yields over half a million entries. And if you don’t think these Agile folks are serious about their revolution, read their Manifesto!
So, what’s at the root of this debate between waterfall and agile? What are the values or business models underlying each that are so in conflict, and more importantly for us business analysts, what do we stand to gain, or to lose, should we find ourselves working in one environment or the other? These are the questions I posed to my guest, Ellen Gottesdiener of EBG Consulting Group, Inc., for this episode of my running series on Building BA Maturity.
First, let me brag on Ellen a little. I heard her speak at Building Business Capability 2010, last year in Washington, DC. She was stumping on the topic of “Nonfunctional Requirements: Forgotten, Misunderstood, Neglected”. Ellen has produced two great resource books for BAs – her first title, Requirements By Collaboration about facilitating great requirements workshops, and her 2nd called the Software Requirements Memory Jogger, which is used by analysts worldwide as a study tool for CCBA and CBAP exams. Reading her thoughts is great, but to experience Ellen speak in person, is a treat. In short, Ellen is not only a thought leader in the areas of collaborative requirements gathering, she’s a very talented trainer, presenter and educator. And any chance you have to hear her, go for it.
Who’s right, the Waterfallians or the Agilistas?
Although I suspect Ellen harbors an inner revolutionary Agilista, she says she’s ultimately a pragmatist. ”There are elements of traditional analysis that are useful in agile contexts, and agile approaches that are very beneficial in the traditional environments,” she says. Interestingly, she points out that Waterfall as it’s defined today is actually a misinterpretation of Winston Royce’s original idea (from whom we get the notion of waterfall development). ”Royce himself came to a modified, much more like agile approach, in his final version of Waterfall” says Ellen. And indeed, the Wikipedia entry on waterfall, confirms that point.
So, then, what is it? What really defines Agile? Ellen describes it as an umbrella term that encompasses these main concepts:
- Partnership between Business, Customer and Technology
In a certain sense, this has always been the case, but Agile levels out the field so that this becomes a more equilateral triad.
- Collaboration as the primary means of discovery, design and build
What should be built? And why, and when? These are problems best solved through team collaboration. Read Ellen’s book Requirements by Collaboration for a masterwork on group problem solving methods.
- Recursive in nature
Meaning, no step of the process (plan, design, build, test, deploy) gets away unscathed just once. Artifacts get repeated attention and further refinement as they cycle back each time, and the deliverables of each iteration/timebox/sprint (synonyms for ‘chunk of development time’) are essentially slices or portions of the final product.
- Tolerance or even embrace of Ambiguity and Uncertainty
Not knowing exactly where a product is headed at first is a given. Allowing the solution or product features to “emerge” over time is the hallmark of this approach.
- Primary role of Feedback and Retrospection
Ellen loves the notion of “retrospective” ably popularized by Norm Kerth. Agile builds retrospection into every iteration or release, so that feedback goes to the whole group for further improvement. Feedback also comes from prototypes, inspections, quality examinations as well.
If that’s Agile culture, what it’s like to BE an Agile business analyst?
Ellen describes the role of analysis in the agile context as a ‘team sport’. For some of us, (this author included) that can be a little jolting. Down in the trenches with project team members (developers, stakeholders, managers) crafting requirements together? Hey, who’s in charge here? On the flip side, the requirements burden is no longer solely vested on one BA’s shoulders. Rather it’s shared within a wider group. For a beautiful elaboration of this shift for analysts, check out this article by Ellen and her business partner Mary Gorman, on the role of business analysis in Scrum (‘Scrum’ is one of the formal approaches to doing agile, as opposed to Kanban, Lean, XP, etc.).
If you’re okay with not being the only BA on the project, the rest of the culture, according to Ellen, will rock your world. When I asked her, bottom line, day-to-day, what’s really that different about doing BA work in an agile context? Ellen didn’t flinch.
“You are jazzed every day. In classic waterfall work, you do your requirements and you’re done. In this world, you’re constantly learning, always connected to the business and the value, not working in isolation.”
Okay that sounds good Ellen, what else?
“Waste goes away. There’s no hiding. Every single individual’s work is more apparent, more transparent, and so everyone, including you as the BA, is pushed to the top of your game.”
Alright, that’s sounding very New York, very metro, kinda sexy. Does it get even better than that?
“As a BA, you craft new requirements every day. I like to think of them like a chef putting only the freshest ingredients into the day’s menu. You slice fresh carrots and celery every day.”
Now I’m getting hungry. Tell me more!
“You’re completely and utterly engaged.”
Sold! You had me from ‘Jazzed’ Ellen. I’ll take me two of those Agile sashimi slices to-go please, and thank you very much.
Bottom line, a great BA, in any context, but especially in Agile, holds three intersecting points of view simultaneously. Ellen calls them the Now View (data, dirty details), the Preview (features, story dependencies, impact on next release, etc.), and the Big View (overarching business strategy, goals, value, impact).
The tools of the trade for an analyst working in Agile aren’t any different. The IIBA is working on an addendum to the BABOK to bring in Agile terminology and help orient the BA, but what analysts have done, and will continue to do, is analyze and strategize for the benefit of the business. One of Ellen’s articles that explains this back-to-the-future shift really well is Agile Analysis: Not An Oxymoron. Traditional analysis, and all the tools in our tool belt don’t go away. What we’re going to be doing more of, if Ellen’s right and I suspect she is, we’re going to be doing a lot more of that work in groups and teams, and we’ll be immersing ourselves in areas we may not have tread in before. ”Great BAs will be learning about acceptance testing” she says.
She also says we can up the Agilistas at their own game. Agile analysis can mature as well. Case in point, “User Stories can be abused the way Use Cases have been,” she says. “They were originally an anchor or token for doing release or iteration planning and for having requirements discussions with stakeholders, but they’ve been elevated to the status of be-all end-all of requirements gathering in Agile projects.” But as she points out, good BAs know that the devil is in the details of any feature. Details like data, rules, interface, constraints, acceptance criteria, etc. There’s room for analysts to do a world of good in these areas. Another excellent resource in this regard is the article (available as PDF download) by Ellen and Mary entitled
Ellen describes it succintly;
“Just remember, business analysis in Agile is not about the ‘role’, or the title. It’s about achieving the ‘goal’ of having team members with critical thinking skills, big picture mindsets, and the ability to analyze, so that the highest value requirements are always the ones being fed first to development and testing teams for earliest delivery.”
So my friends, take heart. To borrow from Karl Marx, BA’s of the World Unite – we have nothing to lose but our boredom and BRDs! Or, read one of my favorite BA Manifesto’s , posted right here, by our own Laura Brandenburg. There’s wisdom in those words. It’s not the title, or the role. It’s ultimately, always, about alignment, clarity, value.
Fellow BAs, what do you think, does agile analysis sound like fun? Does Ellen’s portrayal of doing analysis in the agile world ring true for you? Would love to hear about some of your own experiences. Tony Heap shared some of his unique story in a series of posts on this site. What have others experienced? Real stories from the trenches are welcome.