by Adriana Beal

Here are 3 types of comments I frequently hear from BAs that at least in my eyes make them look inexperienced or lacking critical thinking:

“I’ve started to use agile and it’s so much better than waterfall. I am never going back!”

Problem with thit statement: What isn’t better than waterfall? This type of statement shows ignorance about a multitude of non-agile, non-waterfall methods that have been in use by the software development community for decades before the term agile was coined (if you don’t know any, research IID – Iterative and Incremental Development).

You may have been one of the unlucky BAs stuck in an waterfall model before experimenting agile, but that doesn’t mean the software development world is composed of just these two opposing models, and thus if you are not using agile, then you are practicing waterfall.

A remark of this nature will make you look naive when talking to more seasoned professionals who have been exposed to different methodologies and understand the value of studying and applying a diversity of methods that are available to support software development initiatives, in no way limited to what is prescribed by the waterfall model or agile approaches.

Read also: Traditional vs. Agile: The Future is Hybrid

“Best practices don’t stay that way forever. They change over time or even discarded.”

Problem with this statement: It completely disregards the fact that many “best practices” (which I prefer, like many others, call “good practices”) are context-dependent, meaning, a practice may be extremely successful in certain situations, and not applicable at all in others. Even though some practices may become obsolete, and be replaced with better approaches, in most cases when a BA says that best practices change over time, he/she is actually trying to convey that they’ve experienced different circumstances under which certain practices would add value or not.

For example, in a project involving multiple development teams geographically dispersed, the practice of creating a requirements document for an upcoming feature may be extremely important to ensure a common understanding of changes that will be applied in the system affecting those different teams. On the other hand, a small project involving a single product owner and a small number of developers who are implementing a feature as they talk directly with the product owner, writing textual requirements for the feature may be completely unnecessary and time wasting. A good practice in this second scenario would be to make sure the feature is documented right after it has been implemented and accepted by the product owner (for knowledge-retention, testing and maintenance purposes).

The first practice (writing requirements documents) doesn’t become obsolete only because it does not fit the second scenario. Treating “best practices” as context-dependent is much more realistic than approaching them as “universal truths” that should be retired once you face a situation to which the practice does not apply.

Read also: Methods are a means to the end of project success, not the end themselves

“By providing just‐in‐time requirements, there is less rework of requirements because only the requirements required for the current release are defined in detail and developed.” (IIBA: The Agile Extension to the BABOK – p. 3)

Barry Bohem, in “Architecting: How Much and When?” (Software: What really Works and Why We Believe It - Andy Oram and Greg Wilson. O’Reilly, 2010), provides solid evidence that projects of different levels of complexity require different levels of initial requirements and design effort. Generalizing to say that JIT requirements is always better goes against scientific evidence, and will make you sound naive.

Many experienced BAs agree that it’s important to keep the balance between looking ahead and focusing on the current or next increment.

Business analysis is central to the success of software projects, regardless of the methodology used. In this presentation Adriana Beal discusses the emergence of hybrid approaches that combine traditional and agile
practices, the key role BAs play in more complex agile environments, and how analysts can leverage traditional BA practices to improve the results of agile-inspired projects.

Slides from the talk for the Austin IIBA Chapter on Feb. 17 2012

Download: agile presentation adriana feb 2012