Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage Articles Author Q&A on the Book Business Analysis Agility

Author Q&A on the Book Business Analysis Agility

Leia em Português

Key Takeaways

  • There is a misconception that business analysis skills are not needed in agile environments
  • Many teams very efficiently build the wrong product because the miss out on identifying the real customer need
  • Most agile development approaches start from the point that the product to be built has already been identified "by someone"
  • Business analysis skills and the business analyst role are not synonomous - everyone on a development team should understand the tools and techniques of analysis
  • There are a number of tools and techniques which make identifying and solving the real problem possible 

James and Suzanne Robertson have written a book titled Business Analysis Agility - Solve the Real Problem, Deliver Real Value. In the book, James and Suzanne address the fact that despite the adoption of agile approaches a lot of time, effort and money is wasted building the wrong product.

They explore the challenges faced undertaking analysis in agile environments and address some of the common mistakes they have seen in their work with organizations around the world.

The book is aimed at “anyone who has a stake in delivering real value by delivering the right solution to the right problem”.

The book can be purchased here and InfoQ readers can access a sample chapter here.

James & Suzanne spoke to InfoQ about the book.

InfoQ: Why did you write this book, what is the problem you are aiming to solve?

James and Suzanne Robertson: We kept encountering the attitude that skills of business analysis and requirements

discovery were made obsolete by Agile methods. We also kept encountering Agile teams who were struggling to deliver relevant products -- mainly because they did not understand the customer’s real business problem.

But let's face it, many customers do not understand their problem. It takes skill and application to uncover the real problem. Failure to do so means that you are simply building something that is not really relevant. We have too much software in the world; let’s not add anything we don’t really need.

We also wrote it to discourage the practice of assuming that the first solution that comes to mind is going to solve the problem. Often, these assumed solutions are developed without very much attention to the underlying business needs. We can only solve business problems if we understand the real problem before building anything. There is no time to question the problem during a sprint.

InfoQ: Who is the book for - who should read this book?

James and Suzanne Robertson: Our prime target is business analysts who work in an Agile environment. These people were asking us how they could productively use their skills when the development team were using Scrum of one of the other methods. We set out to show how business analysis is conducted as part of any Agile process, and how the business analyst is an integral part of any development team.

InfoQ: You make the point that despite the adoption of agile approaches building the wrongsolutionstill happens a lot.Wasn’t preventing that one of the key drivers behind the whole agile movement?

James and Suzanne Robertson: Yes, it was. However, Agile processes are all about development of the product. For example, most Scrum projects start with a product backlog. The problem with that is that the “product” in this case is a solution. Very little thought was given to the problem under the assumption that the development team, or the customer, knows exactly what the problem is. This has proved to be an unsafe assumption.

InfoQ: Agile processes make a big point of constant engagement with the customer. Doesn’t that solve the issue of finding the right problem?

James and Suzanne Robertson: Of course it’s a good thing to be engaged with the customer. However, you’re not going to discover the customer’s problem sitting in front of a screen. You have to forget about solutions for the moment and go see the customer’s work -- we call this “creative observation” -- and understand what they are trying to achieve. This is a business outcome, and until you understand the customer’s work, their motivation, their skills, you’reprobably not going to find it.

InfoQ: You say in the book that “delivering a solution is not the same thing as delivering value” - why do so many people and organisations get this wrong?

James and Suzanne Robertson: Over-enthusiasm. The expression “a constant stream of customer value” became a synonym for “we are delivering software regularly, therefore that must be valuable”.

Software is not valuable unless it solves the customer’s problem, and the customer wants you to solve it. Without some delving into and understanding the actual problem, there is no way to say whether the delivered software is valuable. Simply because a user says that is what he/she wants does not make it valuable to the business.

InfoQ: What are the key differences between agile business analysis and traditional business analysis?

James and Suzanne Robertson: The agile (note the small “a”) business analyst works in synchronisation with the product owner and the customers. Prioritisation is a large part of this, and the agile BA is not attempting to build a complete specification, but to study the parts of the customer’s problem that are considered the highest value pieces of the puzzle. Value here means delivering the greatest advantage,

InfoQ: Who is responsible for undertaking business analysis on an agile initiative

James and Suzanne Robertson: Everybody. Just because you don’t have someone on your team with the title “business analyst” (for example, Scrum does not prescribe the roile) does not mean the need for business analysis goes away. It is just as important as it has always been. However, now it might be done by people who are not called a business analyst, and might not think of themselves as one.

Regardless of what the role is called, there is a need to study the customer's problem, what they are needing to achieve, what their aspirations are, what they value. This is what traditional business analysts do, and there must be analytical skills within the team to do it.

InfoQ: Where does innovation and creativity come into solving the right problem?

James and Suzanne Robertson: Two places: one is in identifying the problem. People don’t necessarily know what their problem is. They sometimes fixate on a solution to their assumed problem, and pursue that. It sometimes needs creativity and imagination to probe deeply enough to find the underlying problem. The second need for innovation -- keep in mind that innovation is “fresh thinking” -- is finding the right solution to the problem. There are usually several right solutions, it’s the innovative mind that continues finding them until one outstanding candidate comes along.

One of the things we talk about in the book is about generating multiple candidate solutions in sketch form. Obviously innovation helps a lot here. If one is creatively solving a problem, one is probably questioning the problem at the same time. This is exactly what we want to happen.

Then we use a series of safe-to-fail probes to examine the solution and at the same time, question the customers as to whether this is solving their problem, is it producing the right outcome? Is it suggesting that the problem might be different than this one this candidate solution solves? And can this candidate solve a better problem? One that is more beneficial to the customer.

All this is creative, and has to be done if you are serious about solving your customer’s business problem.

InfoQ: You distinguish between the “problem space” and the “solution space” - why are they different?

James and Suzanne Robertson: The problem space is the work being done by the customer. Let’s say for example this is selling tickets on a Metro system. Then let’s say that we probe this problem space for a little while and decide, with the customer, that part of his/her problem is more valuable, and that’s the part we jointly decide to deliver a solution for. This might be say, the actual vending of the tickets, and we leave aside the reporting and traffic management part of the problem.

It might well happen that when we are looking at candidate solutions, we discover that there is a problem that we can also solve for the customer that was not part of the original problem space. In this case, the solution space changes the problem space. Let’s say for example that we discover the idea that instead of selling a smartcard ticket, travellers can use their debit cards to swipe themselves into and out of the Metro system. This extends the problem space to cover the communication with the debit card issuers and so forth.

That said, usually the solution space is the same, or slightly smaller than the problem space.

InfoQ: A lot of your advice seems to be around using “business events” to map and sequence work - what is a business event and why is this so important?

James and Suzanne Robertson: We work on large problems. Of course there are small development efforts, but mostly a project that any of your readers is working on is going to deliver something significant. This means that there is a need to partition (“thoughtfully slice”) the problem into smaller pieces suitable for study.

A business event is a significant happening, it often happens outside the problem space, that causes a meaningful response. For example, in the above mentioned Metro system, a traveller requesting a smartcard ticket is a business event. It came from outside, and the problem space must respond to it -- take the money, add it to the smartcard, issue the card, record the transaction, and so on.

By partitioning the problem into business events, the business analyst can work on them one at a time. The responses to the business events are discrete -- they have no functional connection to other business events -- and so can be studied in isolation.

The very same property also allows the development to be done, more or less, one business event at a time. The solution to a business event is a useful, stand-alone (within reason) deliverable.

We also make use of business events when we build a story map. Or you can think of it as building your backlog one business event at a time.

InfoQ: You list quite a few techniques and tools in the book - what are some of them and do agile business analysis practitioners need to use them all on every initiative?

James and Suzanne Robertson: While we talk about tools and techniques, we are agnostic about which ones the business analyst uses, We like to think that agility includes adaptability, and that the agile business analyst is able to select the tools and techniques that are appropriate at the time. I don’t mean to duck the question, but for us agility is a lot more than slavishly following an Agile method. Agile analysts are able to adapt to the situation and use whatever suits him/her and the customer.

InfoQ: What else do you want to tell us?

James and Suzanne Robertson: We made a video that explains a lot of the book. It takes 2 minutes 30 seconds.

About the Book Authors

James Robertson is a business analyst, problem solver, author, speaker, instructor, photographer, designer, coach. He trained as an architect but left that for a career in IT and the sociological side of technology. He left the security of employment in Australia to move and start his own company (with his brilliant wife) in the United Kingdom. Since then he has gone on to co-author seven books, numerous courses, theVolererequirements techniques and templates which have been adopted by organizations all over the world as their standard for gathering, discovering, communicating, tracing and specifying solution needs.

Suzanne Robertson is having a stellar career in information technology and systems engineering. She is a teacher, practitioner, writer, instructor and guide. Suzanne is a pioneer adapting ideas from other domains for automated solutions. She has collaborated in workshops using experts from fields as diverse as modern music, visualization and cookery. Ideas from these domains were adapted to make major breakthroughs in creative ideas for domains ranging from air traffic control to local government. She is co-author of the best-selling Mastering the Requirements Process among other books and courses. She is co-creator of the Volere requirements techniques. She was the founding editor of the Requirements Column in IEEE Software.


Rate this Article