Comments on: Business Analysis: Best Practices for Success – An Interview with Steve Blais

By: Adriana Beal

Adriana Beal — Wed, 22 Feb 2012 13:56:38 +0000

Thanks for taking the time to expand your views, Steve! I am happy to know that we are on the same page on this (as in any other topic so far, heh).

I completely agree there is much analysis to be done when we move out of the room after a good face-to-face requirements session — I have so many examples of rework and unmet needs caused but people thinking that one conversation could take care of all the details. As you say, looking at what is going on in reality with the business process is extremely important, as it is to sit down and apply techniques such as building a decision matrix to make sure all scenarios have been covered (the answer is usually no).

By: steve blais

steve blais — Sun, 19 Feb 2012 21:50:18 +0000

I do indeed agree, Adriana, and love your rephrasing of my sentence. Even user stories and backlog items have to be written clearly and unambiguously. There is a trade-off that is missed many times. I can spend a few extra minutes to clarify my thoughts, findings and requirements and write them so that the business and the development team and anyone else understand them, or we can all get together in a room and spend an hour hashing it out until we all understand. Granted, either way I must be a facilitator and communicator, but when the requirements are known and I write them clearly, there is a lot of time saved, and as you so elegantly put it, not just now, but in the future.
Writing careless thoughts and ideas on an index card or as an entry on a backlog just because it doesn’t matter since what is real is the ensuing conversation sometimes seems like a shirking of one’s responsibility to perform due diligence and analyze the situation. There is indeed analysis that goes on in a room when a product stakeholder or two meet with the development team, but I submit there is even more analysis that can take place when you move out of the room and into the business to see what is really going on. And it doesn’t matter what the title of the person who does that is, whoever takes on that task is playing the role of business analyst.

By: Adriana Beal

Adriana Beal — Fri, 17 Feb 2012 10:12:15 +0000

Thanks for the interview, Laura! It’s always a pleasure to read Steve’s thoughts.

Steve, I can see myself quoting your last remarks until people get tired of hearing them :-). I would just rephrase a bit what you said regarding documenting requirements, to read:

“Business analysts who focus on analyzing the business and identifying improvements in the organization’s products and services rather than merely documenting the need presented by a stakeholder, have no fear from the agile evolution and will find they have a prominent place at the table. ”

As I accumulate experiences with agile, I become more and more convinced that relying mostly on face-to-face conversations and producing just enough documentation to allow the software to be built (as proposed by agilists) may generate short-term benefits, but in general at a high cost to future decision-making, software maintainability, and system adoption rates. I even see, in practice, a level of incoherence between the agile concepts of “embracing change” and “barely sufficient documentation”, as the latter often proves to be a hindrance to future change, as people struggle to remember, or are no longer available to share, undocumented implementation details, and the reasons behind them.

Would you agree with the statement that the ability to write quality requirements and system documentation is not going away in an agile world?