Unchaining The Analysts: Making BDUF Agile Friendly by

1 of 26

Slide Notes

As first presented at Productcamp Berlin 2013

sponsors
idealo
location: ImmobilienScout24
Catering : Zalando
T-Shirt Sponsor: Leanovate
Party Sponsor: SponsorPay
Camp Sponsor: Product Owner Dojo / proProduktmanagement / KaufDA / 1&1

This presentation is essentially in two parts

All about the problems I have identified as being pain points for Product Owners and Business Analysts, and finally some techniques that you can use solo, or with your teams, or with your BAs to help boost productivity.

Unchaining The Analysts: Making BDUF Agile Friendly

Published on Nov 18, 2015

Project managers, product owners and most people who are NOT developers struggle with defining a heavily technical solution... And business analysts of the traditional nature have this technical nous, but struggle to make the transition to using agile frameworks because of the lingering hangover of BDUF/BRUF. If your product owner is out of their depth in a technical sense, then the whole project/area of development and system architecture is placed greatly at risk from creeping bugs, unknown dependencies, and missing stories. Simply adding a BA to your team will likely create more problems than solutions without re-engineering the need to know all the facts into something that fits "just enough and Just in time".

But it doesn't have to be this way.

In this case study based presentation I explore exact the exact methods we used to upskill a Business analyst or requirements engineer, and massage their skillset into a key role that can insure that quality, detail rich stories go into any agile process, while bridging the communication gap and bringing a wealth of "Big Picture" thinking to the bite sized chunks of Scrum development.

View Outline

PRESENTATION OUTLINE

unchaining the ANALYSTS:

making bduf scrum friendly

Photo by WadeB

@miss__haley

My name is Amber, and I'm about 34% MIscellaneous stuff like cooking and reading,
32% Internet nerd - I love web technologies and new services. I specialise in UX thinking and UI/Interaction design..

But most of all I am an Agilist.
Trained CSP, i work as a Scrum master and Agile coach, and have also been Product side with Scrum as a PO.

Find me on twitter posting random things of interest..

PROBLEM:

PRODUCT OWNERS AND MANAGERS STRUGGLE WITH TECHNICAL STORIES

The big key word here is domain knowledge.

I often hear PO saying the following: "my teams have to write the stories"
Or
"this work is too technical for me"

Often the technical environment is far more complicated than first realised.

How to cope with the interdependencies of highly technical or back end stories?

Couple this with time constraints and managing stakeholders; actually making your dreams reality gets blocked and stifled.

Photo by Giovanni Toso

IMPACTS

Poorly defined stories
Poorly thought out dependencies on technical systems
Lack of understanding about how stories fit together
Inefficiencies further along the production line
Greater number of unknowns on start
BUGS BUGS BUGS

Also: low moral in team

The potential for a reduction in quality or more bugs OR that you're constantly firefighting.

It all boils down to waste: in time, team focus etc.

The biggest indicator is velocity: check to see if its changing constantly, or staying static instead of improving.

However by far the worst impact is that POs can start to feel less empowered about their products: it's not theirs any more. It becomes a collection of technical tasks.

Photo by x-ray delta one

INTRODUCING THE BACKLOG OWNER!!

SO HOW COULD A B.A HELP?

This roll was first introduced by an Agilist Shanan Holm, and refined in later role iteration By Mike Lowery agile coach.

Find Shanan on twitter @shanan
Find Mike's excellent blog posts on https://nomad8.com

This was initially a way to cope with scrum web development that had a waterfall PM over the top, and later a PO with huge time constraints.

Photo by Nina Matthews Photography

RESPONSIBILITIES

Care for the backlog
Writing stories in tandem with the PO
Being the technical interface between the team and the PO
Championing the product business view
Adding detail of domains, data interactions, system dependencies.

This is a way to leverage the strength of a BA.

They are accustomed to speaking and uncovering hidden requirements. They have one foot in Analysis and one in solution

So what this role does is channel smaller bite sized chunks of the traditional BA into quality stories that have depth and detail.

Photo by o.tacke

ADDS FOCUS

Removes detail oriented information gathering away from the team
Works as a permanent PO buddy
Runs the estimation and grooming sessions
Owns ensuring the PO's are priorities are reflected in the backlog
Responsible for training material and sessions.

The intention here is not to replace a PO but to understand the strengths and weaknesses on both sides.

A backlog owner cannot make business weighted decisions about priority, unless empowered to.
They also do not have the power to stop or change sprints.

These decision points are always resting with the Product Owner.

Photo by minifig

PROBLEM:

MOVING PAST BIG DESIGN AND BIG REQUIREMENTS UP FRONT

Predictive thinking can really mess everything up.

Photo by gadl

MOVING PAST BDUF:THE CHALLENGES

Understanding the concept of "Just enough, Just in time"
Unknowns are actually ok!
Writing user stories without getting technical
Letting go of the how, focusing on the what
Domain knowledge for the other software sopecific skills e.g. UX, UI design

Like any big change it will take patience and hand holding.

It will take the SM and the PO colab on Story writing coaching and estimation games, and expectation setting.

But i have seen Traditional BA with 25 years indentured in the same job embrace this change and totally rock it.

The point is: none of these hurdles are insurmountable.

Photo by Claremont Colleges Digital Library

10.

SOUNDS GREAT!

ERM... HOW DO WE DO THIS?

start small.
start by making the BA your PO shadow.

compare notes after meetings

the main thing that will get this rolling faster is communicating your intention, and acting with trust.

make sure you have your handoff points sorted, what escalation actions need to be in place, who is in charge of what type of communications

then comes the hard part: let go.

Photo by CarbonNYC

11.

WE HAVE NO BA!

BUT... BUT!

Ok so maybe you're a small startup... or you are a large company with no BAs embedded.

This is a hurdle no doubt but there are still methods you can adopt to help nurture whole system and lean thinking.

Start by doing simple flow charts of your audiences moving through the feature you want to develop: these user action maps will at least provide a path for deeper questions into back end touch points.

12.

TECHNIQUES

THINGS THAT CAN SHIFT THE PARADIGM

Photo by Fred Dunn

13.

ALWAYS START WITH WHY!

FOR CRYING OUT LOUD.

This seems so obvious but it is one of the most unexplained aspects of agile development.

Why we are even doing this in the first place?

This is more about communication than metric gathering but having some validated data always helps.

Get inputs from the last release, the multiple guys complaining on the phone..

Then communicate this out to the team.

Photo by m.gifford

14.

GET OUT OF THE BUILDING!

TALK TO THE PEOPLE WHO USE YOUR PRODUCT!

If you want to truly get value in development it means escaping the confines of the office

Find your users.
Get out and make contact.
discover what they need, how they use your product (keep an ear out for completely out of the box usage scenarios! This could lead to new products of markets), their pain points and how critical they are.

Because truly excellent products don't nesseccarily DO everything; they solve a specific problem, and they do this well.

Face to face is always good as you can build mental maps of the types of users you have and their demographic.

Photo by dailydoseofjoshy

15.

SEND OUT A SURVEY

UNCOVER HIDDEN USERS AND DEPENDENCIES

Another method for understanding your user base and their pain: leverage electronic tools.

Use tools like Fluid surveys, survey monkey, to gain deeper insights abut how your product is used.
Use point of context tools like Get Satisfaction, or User Voice to get indepth on the spot feedback about problem areas of your offering.

The bottom line here is as the largely unknown creator of Work Simplification, Allen Morgensen once very sagely said
"work smarter, not harder"

factoid: most people thought that was Scrooge McDuck.

Photo by DaveCrosby

16.

STORY MAPPING

CREATE A BIG PICTURE FOR RELEASE PLANNING

Quick quiz:
Who of you has a clear big picture of all the feature and function groups of your product?
Who knows about Story Mapping?
Who uses it?why do you use it?

Story mapping is a system overview. It's a lean way of doing BD/BRUF...

and a tool to validate the features of your MVP..

and a way to ensure you focus on the right things that bring value to your business and users now..

and a release plan.

Its big and visual, and it's hard to forget about parts of your product if you have one of these in your team area.

Photo by Peter Hellberg

17.

FLOW MAPPING

ATTACHING STORIES TO EVENTS AND DECISION POINTS

Blog post: Mike Lowery : Evolving the story map
http://nomad8.com/evolving-the-story-map/

Flow mapping is a flowchart on steroids.

18.

THINGS TO REMEMBER

Splitting into user roles e.g. Admin, anon user etc
Focus focus focus! One process per map e.g. Payment
You can add the layers of enhancement for anything beyond the MVP

But it also needs love. and attention

it is a living breathing piece of documentation.

Photo by Hot Grill

19.

D.O.R.

ON YOUR MARKS.... GET SET....

It is critical that the team understands what is being asked for in order to maximise value delivery.
If you as POs introduce PBI’s that are not ready to be worked on or PBIU’s that contain ambiguity, waste occurs. Waiting time = waste. emergent requirements go up.

BUT this is not Big analysis. This is a simple sanity check to make sure that you have uncovered the most important things like:
- Do we need infrastructure?
- Do we rely on effort outside the team?
- if we interact with data; does it need any kind of validation?

And most importantly: ARE THERE ACCURATE AND ACHIEVABLE ACCEPTANCE CRITERIA.

You can make it as exhaustive or as simple as you like but understand that you might not have to actually DO all the things on this list.

As long as the conversation has been had that says "nope we don't need it." Or "omg we are 3 servers short" the the DOR has done its job.

a little bit goes a long way to increase quality and productivity.

Photo by tableatny

20.

D.O.R.

Keep near the visual workspace for easy reference
Better to make releases plentiful, and high value than huge
Use top two lines for themes then epics
Horizon slices for releases
Vertical stacks for increasing enhancement within the feature group

Think of how your END user travels thru the system, the roles and system interactions that get triggered by events.

This is inteneded to be small picture thinking. A detailed view on a single user journey

Attach your stories about these interactions to the parts of the map.

Rememeber to find a cool way to mark done. just like the story map.

21.

In Summary

the light at the end of the tunnel is NOT an oncoming train...

Photo by aresauburn™

22.

MOVING PAST BDUF:THE CHALLENGES

Understanding the concept of "Just enough, Just in time"
Unknowns are actually ok!
Writing user stories without getting technical
Letting go of the how, focusing on the what
Domain knowledge for the other software specific skills e.g. UX, UI design, prototyping
and finally....

Photo by Daniel Kulinski

23.