So the current buzz word right now is Agile and it is used in so many different ways to represent so many different things that the industry is in an absolute tailspin over agile. So let's take a moment to separate fact from fiction.
FICTION: Agile means we don't need to do any documentation.
People that advocate this type of Agile Development are taking us back 10 – 20 years when the customers talked directly to the developers. It didn't work then hence the advent of the Business Analysis profession, so I am not sure why people think it will work now. There is still documentation, it is just a matter of focusing on value-added documentation rather than documenting laundry lists of must haves and shall haves.
FICTION: Agile means we don't need a Business Analyst?
The role of the Business Analyst is even more critical on Agile Development projects because the need for upfront analysis and continued management of the requirements is an absolute necessity. Agile Development projects require rigorous planning in the beginning so once you get into the iterations of design, development, and test, the team is simply executing against the plan. In addition, the Business Analyst has to be ever vigilant in managing scope and new requirements for each iteration or release. It is important the BA continues to do analysis and determine the feasibility of the requirements as well as document requirements as the evolution of the development cycle continues.
FACT: Business Analysts' need to be more adept at deciding what artifacts to use for different projects.
This is absolutely true. Gone are the days of 400 page requirement specifications (I wish I was exaggerating). Business Analysts' need to have the ability to assess a project and decide what artifacts will add value for that project. In this way, the BA will become more agile by default and will only use documentation techniques that help the project team deliver results.
FICTION: The Agile Development Methodology will solve all our problems.
As with every methodology there are pros and cons to utilizing this approach.
|
Pros |
Cons |
|
Receive feedback from the customer in a more timely manner |
Agile is most successful when teams are located together; difficult for dispersed teams |
|
Better collaboration |
Can allow for significant scope creep (if not managed carefully) |
|
Identify "defects" or changes to requirements early on |
It will fail without management buy in |
9 Comments
I agree with everything.
Except this
“Agile Development projects require rigorous planning in the beginning so once you get into the iterations of design, development, and test, the team is simply executing against the plan.”
Please tell me that you wrote it just because you wanted to have 2 more lines in the paragraph.
The only plan a team should have is
“We plan to do our best to add value to our customers continuously while (of course) maintaining a profitable business relationship”
Akshay thank you for your input. The primary point I was making with my statement was that even on Agile projects you still need to do Iteration 0 (or planning). Iteration 0 typically includes Stakeholder Analysis, Scope Definition, Solution Decomposition, Informal Models, and Reference Models. Please see an article in the Spring 2008 version of the bridge by Jacqueline Sanders. I have supplied the link.
http://www.b2ttraining.com/files/b2t/docs/theBridge-spring2008.pdf?rand=228570
It is a common misconception that if you are doing an Agile project you don’t need to do upfront planning.
Ashkay’s comments highlight the challenges of addresing this topic. Let me add three more comments of my own.
1. BAs are not required for all types of agile projects.
In fact if the developer team have the skills, why not let them out of the back room onto the shop floor? Why put middleman into the conversation?
How you address requirements management depends on the project, the people and the organsiation. BAs are not always required. (Nor are programmers.)
2. Iterations mean you don’t work to a product blueprint.
If you are a BA assigned to an agile project your most likely mistake will be to model an end state (at least in your head) and then work towads that. This is pretty much contrary to the whole iterative approach.
There is a fundamenatl value in the agile philosophy that says if we design a product today we will probably get it wrong. So don’t. (The phrase that is disparagingly used is BRUF.)
In many stable markets – such as governement – this is not true, but in environments where thre is significant shift in business requriements over time, it is very important to understand.
3. You will probably not work on a pure agile project.
The world isn’t black and white. And you don’t just pick Agile or Waterfall approaches. In the real world you usually mix it up, pulling techniques and tools from a range of methodoloies and frameworks to address the specifics of your project.
The approaches us enterprise workers will usually take is a compromise – some of the strengths of agile and some of the strengths of a plan diven approach.
Part of this creation of a hybrid approach is because we think about the situation and design an approach that is appropriate to the cirumstances. Part of it is becasue of a natural conservatism in large organisations.
(And I think that at this stage of the Agile methodology maturity we don’t know whether this will be a compromise or an enhancement to the agile models.)
Hi Kim
I try to apply your comment about deciding what artefacts to use on ALL my projects (mostly NOT Agile). Sometimes you don’t have a great deal of flexibility on the artefacts but I always like to ensure I understand what is being produced, to what level of detail and that it is appropriate to THIS project at THIS stage.
Even if a document is mandated by the organisation’s process, I still like to understand why it’s considered valuable and ensure that it delivers some value for the project.
Alex
Iteration 0 is used for setting up infrastructure so that the development can start in Iteration 1 and result in working software at the end of it.
It is used to address issues like Development, QA environments, network connectivity (VPN, etc) required to connect to component systems and to gather more detail on the stories to be played in the Iteration 1.
It is a common misconception that agile doesn’t do upfront planning. But if the plan was to plan and make the team stick to it, it would hardly be called agile would it?
A team executing against a plan is an overwhelmingly wrong perception of what agile is. And I hope that it’s a perception, because if you’ve actually done this and called it agile…
Within the agile methodology there is still room for ‘blue print as a framwork”, Iteration 0 for planning and the BA role. The purpose of these components is not to design an end product on the front of the project lifecycle and then build to that blue print. But these elements are needed to make sure the end solution is cohesive and the results of multiple iterations integrates. When the results of the iterations become disjointed then costly rework has to be done at some point in subsequent iterations. The BA role as a facilitator of communications and the agile methodology helps to avoid time consuming rework. It should be acknowledged that the BA adds value other than producing documentation.
Agree with Jaqueline here. Good points.
I would like to pick up of Craig’s comment:
“How you address requirements management depends on the project, the people and the organsiation. BAs are not always required. (Nor are programmers.)”
I agree with the sentiment, mainly. However, I think there is a little confusion between people and roles. I would hate to work on a project, agile or waterfall, where requirements are not determined and determining the requirements is part of the BA ROLE whether that is done by a different PERSON to the one who does the development or not.
Helen has hit the nail on the head. Thank you, Helen, for your insight.
It’s unfortunate that so many people get wrapped around the “title axle”, assuming that nobody has to do business analysis since Business Analysts maybe aren’t mentioned in the agile team role list.
Somebody is doing business analysis somewhere in the project, whether it’s a developer or somebody with a title that may be reflective of the role. Developers MUST use BA skills to properly elicit what the customer wants. Iteration 0 MUST have somebody exercising BA skills in order to determine at least a top-level requirement list, otherwise you have people developing a really cool software tool that they THINK meets company needs, but that, in the end, does absolutely nothing positive to the bottom line.
To quote Akshay:
“We plan to do our best to add value to our customers continuously while (of course) maintaining a profitable business relationship”
Try doing that with no top-level plan derived from accurate business analysis.