Impact analysis, Agile-style

Impact analysis is one of the most basic tools for managing change. Yet (in my experience at least) it remains little used.

This is a problem for Agile, though not because we should suddenly start writing excruciatingly pains-taking impact analyses for everything that moves. Far from it. The problem is rather that, Agile is best done when all the participants are already more or less experienced in all the major managerial and technical techniques. That is the reason why Agile is able to be so informal: because the team already know a) which techniques really add value; and b) how to do the ones that remain, without having to read a manual, fill in forms or hold a formal meeting.

So if impact analysis is a valuable technique (and it most certainly is) yet relatively few practitioners of Agile have much hands-on experience of using it, how do we get the benefit of impact analysis without incurring the cost of formal procedures? It’s hard to say: it’s really quite hard – and generally counterproductive – to insert ‘hard’ controls like this back into Agile, even if they are nominally valuable.

So to be going on with, the table below suggests a list of things most managers with experience of impact analysis know they need to ask about when a change is proposed. You don’t want this to turn into a formal procedure – even a checklist can quickly bog the team down in endless debate – but the team should be able to quickly home in on which of the issues suggested below are relevant, and come up with the right questions.

And as ever, the change being proposed should be compared with ‘no change’. Don’t assume that ‘no change’ has no impact – the whole point of many changes is to avoid or undo the negative impact of the current approach, a shift in the environment or to take advantage of an opportunity no one had previously expected.

Area of impactKey issues
The business case for the change.
  • Is it clear what both the costs and benefits of the proposed change are?
  • Is it possible to compare these with the equivalent costs and benefits of ‘no change’ – i.e., rejecting the proposed change?
  • Are both answers in the same units (hours, money, etc.)? If not, in what sense are they comparable?
  • How credible are either sets of answers?
  • How would this change affect our risk profile?
  • Can any downside of this change be dealt with in later iterations/releases?
Impact on scope.
  • Which stories will be affected?
    • Directly?
    • Indirectly?
  • Who will be affected negatively?
    • What do they think of the change?
    • Can their needs be accommodated in other parts of the release?
  • What will the relative impact be on:
    • Design & architecture?
    • Development?
    • Integration?
    • Testing?
    • Acceptance?
    • Deployment?
  • What will the relative impact be on:
    • Schedule?
    • Budget?
    • Resourcing?
  • How will this change affect other work:
    • The rest of this iteration?
    • The rest of this release?
    • Neighbouring iterations & releases?
  • How much work will need to be:
    • Redone?
    • Changed?
  • Will the proposed change affect compliance, contract or any other binding commitment?
  • What will it take to carry this change out? Will carrying out this change be quick and simple, or more like turning an oil tanker? What is the impact on time likely to be?
  • What is the ‘opportunity cost’ of this change – what are we prevented from doing by choosing to do this?
  • So what should we do?
    • Implement the change?
    • Implement the change, but with modifications?
      • If so, what exactly are these modifications? Are you sure that they don’t invalidate the original purpose of the proposal?
    • Reject the change?

Just a thought.

By |2017-10-24T12:08:46+00:00Tuesday, October 4 2016|Categories: Agile, All, Business case, Change, Management systems, Requirements, Risk, Stories|0 Comments

About the Author:

Chief Architect,

Leave A Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Want to do more than just build systems?             
error: Agile201 is wholly copyright and copy-protected.