Share this
by Martin White on 12 May 2014
Do you want to deliver better results as an agile business analyst?
Instead of trying to predict the future when planning delivery of business requirements, agile business analysts respond to change as it happens, resulting in reduced time wastage and a more collaborative team work environment.
Applying the agile philosophy does not necessarily require changing the activities you already perform. You can enhance your agility significantly simply by restructuring the timing and sequencing of these activities.
As Equinox IT’s Software Development Manager I am responsible for a number of agile business analysts. Based on our experience of delivering numerous agile projects in New Zealand I share in this post the five ways I’ve seen agile business analysts deliver better results. These approaches enable business analysts to focus their team on achieving business objectives and add considerable business value.
1) Create the vision and context
As the business analyst you are the conduit between the business and your team, so it is important that you ensure your team is focused in the right direction and working towards the defined business objective.
Development teams are often disconnected from the business and find themselves working on small pieces of specification without understanding how their work fits into the project in totality. Regularly focusing the team on the overarching business objective “the big picture” will provide important context, facilitate alignment and enable each member to understand the value of their contribution.
As the business analyst you can increase the focus on business value. This is important because most organisations have management structures that focus on managing people, rather than value.
2) Be part of the team
New Zealand business analysts are often located separately from the development team. Physically moving into the team helps to facilitate cross communication, encouraging discussion of work in progress and keeping the business analyst better informed.
Business analysts often run ahead of the development team. But in an agile environment you should aim to minimise this gap in order to provide opportunities to work collaboratively. This may mean understanding the high-level stories and acceptance criteria ahead of the sprint, but the elaboration of these with the business and the development team happens during the sprint. When everyone is actively involved in the progress of the software solution this results in less room for error and mis-communication.
3) Accommodate Change
One of the fundamental truths of being agile is the ability to accommodate change. This starts with refraining from locking down details until the latest possible moment. Over the course of a project business objectives can change and priorities may shift. Adopting a more fluid agile approach gives you the ability to accommodate change as it arises along the way.
Central to this is the importance of encouraging client involvement by providing frequent opportunities for feedback. The more actively involved the client is the sooner you will be aware of changes or amendments required, thereby minimising the need to re-do work.
Remember to ensure you have a controlled ‘trackable’ feedback system in place. Increased client feedback can result in many small tweaks and changes filtering through to the team. These need to be managed and followed through effectively. Commonly this is managed through backlogs and visual workflow tools such as Kanban boards.
4) Specify acceptance tests for requirements
Your effectiveness as a business analyst is ultimately measured by how well the software delivers the required business value.
Often in New Zealand business analysts get involved in acceptance testing at the end of the software development process, which is too late. If you can only confirm that your software has delivered business value at the end of the project, you may discover that there is a good deal of rework required and a lot of wasted resource and effort.
In our experience, much greater business value is delivered by combining detailed requirements and acceptance test specifications as one activity. This is further enhanced by writing test specifications in such a way that the testing of them can be automated using an agile approach called acceptance test driven development (ATDD). Using these approaches enables software to be validated immediately as each requirement is developed, minimise waste and rework and maximising business value.
5) Stop starting and start finishing
In our experience New Zealand IT professionals all want to do the best job that they can. The problem is that many teams have a tendency to keep going, gold plating and polishing until something is perfect. But what if this is beyond the level of quality that the customer needs? Then we have wasted time and resources to add no further business value. As a business analyst on an agile software development project you need to provide a very clear definition of what done means in terms of both functionality and quality for each story, and once it is met the team must stop working on it.
We have found that many New Zealand software development teams find it difficult to successfully adopt agile. Business analysts play an important role in agile projects by creating the vision and context, by being part of the team, by helping the team accommodate change, by testing early that business value is being created and by making it very clear when a requirement is met. Do these things well and you should find that you whole team starts getting much better at delivering success agile software development projects.
