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.
I disagree that we are all BAs and I strongly disagree with the notion that developers should practice business analysis. I would prefer to work with a developer who writes clean, working code in the best way she/he knows how to do. I want to work with a developer who focuses on the best WAY to accomplish the WHAT. The WHAT is my job. The WAY is the developer’s job. Trying to master both of these things will extend the cycle and also, as a developer, I think you would be happier to not waste your time filtering through the mess of getting to the what, because, it’s really messy.
I’ve worked as a BA on projects where the developers insisted on my presence. I suppose many of you have not had this happen, but in cases where you are a small dev shop and you are dealing with a large PMO [corrected here - typo in original reply] client, you will benefit from having a BA take the reins – from them, really – so that you can manage scope more effectively.
Project managers manage “when.” BAs manage “what.” Developers manage “how.” There will always be back and forth and everyone’s input is certainly necessary but in the end, someone has to be on point for owning that part of it. That’s been my experience. I know it’s really oversimplifying it but keeping it simple rocks.
© 2010, Tia Peterson. All rights reserved. This text may be reproduced with permission. Please contact tia@tiadpeterson.com to request permission to reuse this content. Thank you!

Discussion
No comments yet.