I posted the following as a reply to several comments on an old (I’m talking 2008) article titled “The Role of the Analyst in Agile Projects.” It’s nearly 3 AM, so I’m headed off to sleep but I wanted to include my response here because although the conversation might be aged, the context is not.  Cheers!

Read my reply here first, and then go read the article.

I find this conversation so fascinating. In my opinion, the ultimate goal is to build something timely that meets the customer’s expectations and needs. Whether or not there is a business analyst active on the development team is a decision that needs to be left up to that team. If you fall into a prescriptive mentality about agile development, you’ve already lost and are no longer agile. You need to do what works for your team and the project at hand.

Read the full story

— Tia Peterson

I have been thinking a lot about documentation recently, now that I am about to go back into full-time consulting work again.  My professional background has quite literally been completely built upon documentation – originally as a spec writer in a large development environment, then as a product manager still in that same large development environment, and later as a business analyst in a much smaller, more agile (and also more global) setting.

Boy, were those two completely different worlds of documentation!  In the one setting, we had team fully dedicated to managing documentation – ENTIRELY!  We were documentation specialists.  In the other setting, documentation was either needed or not needed.  It wasn’t someone’s “job” to document, rather, the documentation was a byproduct of the development or business contract.

Of course, I didn’t mind the second setting in the least.  Even though I have a technical writing degree, I completely get the logic behind the theory that documentation is simply a means of communication, and a pretty lousy one at that.

Here’s why:

Read the full story

— Tia Peterson