The Agile BA / PM – First Impressions

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

No more paperwork!

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

Requirements are a continuous dialogue.

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

Project Manager
Not Project Manager, Project Co-ordinator.

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

What is the customer experience?
What is the customer experience?

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!

The Agile BA / PM – First Impressions

New job!

On Monday January 18th I will be starting a new job as a Business Analyst / Project Manager, at a small IT consultancy that creates custom web applications as well as offering hosting solutions.  They predominantly use Agile methodologies where possible, however the final approval comes from the client, so if the client wants Waterfall then so be it.  This is a very exciting move for me, and I cannot wait to get started on Monday.

I started this blog in 2008 to track my career change from a recruiter with 10 years experience to a Business Analyst (hence the blog name, see my first post).  My first role however was not ideal, and I knew that going in as it was an Implementation Consultant role for a SaaS product.  Although it involved business analysis type work, such as requirements gathering and extensive customer interaction, it was within a very confined environment.  Essentially the product existed, we were just tailoring where possible and getting the customer trained, live and bringing in revenue.  It was a good starting point but not what I wanted long-term.  I entered Business Analysis with the idea of working on new software product development and release, preferably web applications as that seemed so fluid and exciting.  This new role seems very much in line with what I saw in my minds-eye when I started this career change adventure.

This new job is a combination, they are bringing together the Business Analyst and Project Manager roles.  Previous experience has shown the owners that at present there is not enough work on either side for a full role and that there is also a lot of cross-over.  I will get involved in so many different areas, from requirements gathering, developing and managing a project plan, wireframes, information architecture, testing and so much more I’m sure.  I have a lot to learn.

I will be working my way through the following books recommended by one of the company owners as I get started, and will post a quick review of each as I go:

So a new chapter opens in my career change, and again I will be blogging my progress.

I would be very interested to hear from anyone who has worked in a joint BA /PM role such as this, and any other suggestions on readings would be most helpful.

New job!