Sometimes it’s the simple things that make a profound difference. Sometimes they can be so blindingly obvious that we cannot see them. And the biggest impediment to progress can be between our own ears.
In this article I will describe ‘attentive listening’. We will cover how to do it, why it works and when to do it. At all times we will bear in mind the Agile manifesto commitment to maximizing the amount of work not done – not done by us, by the teams we work with and by the stakeholder!
Listening is a cornerstone skill of business analysis. If an analyst is to be of any value then they must be alert to clues in the environment. What thoughts, frustrations and opportunities are there? Understanding what is said, is an absolutely fundamental part of any analysis in order to produce useful insight or alignment.
So, you listen already? Sure you do, yet what are you listening to? The whole of what the speaker has to say? Are you giving them a chance to finish their thoughts?
In the simplest explanation of the term, a UX writer is an author who writes for user experience. When using a digital product, you follow text in order to obtain the user experience you’re after. This text should be precise, brief, and straight to the point. The writer’s goal is to guide the user through the different stages of product use.
The term gets mixed up with technical writing and copywriting. The difference is that UX writing is much more concise. An effective copy results from the collaboration between the writer and the entire design team.
Let’s start with the specifics: how can you improve your UX writing skills and contribute towards an improved final product?
When I began training to be a BA, I never dreamt that I would need to be a salesperson too, in fact, I'm glad I hadn't realized that as it may have deterred me from, what is for me, the most suitable and fulfilling career that I could have wished for.
The answer is simply this: the ability to sell. The better you are at selling, the more senior you are likely to become, and this is true across the whole business, it doesn’t just apply to Business Analysts.
Learning about mental models and how to apply them to their work is one of the best investments for business analysts interested in achieving the level of deep thinking that leads to better outcomes for their projects and organizations. There is incredible power in using inversion at the outset of a project to imagine ourselves in a future where the solution has not only been delivered, but is in the hands of end-users to get their job done. Rather than simply going through the typical project phases in forward motion, we can then look backward and gain additional perspective into what might go wrong so that preventive steps can be taken to avoid those bad outcomes.
In Part 1 of this series John Seddon argued that Agile, as practiced, is bereft of knowledge, hence its ubiquitous failure. Here he argues that ‘get knowledge’ is the starting-place for effective change.
Part 2: Knowledge: the prerequisite for profound change
It may seem heretical to suggest that we make change without knowledge, but, as Deming pointed out, experience is not equivalent to knowledge; you can spend 20 years in an organisation without knowing how to change it for the better. Leaders, clients and stakeholders describe requirements or problems to solve on the basis of their current world view, governed by information from their current control systems, but what if their world view is flawed? What if there are bigger and different problems to solve?
The fact that software projects and tasks are reported to be “90 percent done” for a long time has become something of an industry joke. (A related joke states that the first half of a software project consumes the first 90 percent of the resources, and the second half consumes the other 90 percent of the resources.) This well-intentioned but misleading status tracking makes it difficult to judge when a body of work will truly be completed so you can ship the next product release to your customers. Here are several typical causes of “90 percent done” syndrome and a few possible cures.
Culture clashes frequently arise when teams are working on requirements. There are those who recognize the many risks associated with trying to develop software based on minimal or telepathically communicated requirements. Then there are those who think requirements are unnecessary. It can be tough to gain business-side cooperation on projects like legacy-system replacement if users see this as unrelated to their own business problems and not worth their time. Understanding why people resist participating in requirements development is the first step to being able to address it.
Sometimes I find it difficult to explore new pieces of work in a structured way. When given a new challenge / piece of work it’s easy to jump straight into a solution. However as BAs we first need to understand the problem area better.
Surely facilitation is an important part of a business analyst’s job, but it is far from the only part. Analysis in itself should always form the core of a business analyst’s responsibilities. We are called ‘analysts’ for a reason! Facilitating information gathering and translating it to ‘requirements’ doesn’t make you an ‘analyst’. Go above and beyond, and add value by ‘reasoning backwards’ and ‘reasoning analytically’.
brought to you by enabling practitioners & organizations to achieve their goals using: