Documentation OR Agile

God, it's been ages since I last posted on here!!!  Working away hard, nothing really new to post relating to this Blog.

Until today...

Project/Development methodologies can be a difficult subject; Traditional Waterfall, Agile or company specific.  You really need to know what the preferred method is, so you know what the project deliverables are (if any)!

I have been reading a few articles today to refresh myself on pros and cons, reasons for using and general updates on different methods.  The following article in the BA Times has caught my attention and I felt it was worthy of linking to.

BA Times - Business Analysis: Is it a Bottleneck in your project?

I think the title is a bit miss leading, but the article is very helpful.  Key paragraph to me (in my present project) is:

"I have seen a project work where multiple BA resources worked on the requirements and specialised in particular areas. The requirements were not completely detailed up front but the business vision was, and high level requirements were documented to a level that allowed estimation to be performed. Then as each iterative development phase started on each business area the BA responsible would verbally present his or her concept to the development team in detail, with mock screen shots or story boards, models of the process, and associated business rules. Allowing the developers and testers to see the complete picture as well as the detail is important and allowing them to ask questions and seek clarification on issues instantly speeds up the process of transferring information. If anything does change then an efficient and quick change management process is very important."

It sums up nicely what I am doing at the moment.  I have produced a high level BRD (for want of a better title - possibly a simple Requirements List is closer), I know what is required from the solution and I am awaiting a decision on methodology to be used going forward by development.  I know the methods that have been used by Dev in the past - having worked in the department for 3 years - but there has been talk of a more Agile approach being introduced. 

With high level requirements already in place, I can easily go down whichever path I need to, be it Software Requirements Specifications, Product Backlogs or, as per the article, present to the developers.

So what we want is a way of speeding up the requirements process without losing any of the detail or the communication to stakeholders that allows them to confirm the requirement and therefore deliverables are correct.

...

So in my experience a middle ground is important. We need to capture the business's vision in a document because it will be referenced a lot and it is an important we capture it in detail and clarity.

At the end of the day, we will be working towards a solution!  The path to the solution is important but not as important as the information being conveyed.