1 of 16

Slide Notes

DownloadGo Live

Readiness - The key to quality and speed in agile

Published on Jan 12, 2016

Readiness is something which has been, and will be hotly debated in the agile community. Personally, I love the concept... But Then I was a Business Analyst for years. Consider this scenario; Your development team is plagued with unexpected work, high bug counts and seemly never ending technical debt.. and very little traction on actually moving through the product backlog.

A Nightmare situation.

The morale impacts of constant problems on a team and no progress through the "interesting" work are brutal. The fastest way to drive productivity into the ground. So how did we get here, and where is a good place to start looking to solve these problems? In my opinion: start at the start. Look at the quality contained within the cards entering the sprint or iteration.

To excel at Just enough and Just in Time requires a level of pre-work before the sprint starts, and honing this pre-work is what a "The Definition of Readiness" is all about.

Quality in; Quality out.

View Outline

MORE DECKS TO EXPLORE

PRESENTATION OUTLINE

1.

Readiness

The key to assuring quality and speed in agile
Photo by tableatny
2.

hello world

I'm Amber
Im about 30 percent nerd, and 70 percent weird agilist
Photo by appleswitch
3.

problem

Bugs... loooooots of bugs
with system opacity (MEANING LOW TEST COVEREAGE) and general instability, the chance of affecting a component or monolith with new work is high indeed.

Even worse is when new work fixes a bug and we don't know why
🤨 I mean cool but ??
Photo by urtica
4.

problem

cards added during sprints
Emergent work - this is a symptom of not understanding the context, complexity or domain of the work to be done.

Team enters into cycles of discovery (defining and uncovering unknowns) during what *should* be a phase of pure execution.
Photo by JasonParis
5.

problem

scope creep
Emergent work - this is a symptom of not understanding the context, complexity or domain of the work to be done.

Team enters into cycles of discovery (defining and uncovering unknowns) during what *should* be a phase of pure execution.
Photo by JasonParis
6.

problem

doing discovery during delivery
Emergent work - this is a symptom of not understanding the context, complexity or domain of the work to be done.

Team enters into cycles of discovery (defining and uncovering unknowns) during what *should* be a phase of pure execution.
Photo by JasonParis
7.

problem

technical debt
execution with un understanding that something may break, be unstable, not production ready, or super prototype-y.

Technical debt is not in and of its self bad, its just doing fast workarounds all the time means this adds up into patchwork systems
Photo by Richard Masoner / Cyclelicious
8.

problem

patchwork architecture
execution with un understanding that something may break, be unstable, not production ready, or super prototype-y.

Technical debt is not in and of its self bad, its just doing fast workarounds all the time means this adds up into patchwork systems
Photo by Richard Masoner / Cyclelicious
9.

problem

domain knowledge
This factor comes to most all of the time.... unless they are working with repeatable work in the same systems regularly.

New feature or new product development triggers this condition.
e.g. a team that specialises in search functionality having to design a KYC* process for online.
Until the different facets of KYC including system design, architecture, pest practices and regulatory environment are understood, the likely hood of bugs, weirdness, technical debt, or even regulatory penalties for violations etc are a real and likely possibility.

Discovery phases and spikes are super helpful here, as is high quality LIGHTWEIGHT documentation of research outcomes.



*KYC=Know your customer - used to verify client identity and in some instances also used to assess risk.
Photo by Wonderlane
10.

problem

system traceability
This factor comes to most all of the time.... unless they are working with repeatable work in the same systems regularly.

New feature or new product development triggers this condition.
e.g. a team that specialises in search functionality having to design a KYC* process for online.
Until the different facets of KYC including system design, architecture, pest practices and regulatory environment are understood, the likely hood of bugs, weirdness, technical debt, or even regulatory penalties for violations etc are a real and likely possibility.

Discovery phases and spikes are super helpful here, as is high quality LIGHTWEIGHT documentation of research outcomes.



*KYC=Know your customer - used to verify client identity and in some instances also used to assess risk.
Photo by Wonderlane
11.

causes

poor quality in the work items
Photo by anyjazz65
12.

UNKNOWNS

yup... too many of them
the key point here is that if a team starts with with too many unknowns on it's plate before start, then likely outcomes will touch all the problems mentioned.
Photo by Hello Turkey Toe
13.

The D.O.R.

Definition of Ready? What is this anyways?
Photo by tableatny
14.

There are two points of Quality Assurance
in Scrum...
The way in,
and the way out

15.

Lets focus on the way in

The DOR helps teams to ensure the right stuff happens at the right time.
16.

Quality In; Quality Out

Thank you for listening!

for a deeper dive (that boarders on satirical rant) check the article I wrote on Readiness here: https://medium.com/@Miss_Haley/the-contentious-issue-of-being-ready-2c14bb5...

Amber Haley

https://www.linkedin.com/in/hyperaktiv