Aug
23
Agile Processes and the BABOK
August 23, 2006 |
One of the criticisms of the current version of the BABOK(tm) that seems to crop up a lot from supporters of Agile development methods is that the current text indicates a strong bias towards traditional, waterfall, CMM-style development.
We will be trying to address that in future releases.
Some of our members have a strong dislike for Agile methods. I have reservations about them myself (and I plan to get back into discussing those). But in a real way, it doesn’t matter what I think. The BABOK describes those approaches to business analysis that are “generally accepted”–meaning that a significant percentage of authorities in the field and practicioners consider those approaches valid. “Generally accepted” does not require a majority. In my view, Agile software development has enough support to qualify.
BA practitioners are, of course, free to argue for or against any approach to requirements they like. Just because we put it in the BABOK doesn’t mean you have to agree with it–it just means you need to understand it. And on that note, I think understanding Agile development, and the reasoning behind it, has advantages even for those of you who will continue practicing traditional development.
Comments
4 Comments so far
What I'm Reading- Do You really Believe in What you Do?Requirements Defined - Seilevel's Software Requirements Blog
- C.R.A.C.K. Requirements managersBetter Projects
- ‘IT has no inherent value’IT Project Failures
- Business Analysis in an Uncertain EconomyJonathan Babcock
- Why We Lost Focus on Development PracticesAgile Management Blog
- Talking about what we doRequirements Defined - Seilevel's Software Requirements Blog
- BPM is not Software EngineeringGo Flow
- 3 Big CaliberRM Gotchas And How To Fix Them Part 1Requirements Defined - Seilevel's Software Requirements Blog
- Project World and World Congress of Business Analysts (PW&WCBA)Better Projects
- Troubled ProjectsHerding Cats
A better argument than ‘agile vs waterfall’ may be ‘iterative vs waterfall’. There is plenty of empirical evidence and real project data backing the notion that projects based on an iterative approach perform better (i.e. happy stakeholders) than those based on a waterfall approach. Personally, I hope that iterative development, whether RUP or Agile or adhoc, is becoming the generally accepted approach.
“Generally accepted”, in the context of the BABOK, is not an endorsement of a practice by the IIBA. It just means that it’s something that enough people are doing that we feel BAs should be aware of it.
I was recently at a presentation by Ivar Jacobsen where he presented his new framework for software development, the Essential Unified Process. He’s trying to establish a framework where the different practices embodied by RUP, Agile, and CMM can be incorporated under a single meta model. He does this by identifying a series of “practices” and incorporating these practices together to form “processes.”
So, iterative development would be considered a single “practice.” Iterative development doesn’t solely belong to the Agile development methodology, though it’s one of its main characteristics. Other “practices” would be things like Use Case Driven Development or Architecture Driven Design. Each of these practices is a discrete body of procedures and artifacts. I think this componetized way of looking at the various roles and activities in a software development is a very practical.
Jacobsen also breaks out the “social engineering” aspects of the Agile methodology - and really, that’s what makes Agile what it is. The practices that make up Agile methodology aren’t unique. It’s the social engineering aspects of pair-programming, stand-up meetings, etc… that make it a methodology.
So, I think that the BOK should focus on the various practices and techniques utilized by business analysts in performance of their duties. It’s only when these practices are combined together into a process with a layering of social/organizational engineering do you actually get a methodology. The BOK should be fairly agnostic to all the different methodologies employed.
If the BOK looks a bit light on Agile Methodology, I would suggest that this is because the Agile methodolgy is a bit light when it comes to activities performed by analysts. The analysts I know who work in an Agile environment have struggled to define a role for themselves. Basically, if the BOK reflects most, if not all, of the practices performed by analysts in the Agile methodology, then I really don’t think they can claim a bias. There’s simply more for an analyst to do in other methodogies - more techniques and practices to deploy.
This is a very worthwhile and timely thread. Individuals who function in specific roles, whether business analysts or those who write code, often lose sight of the larger picture. There are many worthy ideas coming from the Agile community. It would be unfortunate if current efforts to define a BA body of knowledge did not somehow finds ways to connect with these trends.