Last night I went along to the 'BA & UX' event organised by the UK chapters of IIBA and UXPA, with speakers as follows:
"BA and UX: Intrinsically Incompatible?"
Nick de Voil, Member Experience Director of IIBA UK
"UX vs BA: The Great Debate"
Ian Worley, Global Head of UX for Morgan Stanley
In a nutshell, the message from both talks was that there are similarities and differences between the BA and UX roles, but when it comes down to it everyone on the team should be working together and offering up skills to projects, rather than concentrating on job titles. You can read more about the presentations on Twitter, using hashtag #uxbaot.
The Agile question
I feel like iterative working is a huge opportunity, which is getting rejected by some business analysts who feel their work does not fit in the process. I want to put forward some thoughts in this post in defence of Agile and hopefully to encourage more BAs to engage with this opportunity.
1. Which Agile is right for you?
When people talk about Agile, they normally mean Scrum, which is the most common Agile development methodology. But there are many different Agile development approaches, such as Kanban, DSDM, Lean etc. Different methods suit different projects and organisatons. Read more on versionone.com.
2. Think of Agile as a development methodology
I think the biggest mistake people make is to view Agile as a project management methodology. I often hear people say things like "how do we know what the whole solution looks like?" or "how am I supposed to get this complicated analysis done during a 2 week sprint?". Scrum is about taking a bunch of development tasks (user stories), resolving them during a sprint, and then re-evaluating the next lot of stories in light of what has now been developed. And along the way the BAs and other stakeholders can review progress and help direct and shape the emerging solution. To be successful at a project level, you need to run more traditional project management over the top of this, and work out the bigger picture of what you are doing and when things like business analysis need to be completed to feed into the Agile development cycle.
3. Do enough design up front
4. Business analysis needs to run ahead of development
5. Understand the methodology, but beware of puritans
The first is the manager who has read somewhere that Agile is the in thing that can deliver quick results. They throw together a team of people, say go and expect instant results. All people working in Agile should be trained properly in the process itself. It is a disciplined way of working and everyone needs to understand it properly from the start. Those outside the process, such as business stakeholders need to be given a clear understanding of how it works and their involvement. Put simply, if the business stakeholders have not been properly introduced to the iterative concept, they are going to be upset when you present them with a piece of software that looks unfinished and only meets half of their requirements.
The second is the Agile puritan. This is normally the developer who has read everything about e.g. Scrum, and knows exactly how it should work. This quest for ideological purity can sometimes prevent the pragmatism required to get things done. Remember, the object of the project is not to run an optimal Agile process, it is to deliver an optimal product.