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
One of the big topics that came up from both the presenters and the audience questions, was how BAs (especially) can work with Agile. As someone who does both BA and UX work, as well as project management, product management and lightweight dev such as SQL, XML, XSL etc, I was amazed by the strength of negative feeling about Agile. I work in both Agile and Waterfall type methods, and for me it is clear that iterative development approaches are the easier and faster route to realising relevant, quality project outcomes. I was also surprised by the ‘them and us’ mentality about working with developers – although some of this was clearly tongue-in-cheek.
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
Someone said that writing 400 page BRDs up front was ‘unfashionable’. I would use the word ‘ludicrous’. How can it be feasible to work out every detail of a development without at least some technical exploration, a prototype being made and user tested etc. It makes much more sense to do ‘enough design up front’ – work out what it is you are trying to make, the general architecture, high level user-stories and requirements, what the definitions of success and failure are etc. You will learn so much about what you are developing as the solution emerges, especially the truth about what is and is not important for users.
4. Business analysis needs to run ahead of development
Perhaps an obvious point, but lots of things need to be done before user stories are ready to go into development. Business analysis needs to take place in advance of the sprint or iteration where the user story will be developed. Prioritise the analysis and deliver it in the order that the development is scheduled, just-in-time. The idea of ‘sprint 0’ was discussed at the presentation, where investigation takes place in an extra sprint before the first user stories go into development. This needs to happen, and you need to accept that your sprint zero may be 4, 8, maybe 12 or more weeks long.
5. Understand the methodology, but beware of puritans
This really is the key problem I have come across with Agile at the moment. There seem to be two sorts of influential people talking loudly about Agile.
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.
6. Find your own way of working
I think the big message with Agile is ‘find a way that works for you’. Every business and project is different, and you can combine different approaches to make iterative development work smoothly for your business. I currently work on a project where we have just settled into a DSDM/AgilePM approach being used over the top of a Scrum development team. The Lead Business Analyst has a prioritised list of items that require investigation and knows when these are scheduled for development, so she is working well ahead of the development sprints. Don’t be afraid to change the rules to fit your business – focus on the goal – delivering a high quality product.