This month’s eJournal issue is about Agile and the Agile Business Analyst with a couple of great articles by Ellen Gottesdiener and Scott Ambler exposing upon the agile side of the business.
At ModernAnalyst.com we try really hard to showcase editorial content which is relevant, educational, well balanced, and thought provoking. For the most part, as an editor, I try to stay on the sidelines when it comes to controversial topics such as the Agile vs. Traditional methods.
Yet today I couldn’t resist chiming in! Ouch!
I tend to be a middle of the road guy and, in general, I try not to get stuck on any one of extremes – regardless of subject or topic. My belief is that if it works for me then I’ll continue to use it and I also strongly advice you that if it works for you then you should continue to use it – whatever it is.
But Jason Gorman puts it my better:
- If it works, do it
- If it works, it works
- If it seems to work, it probably works
- If it seems to work, it probably works – and might work again
The idea is that fanaticism is not a good thing on either side of the fence. Some agilists when they hear of waterfall projects which succeed, claim the team must have used agile and gave the process a wrong title. Traditionalists who witness successful agile projects call them hacks destined for eventual failure.
As a business analyst, trying to make sense of it all, you might find yourself thinking “agile is bad” because there doesn’t seem to be a well defined role for the BA on an agile team or, perhaps, you’ve started your career as an agile BA and cannot comprehend while anybody in their right mind would want to write a 100 page requirements document.
Unfortunately, the debate between agile and traditional software development processes is alive and well with both side of the camp continuing to fire salvoes at each other.
The truth, as I see it, is probably somewhere in between - as I’m sure you’ll find examples of success stories where:
- Agile methods were used to develop large-scale applications,
- Traditional methods were employed on small projects,
- Agile teams utilized use case narratives,
- Traditional teams created user stories to document requirements,
- Etc.
Since this month’s eJournal issue is on Agile – let’s get back there!
Is Agile bad?
No.
However, the type of agile movement that I like is the one that realizes that “agile” is not the end goal.
Creating value is a good goal.
Solving business problems is where it’s at.
Getting the job done is what’s important.
If it works, use it – whatever it is!
Do not be afraid to use what works, don’t shy away from learning something new, and keep on improving our profession and craft regardless what the end process/methodology may be called.
- Adrian
Adrian Marchis
Publisher, ModernAnalyst.com
PS: Are you scared of Agile?
Disgusted with Traditional methods?
What’s on your mind?
I’d love to know!