Joining the dots: Working with an Agile development team
I’ve read lots of articles and books on Business Analysis tools and techniques and when to use them in the project lifecycle.
What I haven’t seen so much of is how the BA works with the different roles in an Agile development team. My previous blog went into the change for a BA working in a Waterfall framework to Agile which touched on this subject, so here I want to delve in to how you use the tools and techniques we all know so well and how you work with the right people to ensure the outputs from those techniques are effective. It’s based on the British Computer Society (BCS) Foundation in Business Analysis course headings for those who have that certification.
Investigate situation – uncover issues and problems
As we know, this stage is about understanding what the problem is. The techniques are used mainly in a Discovery phase and is very heavy on stakeholder engagement. However, the skills you use are very closely linked to those of a User Researcher. Interviewing techniques may sound very simple and straightforward but for those who have tried it, it’s not easy. Understanding what are open and closed questions and picking out the important information from the other ‘noise’ is difficult. When interviewing to stakeholders, It’s very easy to:
- Lose focus of the interview (go off track)
- Not make the most of the time you have with the interviewee and end up with follow up conversations
- Not get all the information you are after (again, resulting in follow up conversations)
Working with a good User Researcher, they will show you how to go about creating an effective discussion guide that allows you to not only maximise the time you have with the person you’re interviewing, but also capture all the pertinent information you need in one go. Stakeholders are busy people and may not want to be contacted numerous times.
If you have Subject Matter Experts (SME) as part of the agile team for the Discovery stage, then you will be spending quite a bit of time with them to understand the ‘As is’ processes. Don’t just use them for information though, get them involved in articulating the problems, whether it be a rich picture, mind map or emotion map. Making them feel part of the team will build relationships that you might need to call on later in the development of the product.
Consider perspectives – stakeholder identification and analysis
Getting to firstly identify the stakeholders for your product/service will involve most of the development team on board at that time. Typically, this will be a Product Owner/manager, Delivery Manager (Scrum master), User Researcher and SMEs.
Stakeholder identification and analysis (e.g. interest/influence matrix) sessions should be carried out with the whole team but the BA should be working closely with the Product Owner to understand those stakeholders in the high interest/high influence category which you will need to be managed. While you may not be directly involved in engaging them, you will need to understand their perspectives as they may well see some of your outputs (e.g. problem identification, cost/benefits analysis)
Analyse needs – identify improvements
After the Discovery phase is completed and you’ve got the go ahead for Alpha, now it’s time to get (for me) in to the exciting part of product development……identifying potential solutions to problems.
This for me is the part of product development where the BA really starts to put in practice the work they’ve done in Discovery and develop those relationships with nearly all of the other roles on the product team. Let’s start with prototyping solutions.
You’ve now worked with the user researcher to elicit user needs, engaged SMEs and stakeholders to understand ‘as is’ processes, identified potential pain points and have a list of stakeholders which you are keeping an eye on and managing (ideally with a communications strategy). While all this was going on, the interaction designer/UX will have (or should have) been working on a prototype to meet some of those user needs (not all of them, this is Agile after all). So where does the BA fit in here then? Well, first of all, as you were involved in eliciting those user needs through your interviews with stakeholders (including users), you want to ensure what the UX is designing meets those needs (and not just something they think is a ‘good idea’. To be fair, UX rarely, if at all, do this). Some BA books will say the BA would create prototypes however, in these days of software development, many organisations now specialise with either a UX, interaction designer or variation (be careful here. I’ve worked with someone who got very irate when I referred to him as a UX when he was an interaction designer!! There is a difference by the way)
Now a prototype’s been developed, you (along with the UR) are taking it out to users to test and get feedback. Again, it’s a skill that you will learn from a good UR. Trying to stop yourself showing a user how to use a prototype is hard……we’re inherently helpful but need to constrain ourselves and see what the user does.
When you feedback the findings from the testing to the rest of the team (a must), you will be asking the developers and QA what possible constraints there may be (if any) if a particular solution was to be implemented. At this stage, you can start engaging the QA to find out how they want the scenarios articulated in the user stories (e.g. are they happy with BDD). This flows nicely in to the next stage.
Evaluate options – High level user stories
For a lot of people, this and the next stage (Define requirements) is where the BA comes in to their own because it’s about user stories. It’s worth pointing out here that if you haven’t begun to understand the rest of the team roles, it makes the last 2 stages a lot more difficult. Remember, you are building relationships and understanding with your team, and the sooner you do this the better it is….for everyone. I’ll come to why a little later.
As the prototype has been tested, some of the design hypotheses will have turned in to proven user needs i.e. the user likes what’s been designed and is ‘good to go’ to be developed in to a ‘thing’. Great, we can at last start writing user stories! I’m not going to cover that subject here as there’s more than enough information out there to cover how to write good user stories. What I will cover here is that you must involve everyone on the team in the creation and elaboration of those stories…. from start to finish. Don’t see the user stories as purely ‘the BA role’. It probably is to write them but they’re actually the whole team’s user stories. There’s nothing more frustrating than spending time and effort creating what you think is the perfect user story only for the front-end developer to say in 3 amigos that the design has changed, or an API has been removed/changed resulting in functionality having to change.
Making the whole team aware of the story, not just the Developers and QA, is a way of managing risks and ensuring the unknowns are kept to a minimum. You’ll never stop all unknowns but you can cut these right down when everyone on the team knows what the story’s about. After all, the BA can’t be expected to think of everything!
Define requirements – User stories
I’ve briefly covered user story development but here is how you take that to the next level and become the linchpin of the development team. One of the most important tools I’ve used on all my Agile teams is the user story map. Jeff Paton has written a great book on the subject (which I’m sure you’ve all read) however, my main issue was getting it implemented. I’ll cover how I overcame this in a later blog but for now, the user story map is not just a tool for displaying user stories. it’s a vehicle for getting the whole team involved keeping the product on track to achieve its aim. As we know, the user story map not only shows a flow of stories from left to right (user journey) but also top to bottom (releases). It gives a short(ish) view of the work of the team but if you add in the designer’s hypothesis board and the product vision, it provides a flow from design right through to development. It’s also a great tool to use at show and tells. It really gets the stakeholders engaged. Much more than a boring set of slides.
I’ve joined many teams where they haven’t had a user story map in place (they’ve normally just got a sprint board) and I find the whole team’s disconnected. The designers are working on something that’s either not part of the product roadmap (if there is one) or they are carrying out user research that developers are building in the next sprint leaving no time for the BA to carry out the analysis of the story. In a nutshell, everyone has a different view of the product’s vision resulting in different priorities and actions. A recipe for disaster.
As Business Analysts in an Agile world, we need to focus on not only building relationships with our stakeholders, but with the team who’s going to develop the product. Not only is this an essential role of the BA, I would argue it’s critical to the success of the team.