Marcos Ferrer, CBAP has over 20 years experience in the practice of business analysis and the application of Information Technology for process improvement. Following graduation in 1983 from the University of Chicago, Mr. Ferrer joined IBM in Chicago, where he worked on requirements and systems implementations in diverse industries. His recent projects include working requirements for the Veteran's Administration, introducing BA practices at the Washington Suburban Sanitary Commission, and creating bowling industry models for NRG Bowl LLC. In November 2006, Marcos Ferrer is one of the first CBAPs certified by the IIBA. He has served as an elected member of the DC-Metro chapter of the IIBA, most recently as President, and assisted in the writing of the BOK 2.0 test. 
This is NOT another Agile Methodology posting. I make no claims to any special agile expertise, nor am I interested in methodology wars. I just want to say that fads are fads, and never substitute for analysis. I completely understand the attraction to agile. It is an excellent summary of what can work for some teams, on some projects.
It is my observation that all the named methodologies I have run into can map onto BABOK concepts, and the BABOK is a superset of them.
Here is the manifesto itself for context (derived from the Agile organization's own web site at www.agilemanifesto.org ):
Manifesto for Agile Software Development
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
1. Individuals and interactions over processes and tools
2. Working software over comprehensive documentation.
3. Customer collaboration over contract negotiation
4. Responding to change over following a plan
That is, while there is value in the items on
the right, we value the items on the left more.
---------------------------------------------------------------------------------
And here is one analysis, based on general knowledge, personal experience and BABOK concepts:
-
BA Fundamentals (and hence the essential skills to perform Requirements Communication) have to be present before tools matter. Tools can only support competent, effective behavior, not create it. In a sense, all successful projects are "agile" - it is my observation that all successful projects are full of brilliant individuals who interact fast and freely. This single factor seems to compensate for everything else - counterexamples are welcome, I don't have any.
-
Software over documentation is already the most common approach in software development, so it is hard to understand why it matters to "Agile". Since 65% "failure" rates are already being achieved in software development, it must be items 1, 3 and 4 that really matter, if Agile is effective at all.
-
Substitute "Iteration of Requirements with Stakeholders" for "Customer Collaboration", and substitute "waterfall requirements" for "contract". Contracts, at their worst, are an attempt to "lock in requirements" before they are understood, leading to excess change order profits for the contractor (when changes are allowed), or failed stakeholder acceptance (when they are not). Waterfall requirements are best saved for "one shot" efforts like the moon program.
-
Over planning, and reluctance to adjust plans as requirements are "learned", is clearly a cause of certain project failures - it is mostly a failure of intelligence (see item 1). What is missing from this concept is the idea of Enterprise Analysis (especially risk analysis, stakeholder analysis, and cost benefit analysis) and the Requirements Planning that must follow from these. Another way to put this is - IF the project is simple and low risk enough, Agile may be a fit (see BOK tables 3.0 and 4.0 in the Enterprise Analysis section, and see if you can spot which projects might use Agile.
SO, from analysis to opinion (if you have your own opinion, send it in, we will tally responses and report on same):
IN MY OPINION: Agile process fits certain kinds of projects, but hardly most. Here is my list - what is yours?
"Small potatoes" - low risk, decent to high payback systems that only have to satisfy a small number of users with homogeneous interests, have low visibility, or represent proven, successful increments to already successful systems (yes, maintenance and enhancement).
"Feasibility" or "Proof of Concept" trials, which could clear the way for more investment in a larger project?
"Research" projects, where almost all is unknown, budgets are huge, and the paybacks considered indispensable, if they can be achieved at all. These are really rare; one example was the "skunkworks" team that developed the unique (and ultimately unsustainable) Blackbird spy plane.
"Invention" projects for systems that can succeed "virally" and evolve, that represent completely new behaviors ,or huge boosters to behaviors, that people crave, regardless of how poorly delivered (e.g., cell phone service, social networking, 45rpm records).
WHAT AGILE PROBABLY DOESN"T DO is Enterprise level projects, projects that must organize the efforts of many people. I am sorry to say that I hold this opinion in spite of the fact that I helped lead just such a success - an Investigation Management system for over 1400 government users. We succeeded by using all four principles in the Agile Manifesto, AND this only worked because we were an A-1, Agile Item 1 team.
My advice - get the smartest team you can that actually CARES about their work, and put them under tremendous pressure - they will cut to the bone, and will NOT skip any critical steps, and you can call it Agile if you want, but I call it B.A.gile!
More shall be revealed. Keep the feedback coming to marcosferrer@verizon.net.
Have fun!
written by Francois Combrinck, February 18, 2009
I must agree. I have found that Agile also works very well with system maintenance projects where the development team know the business environment very well. In these cases, the team might not even need a BA.
Finally, it needs to be said that the Agile People themselves say that Agile only works for small to medium co-located teams. So yes, Enterprise Level projects using Agile Methodology is asking for bit too much trouble.
-
- +0
-
-
written by Charles Agu, February 18, 2009
-
- +0
-
-
written by Angela, February 18, 2009
In my experience people tend to think that in order to be "agile" you must follow all of these specific practices for example, co-located teams, little to no documentation, etc. In my opinion if you have an agile mind set, do what works best or be flexible and adaptable, then how can you not be successful?
-
- +2
-
-
written by ryan forsberg, February 18, 2009
"I often wonder what problem is trying to be solved by iterating in the code/test part of the
software lifecycle. In the book, Hitchhikers Guide to the Galaxy â€hyperintelligent
pandimensional†beings got fed up with the question of the meaning of life, so they built
a super computer the size of a small city to answer the question. It took the super
computer seven and half million years of calculating the answer to the ultimate question
of life, the universe, and everything. The answer was “42.†The problem is the builders
did not know the exact question.
The code/test iteration is not much different than 42. Incomplete requirements are the
biggest issue facing software development. I guess it is clear to the Agile folks that it is
only logical to spend more time coding instead of cleaning up requirements or writing
concise requirements in the first place.
They believe trial and error is the best method to gather and communicate requirements.
As they say, developing a “working product.†It is clear they skip the study of the
customer problem and focus where they are comfortable which is on the code. They
hope to solve the customer problem by trial and error. The problem with trial and error is
you are going to make a lot of errors along the way."
Excerpt from:
The Agile Method and Other Fairy Tales
By David Longstreet
http://www.softwaremetrics.com/Agile/Agile Method and Other Fairy Tales.pdf
-
- -1
-
-
written by Quentin R Suskin, February 20, 2009
Frankly, I am constantly surprised at the lack of importance placed on good documentation, esp requirements.
If you don't know what you want, how will you ever get what you want (to put it simply)?!
I think the problem is that often documentation is taken to the Nth degree of perfection before proceeding with any development. This is unnecessary (consider the law of diminishing returns...), and I believe has resulted in this backlash to the other extreme where documentation is considered almost unnecessary and a barrier to implementation.
In reality, business analysis is a process designed to assist projects to avoid failure. What we all forget is that sometimes (i.e. small projects vs. large), the process should be cherry picked for what is appropriate and relevant given the size and complexity of the project.
In other words, make the process work for the project you are on.
-
- -1
-
-
written by Kathy Martino, February 20, 2009
I thought that remark was spot on.
Read the article: http://www.networkworld.com/ne...tml?page=1
A not so obvious component I think missing from Agile is Adaptable Technology. That is, software components and databases being designed flexible enough to respond quickly to change, otherwise developers just seem to be working faster and harder (not smarter) in response to change.
Agile Projects: those with requirements and business goals that change frequently because of market conditions and vendor changes. Companies need to respond quickly to market and vendor fluctuation to remain competitive and in business.
All other projects fit somewhere between the Agile approach, or version of it, and whatever works best for your company, culture and goals. In my practice I have always worked with individuals and collaborated to build software and revisions, and I consider myself to be pretty agile in the face change without the Agile label. It all rests on how flexible the technology can be made, how creative the people are (individually and together) and how good is the understanding of the environment (people, process and information).
-
- +0
-
-
written by Greg Busby, February 25, 2009
Marcos, agree very much that having a smart team that cares will solve nearly any problem, as long as the methodology doesn't get in the way.
-
- +1
-
-
written by Michelle Gehrig, March 02, 2009
I've recently been through 3 successful enterprise level projects where the documentation was "just enough documentation". I'll admit - it was a struggle to get buy in that the level of documentation was sufficient but by remaining collaborative with both the business and the IT teams - the projects were successful. The volume and detail of documentation needs to make sense for the project and for all concerned.
-
- +0
-
-
written by Gurdip Singh, March 04, 2009
The word Agile is a fad and probbaly crept into BA or project space from the "Developer world" space. The latest BABOK also specifies clearly (section 2.2.4) that for "Agile" to work there are lots of factors. I think people matter as well as processes to make a project sucessful. If the environment is very big and formal processes are supposed to be followed, some agile/smart poeple can't come and change the whole working culture of the company. Agreed they may be sucessful also but then processes gets defined taking into account that what are the risks involved in adopting this approach. It is practically difficult to be agile when stakeholders are geographies apart and resources are scarce. I mean how will agile work for involvement of architects/business-people in a company which has many projects running in parallel and in each of those their involvement is required.
-
- +0
-
-
written by Donald Tardif, June 15, 2009
I don't believe in Santa but I still use him to yield appropriate behavior from my kids.
-
- +0
-
-
Just for fun....
The Agile core values from the perspective of a Software Development Company salesman (with a G.W. Bush accent).
1. Individuals and interactions over processes and tools
"...processes are complicated...we believe the customer comes first and we want to involve you throughout the entire process .... "
2. Working software over comprehensive documentation.
"... we are not going to bore you with complicated diagrams and long winded maintenance documentation - nobody reads that stuff anyway. We are going to build what you tell us to build... "
3. Customer collaboration over contract negotiation
"Let's not worry too much about what the final product will include. We are going to build as much as we can...."
4. Responding to change over following a plan
"Planning and change are like water and oil. I'm an oil man (huh) so we're just gonna fly by the seat of our pants on this one..."