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 can be found at the BCS Bookshop with a discount for BCS members, and will also be available at Amazon (including kindle version), Waterstones, Blackwells, Wordery, and all other good booksellers.
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:
Agile teams practise a variety of techniques when estimating, but most of them are rooted in the same basic theoretical concepts, neither of which are new:
- Wideband Delphi – which depends on multiple people contributing to the final answer; and
- Relative Sizing – because humans a really good at comparing things, but relatively poor at precise guesses.
Continue reading “The Theory of Estimation”
Many organisations are trying to become more agile. Some succeed, but in many cases they struggle. Even though they might use a process like Scrum, have things called Backlogs and people called Product Owners, when they compare what they are doing with the past, they aren’t often actually delivering different outcomes.
The post Sliding Doors – A Tale of Two Agile Teams describes one project and shows how teams (in this case, the Blue team) can appear to be agile, but not actually be agile – they could have delivered their prototype using traditional development approaches. But this doesn’t just happen in small teams; it is also evident at an organisational level, particularly when organisations try to make Programmes more agile.
Craig Larman is a respected agile thought leader, and the author of various books on scaling lean and agile approaches, including developing the LeSS (Large Scale Scrum) approach. He has a theory on why adopting a cultural change like agile is difficult – He calls it Larman’s Laws of Organisational Behaviour.
Larman’s Laws state that “Organisations are implicitly optimized to avoid changing the status quo middle and first level manager and “specialist” positions and power structures“.
Furthermore, he goes on to state that change initiatives will end up being manipulated (probably by those managers and specialists) into “redefining and overloading the new terminalology to mean basically the same as the status quo“. His main message being: culture follows structure, which is similar to the quote (often attributed to Peter Ducker) of Culture Eats Strategy for Breakfast.
Continue reading “Why do People and Organisations Struggle to be Agile?”
In the 1998 movie, Sliding Doors, Gwytheth Paltrow experiences two very different storylines in parallel because of one small difference. In one version, she leaves work early, catches the tube and arrives home to find her boyfriend in bed with another women; in the alternative version, she is slightly delayed, just misses the tube, and doesn’t catch him. The movie plays both versions side by side, switching scene by scene between them.
This blog is based on a real life project, where we were asked to help automate some manual business processes. As we began exploring the problem space, it turned out that another team had also been asked to do the same, but were taking a different approach from us. While we were thinking about business and user goals, they had decomposed the problem functionally.
This story describes how these two approaches differ, particularly with the outcome, tries to explain why goal decomposition is better, yet despite this, is still relatively rare to see.
Continue reading “Sliding Doors – A Tale of Two Agile Teams”
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.
Welcome to a new website exploring how analysis can be agile in modern teams, and how modern agile teams can employ analysis techniques and tools to be more effective.