So I am 12 weeks in to my new role as an Agile Business Analyst, so I wanted to give a summary of my impressions, and how the role combines with being a Project Manager and QA part-timer.
1) Documentation
This is the biggest area of change for me, and from my perspective a welcome relief. Gone are the bulky Business Requirements Documents that I slaved over for days, only for the customer not to read, and for the team not to look at again once the review is over. Agile is agile because it is nimble. You do not weigh yourself down with hefty tomes, documenting every in and out of the project. Instead, stories, and scenarios are used. Work is done firmly at the business level. What does the business need? Let the Technical Lead do the interpretation. Yes you need to be grounded in technical reality when the implementation starts, but you don’t know why you are doing it unless you have captured the business level goal. This can normally be captured in a sentence, or short story, and the simpler the better.
2) Requirements Gathering as a Conversation
The convention of Agile requires that the customer be heavily involved in the project throughout the lifetime of development. Although we cannot incorporate the customer to the level we would like, we are still delivering working functionality and demos every week or two, so a constant stream of feedback is available. This dramatically changes the requirements gathering process. Working from iteration to iteration, as the BA I work ahead of the developers as much as possible, reviewing the stories and clarifying requirements. However more typically I am working in the moment with developers as requirements questions come up, because they don’t know the roadblocks or lack of understanding until they really get in to working on a story. So on these occasions, we are having ad hoc meetings with the customer, discussing their needs and working through use cases, that will result in working functionality very quickly, typically no longer than 2 weeks. The discussion therefore remains fresh in their mind, the decision is captured and implemented quickly, and the presentation of the result is fast. I have found this to be a very effective way to seek requirements and verify their understanding. Nothing is ever captured and documented, never to mentioned again until weeks or months later when the product is delivered. This is why requirements gathering now feels like a real dialogue, a never ending conversation stream connecting the developers to the business, and vice-versa, through myself and the Tech Lead.
3) Project Management
This is the completely new area for me as I have never been a Project Manager before. However, once again, Agile to the rescue! The PM role in our Agile projects is very limited, and in fact we call it Project Co-ordinator to stay true to the team ethic of Agile. We are all in it together and not under the instruction and watchful eye of a manager per se. The small teams, and heavy involvement I have as the BA means that I have my finger on the pulse of the projects progress. But more importantly, the iteration development cycle means that we are never falling behind schedule or stressing about keeping Microsoft Project up to date. We assign stories to be completed in an iteration, based on the number of points we estimate can be completed. One or two weeks later, we know if we have hit that or not, and we estimate the next iteration based on the last. Apart from that, I do some burn down charts, however not for all projects, it depends on the customer, as does whether they need some thorough updates as we progress, but really the PM responsibility is limited. Most critically in this role I feel the need to stay Agile. Don’t get bogged down in facts and figures and work that does not have business and customer value. It is a powerful motivator to stay on track, and follow only those critical metric required for the project to succeed and to keep the customer happy.
4) QA as Usability Testing
I have found this area to be the most challenging and perhaps, dare I say it, the least interesting part of the process. It is a vital aspect to the process, no doubt, however my lack of training or formalized approach to this function means that I maybe create more work and more repetitive actions as I feel my way through the process. However, I have found it is an excellent opportunity to do some rudimentary usability testing. I put on my “I am the user or customer” hat and dig in to the fledgling software, asking the basic or simple questions of the developers to see if there is a better or simpler way to do things. So it is not just Use Cases, bugs, issues, report, it is once again a more fluid dialogue of not only the issues found but maybe a better way to organize a screen or function during the next iteration.
Overall, I am thrilled with my new role. I am learning so much, and I am involved in so many things that I have wanted to be doing for so long now. I will try and keep the articles coming as I truly define my place as a Business Analyst / Project Manager in the Agile software development world.
Thanks again for reading!
Budding Business Analyst 