Too many agile projects fail to analyse the problem they are trying to solve because they feel analysis takes too long. All too often the decision to introduce IT is taken by well-meaning senior managers who fail to see the need for analysis or understand the problem they are trying to solve with IT. Once the problem has been assigned to the IT department analysis can be side-lined in favour of development work and technical solution. If you give the problem to IT to solve, then they are going to look to IT to solve it!
I had great pleasure taking part in the BA Summit 2017 organised by Penny Pullan of ‘http://www.makingprojectswork.co.uk’. Where i had some great questions on the Topic of ‘Agile and Business Analysis’.
Please download and enjoy – http://pennypullan1.audioacrobat.com/download/BASummit17LyndaGirvanAgile.mp3
After months of hard work writing, editing and reviewing, I am thrilled to announce that our book ‘Agile & Business Analysis‘ by Lynda Girvan and Debra Paul, with a foreword by Scott W Ambler, has been published and is now available!
It is particularly recommended for anyone taking the Agile Business Analysis certificate, part of the BCS Advanced International Diploma in Business Analysis as it covers all the syllabus (and more).
The Business Alchemist at AssistKD has written about how difficult it is to provide certainty to people learning agile or business analysis. There is almost never a 100% right answer, but there are some things that analysts can do to help navigate this uncertainty:
Jeff Patten’s User Story Mapping is great technique that many teams use early in the development of a solution. His book describes the process in detail, and I highly recommend it. There is also a simplified explanation in the ‘Modelling Stories and Scenarios‘ chapter of Agile and Business Analysis.
User Story Mapping solves some of the problems that Agile teams face when trying to balance the desire of the stakeholders to know details about the whole project against the needs of the Agile team to focus on the short term, high certainty requirements, and avoid big-up-front design.
The approach allows the team to expose the whole project scope in a way that is quick to do, produces enough detail (but not too much) and allows the work to be prioritised.
Stakeholders can indulge themselves in the art of the possible, exposing a breadth of capability for the solution that may far exceed the resources of the team to deliver. This is only OK if it doesn’t consume a lot of effort, or set unrealistic expectations, so it is important to manage that aspect. However, by being able to see the whole solution, stakeholders are better able to prioritise shorter term goals, and direct the team’s focus on what they want first.
Coupling User Story Mapping with a strong focus on Goals and Goal Decomposition allows teams to focus on the right things. Since User Story Mapping can allow teams to functionally decompose the problem, it is really important to ensure that the slices of user value relate to goals rather than functions. For an example the difference this can make in practise, read about A Tale of Two Agile Teams.