Date: 16 Jan 2019

Business analysts are just as indispensable as they always have been, but now we have to work differently, in a more agile way, to fit with agile development.

This webinar shows you how to do that. It is about three things:

  1. Too many projects start with an assumed solution, often by recording this assumed solution as a backlog. We show you a better way to start.
  2. Spend enough time with the customers to understand their work, their desired outcome, and what it is they value. We talk about generating alternative candidates solutions and testing them using quick, safe-to-fail probes. The justification for multiple candidates is to get away from the assumed solution, and validate the customer’s problem space by exploring different ways to solve it.
  3. Use a story map to organise the stories written by the business analysts. The BAs write the stories in units corresponding to business events. The product owner prioritises the story map (which is in effect prioritising the business events) and thereby synchronises the work of the business analysts with that of the developers.

 

James Robertson is a business analyst, problem solver, author, speaker, instructor, photographer, designer, and 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, and the Volere requirements 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.

James’s latest book (seventh and counting) is Business Analysis Agility. In this, James and co-author Suzanne Robertson demonstrate how business analysts can work in an agile way, and mesh seamlessly with an agile development team. They show how to overcome the problem of the assumed solution where the project starts with a product backlog. This means that the project starts with a solution, and not the problem to be solved. The book reveals how business analysts can discover the right problem to solve, and how their findings can be synchronised with the delivery cycles of the developers.

James' career is broad, both in a geographical sense and the areas and systems that he has worked with. It is fair to say that James has worked on almost every type of commercial IT project - from a start as a programmer in a software development house in Sydney, to consulting in New York, London, Rome, and most European capitals. He has earned his experience at the sharp end of both project and research work.

He divides his time between London and the French Alps. He skis for as much of the winter as demands on his time allow, and hikes all summer.

 

 

 

Books by this speaker



Comments

To join the discussion, please sign in.