3A lightning talk at the 2015 BA Development Day conference, at Te Papa in Wellington NZ.
If we are to improve the balance between the art and science of business analysis and to strengthen our skills and approaches, then we had better break some of our bad BA habits!
There is so much waste involved in how business analysis is applied to most project methodologies and governance frameworks, from bloated requirements documents, to modules defined that are never needed, to hand-overs that add no value, to keeping people waiting, to having to rework. These are all effectively software development variants of the original seven forms of waste (or Muda) from the Toyota Production System … and there is now an eighth far more insidious form of waste of which BAs can be as guilty as anyone else.
David will share a brief rant about these BA wastes and his vision of what a lean approach to business analysis could look like.
8. Assurity Consulting Limited • BA Development Day 2015
#2: Unnecessary Features
Often or
Always used,
20%
Sometimes
used, 16%
Rarely or
Never used,
64%
Source: Standish Group
16. Assurity Consulting Limited • BA Development Day 2015
Lean Business Analysis Manifesto
Doing all of the analysis upfrontProducing what is needed,
when its needed
vs
Working with the right people
at the right time
Working in Silosvs
Building quality in
from the outset
Checking for quality at the endvs
Avoiding unnecessary steps
that don’t add value
Following a prescribed processvs
17. Assurity Consulting Limited • BA Development Day 2015
When there’s no more business as usual, why
do business analysis as usual?
Editor's Notes
Setting the scene:
Just been running a training course in Tauranga, and at the beginning I asked everyone to name one thing they loved and one thing they loathed about how they made software.
They were pretty consistent in loving:
> Adding value
> Delighting customer
And in loathing:
> Disappointing
> Delays
> Cost overruns
But this still happens and all too much, why is this, and what has it got to do with us, and more importantly what (if anything) can we do about it?
Today, we largely still follow and overly planned approach to our development and project work.
Even those working on agile projects are still typically stuck within a traditional PMO or governance model. These things are changing, just awfully slowly.
This is fine in a structured, predictable, controllable environment … but …
… increasingly today we are experiencing more unpreditable events, and when we do we are less able to control them ...
… there are several sources for this turbulence:
> Digital disruption
> Global financial crisis
> Climate change
> Regulatory change
> Natural disaster
Of course, a very well-known local example of this is what happened in 2011 … I’m not going to go into what happened or the immediate aftermath, because that’s not the point of the talk ... However once the immediate chaos and danger was past ...
… the recovery started … and organisations found that they didn’t have time fot the normal red-tape they were used to ... they adapted and adoped new ways of working ... more pragmatic, more collaborative, and leaner ... and once the recovery was firmly underway, people found that they wanted to continue working that way ...
... so what was one of the key factors in what was different?