The Modern Analyst Blog for Business Analysts

Adrian M.
Adrian M.

Agile - the way I like it...

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 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
He calls this The Post-Agile Manifesto (disregard the toilet – I haven’t figured that one yet). For more, here’s a Post-Agilism FAQ.
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.
The reality is somewhere in between the Traditional Methods and the Agile Manifesto with:
Since this month’s eJournal issue is on Agile – let’s get back there!
Is Agile bad?
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
PS: Are you scared of Agile? 
      Disgusted with Traditional methods?
      What’s on your mind?
      I’d love to know!
This entry was published on May 11, 2009 / Adrian M.. Posted in SDLC, Process, and Methodologies, Agile Methods. Bookmark the Permalink or E-mail it to a friend.
Like this article:
  2 members liked this article

Related Articles


charmy posted on Thursday, May 14, 2009 12:46 AM
I have worked both with the traditional method as well as the agile method. And both the methods have been successful with respect of delivering valuable software to the customer.
Good thing of traditional method is it gives you enough perfect structure to visualise the system before you actually start the software developement. Good thing about agile is customer is involved in the process right from the start, so by the time the product comes out he/she is well versed with how valueable the software will be.
Justin posted on Wednesday, June 3, 2009 5:38 PM
Hi Adrian

I certainly agree for what you have mentioned, i would say a perfect combination of both the processes( agile and traditonal) has proven atleast for me to be successful. I personally feel being biased to one process just because it worked of one or couple of people doesnt justify for being efficient and other lacking , which referes to your comment: " If it works, do it " cant get any better than that. Oh btw let me introduce myself i am Justin i just joined the blog today so a sincere hello to all of you mates.

I know this might not be the point of discussion for this month, but lately i have made a decision to take the IIBA certification. I was wondering if may be anyone of you here could kindly put me in direction in terms of where and how i can take this certification( online), and by any chance if anyone of you have already taken or currently undertaking the certification, would help me suggesting or share the manuals or reference books that i can use for my certification. hope you all have wonderful day

cheers mate
Tony Markos posted on Tuesday, June 9, 2009 6:24 PM
To me, agile seems largely to be just sound bites. Take for example the agile mantra "model just enough". That is not good enough. The essentials of functional modeling have been identified for many years: Inputs/process/outputs. Why can the agile crowd not get specific about what the essentials - the unchanging "just enoughs" - of a functional model are?

Sound bites, while catchy, are dangerous because they retard logical thinking. While agilists espouse on one hand "model just enough" , they also largely espouse functional modeling techniques (most noteably use cases and activity diagrams) where the essential inputs and outputs are ignored.

Tony Markos
gbcambridge posted on Thursday, January 28, 2010 5:06 AM
here is my rather late comment for what it is worth.
This is a good subject to get a rant going... but it really does need some cool-headed analysis if we want to progress.

Firstly, the pragmatic approach of "if it works, use it".. is fine, but ignores the fact that we might all be doing things so differently that we have a multitude of non-standard methods in use. So, there should be a corollary of "standardize where ever possible", in all domains.
Secondly, the definition of Agile and Waterfall seems to vary according to the audience. Broadly I have ended up with defining Waterfall as a broadly planned and sequential process, and Agile is not! I have never had the misfortune to work in organizations whose view on projects were so rigid as to prevent the use of whatever best practices were appropriate for a project. So, embedded customer, staged and incremental releases within a so-called Waterfall project, were all normal.... if they helped.
The suitability of management techniques also depends on the type of project, the organization and ultimately the level of risk of the project (and this would take into account the skill-levels of the staff,the involvement of the client and so on). Hence the management method should be selected based on these criteria...not made dogmatically. Management Fundamentalism is probably something to avoid.

I think the arguments about Waterfall vs. Agile are misplaced and just a little extreme. We are arguing about the meaning of labels! What I think we should have is a set of management principles, clearly spelled out for our projects and which are supported by one or more "proprietary" methods, according to the specific project needs.

Now, to get a discussion about the basic principles of Project Management would be of real value.... IMHO!
Only registered users may post comments.


Blog Guidelines

» What is the Modern Analyst Blog and what are the Benefits of Contributing?

» Review our Blog Post Guidelines.

» I am looking for the original Modern Analyst blog posts. LinkedIn Group on LinkedIn: connect with fellow business analysts in order to develop and expand your professional network.
Learn More...

Copyright 2006-2024 by Modern Analyst Media LLC