With Agile becoming more and more popular, there is a group of people who believe that we should go beyond the multi-disciplinary team to teams with people that are cross-disciplinary: developer, tester, BA and UX in 1.
It is essential for Agile teams to work together and help each other out, but I do not believe in the one-man-band ideal that those people are looking for. In Dutch, a concept like that is called “A sheep with 5 legs”, and I think that visualizes it pretty well.
Malcolm Gladwell, in his book Outliers: The Story of Success, presents convincing evidence that to be really good at anything you need to spend at least 10.000 hours honing that skill, regardless of your talents. That would mean that a dev-tst-ba-uxer would need at least 20 years of work-experience and the youngest possible cross-disciplinary Agile team would have an average age of 40 years.
So just like in the construction industry I think that IT has it’s own carpenters, electricians and plasterers all trained and skilled for their own discipline, but working together to build a house.
However, more recently I’ve come to see that the disciplines of Business Analysis and User Experience are so close that we should compare them with the plasterer and the tiler: practitioners of both disciplines need to have the same foundations and basic skills and can jump in to help each other out in times of need.
That point was brought home to me during the UX Australia conference in Brisbane last week, a great conference with young, energetic people that very clearly all had the same mission: improve themselves and their discipline.
During this conference I came to realise that the UX and BA discipline are currently too separate: in many organisations BAs and UXers don’t work together but just “hand over their work to each other”, or even worse: compete for the time of the stakeholders.
I think it would be very beneficial for both groups to work closer together, there are definitely clear lessons that both groups can learn from each other. I will address some of those lessons here:
What Business Analysts can learn from the UX discipline
1. Really, no really, think from a USER’s perspective
For the BAs, stakeholders are very important, and a stakeholder analysis is part of the toolkit. However, too often we end up facilitating compromises between those stakeholders which might not be the best for the end-user. The UXer is always working to create the best system for the end-user, regardless of what other stakeholders might have to say. BAs should take some of that drive on board.
2. Prototyping to validate requirements
As BAs we know that requirements are often not clear. We are trained to “pop the why stack”, but even then stakeholders often don’t know what they want until they see it.
UXers assume this from the beginning and they work with models, wireframes and prototypes to test and validate the requirements. Many Agile BAs will already be doing some of this, and some of us even use prototyping/wireframing techniques in requirements gathering workshops, but what we can learn from UX is to make it intrinsic to our work.
3. Innovative ways to find requirements
Quite a few sessions during the conference talked about going out on the street to do surveys: actually questioning potential users. When was the last time you did that as a BA? Let’s face it, we might complain about the fact that there are no real users to do our requirements analysis, but what do we do about that?
What UX professionals can learn from the BA discipline
1. Ask the Why question
In the opening keynote at UX Australia, Bill DeRouchey, a celebrated US based UX expert, addressed the importance of the “Why” question. No BA in his right mind would open with a topic like that at a BA conference, because that is the very first skill you learn in BA bootcamp. Bill apparently saw a need to address that issue among UXers, which is telling.
2. Requirements capture and management
During some interesting conversations with the other participants of the conference I found out that many struggle with the level of detail on their wireframes. They are confronted with clients who want business rules and screen rules captured in their wireframes, and they are not always sure how to handle that. This comes up especially with UX people that work at digital agencies, where there are often no BAs.
Although there isn’t a clear answer to different levels of requirements, we as BAs are trained to deal with that and have a number of techniques (capturing Use Cases, UML models, process modeling business rules) to deal with it.
3. How to be heard
It is almost amusing to write this one, as BAs have been struggling for years to be properly involved and I’ve been to many a BA conference where there were sessions on how to be heard as a BA. However, due to the growing seniority of the BAs, organisations such as IIBA, better tools and techniques and authors/presenters such as the Robertsons, the BA profession has matured a lot over the last few years.
UXers are still struggling with this, and most of the success stories are “brute force”: an executive hired an UXer and forced the rest of the organization to listen. Although this works on the short term, what happens when that exec leaves again? There are definitely lessons from the BA community that the UX-people can learn.
In Summary
This was a good conference with great people and some interesting lessons. What I’ve taken from this conference is that BAs and UXers need to start working much more closely and start learning lessons from each other.
This is very different from the current situation that I’ve seen in a number of organisations where the two disciplines are often somewhere between serious disagreement and official state of war. If you feel that your organisation is doing it well, leave a comment to describe how UXers and BAs cooperate and make it work!
