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
A few weeks ago, I had the pleasure of taking part in an interview with Dave Saboe for an episode of his podcast series – Mastering Business Analysis.
You can listen to my episode – How to Succeed as a Business Analyst in an Agile Environment by clicking on this link!
In an ideal world, agile teams don’t need to estimate at a whole project level. They get given an overall project goal, and work together with their customer to work out how to achieve it. In time, they may settle into a more predictable velocity that allows them to predict with some accuracy what they can achieve in an average iteration, but that isn’t going to happen right at the start.
However, that’s not how the world works. In reality, the customer often want to know things in advance. Typically:
- How long will it take;
- How much will it cost; and
- What will I get at the end?
This is the classic project management ‘Iron Triangle’, and traditional projects are set up to provide answers to these three questions at the beginning. They will then pretend that the process they are following will guarantee that they will still be true at the end.
One of my favourite quotes from Scott Ambler is that every time someone asks you to tell estimate the whole project, they are really asking you to lie to them; you just aren’t sure which of your estimates will be the lie (clue: it’s probably all of them).
But despite evidence overwhelmingly showing this to be true, particularly with IT or change projects, the practise still persists. For some eye opening statistics, see this Wrike blog which is promoting using project management approaches, yet still shows that less than a third of those using formal methods stay on schedule, less than 2 out of 5 stay on budget, and barely two thirds deliver the expected scope!
So, how can we get around this paradox? – as an analyst, you don’t want to lie to your customer; but the customer expects at least some idea of the cost to get what they need.
The secret lies in two areas:
- Do ‘Just enough‘ analysis, ‘Just in time‘;
- Rely on the fundamentals of agile estimation: Wideband Delphi and Relative Sizing.
The first thing is to properly understand why your customer is asking you to estimate the project. Without this knowledge, it is impossible to know how much detail you will need to go into, nor when you can stop. It is also an opportunity for you to challenge your customer on what she needs the estimates for; and whether she needs them at all.
Many people, particularly those unused to agile delivery, assume that fixed price delivery is preferable to time and materials. Therefore, they need to know in advance, what the deliverables will be, and what the supplier is being asked to price.
However, as Craig Larman and Bass Vodde explain in their ‘Practices for Scaling Lean and Agile‘ book (and in the sample chapter at www.agilecontracts.org), this is not true. Mature, successful agile outsourcing use time and materials contracts, along with strong collaboration and trust. This feels counter intuitive but isn’t.
Agile projects expect change, especially to the scope. Agile works precisely because the customer uses the early delivery of working solutions to better understand their problem, and adapt the solutions accordingly. Therefore, it would be impossible to accurately predict the outcome at the start, so it is illogical to even try. However, we are certain that the solution will require people to work on it, and may require the purchase of some materials.
As long as the customer is properly engaged, and the team is making tangible progress towards her goal, then time and materials is an ideal way to describe the contract. All that is required in advance is confidence that the budget available will deliver enough value. Since the customer is in control of when to stop, and what to prioritise in each iteration, they are already in control of their scope, their cost, and their schedule.
Nevertheless, this isn’t always possible. Sometimes it is necessary to agree some level of scope or commitment up front, and this will require some analysis. There are several things that can contribute to this analysis, and draw on the principles of agile estimation – involving many people (Wideband Delphi); and comparisons between things (relative sizing). Some examples are:
- An understanding of the problem, perhaps by some ‘Just enough’ modelling, or workshops like Story Mapping;
- An understanding of your team’s capability, perhaps with historic analysis of velocity or deliverables;
- An understanding of some previous project that can be compared to the current project;
- A measure of the size, perhaps by creating business epics, a high level business architecture, or a Use-Case model;
- Creation of prototypes, perhaps extremely low fidelity such as cardboard mock ups of products, or hand-drawn wireframes of screens.
It is important to ensure that as little effort is put into this analysis as possible – just enough to be able to answer the customer’s questions about the overall project. The sooner the team is engaged in actual early delivery, the better.
To do this, keep the size of the things being analysed or modelled as large as possible. You know they will be broken down later, so keeping them big means you are doing less nugatory work if they are eventually reprioritised.
It is also important is to remember what assumptions you are putting into your analysis. As the team starts iterating, they will learn more about the project, and will be proving or disproving those assertions. When this happens, it is an opportunity to revisit your high level analysis and refine it with your new knowledge of the assumptions. This is particularly important if the customer is relying on your early estimates for higher level reporting.
Estimates made before the team starts will always be poor quality, unless the problem being solved is trivially simple. They can help justify investment, determine the initial size and shape of the team, inform future workforce development or hiring decisions and predict when the customer may have a version she can start using. However, they should not be used to create project milestones far into the future or become hard dependencies on other projects.
To conclude, it’s best to avoid up-front project estimation if you can. Understanding why your customer thinks they need detailed estimates will help you get the amount of analysis correct, and may provide an opportunity to persuade your customer that she doesn’t need them after all. If she does, keep things high level; business level epics or outcomes, high level goals and ranges (i.e. 6-9 months) are good.
I came across an excellent blog on Forbes the other day by Steve Denning, in which he describes Agile and tries to help people navigate the complicated Agile landscape we find ourselves in. He quotes Craig Smith’s excellent ‘40 Agile Methods in 40 Minutes‘ that, when coupled with the 70 agile practices (some are on the Agile Alliance subway map) can make it very hard for people to decide how to ‘Be Agile’.
Steve cuts through the detail beautifully, and distills out 3 laws of agile (small team, customers, networks) and reinforces that this requires fundamentally different management.
It is well worth a read, and you can find it here: https://www.forbes.com/sites/stevedenning/2016/09/08/explaining-agile/#596308a5301b
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:
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.
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.