marc tollens air france - klm process mining camp 2018 · 2020. 1. 6. · qa overload > slicing...

Marc Tollens Air France - KLM Process Mining Camp 2018

Marc Tollens

Digital Product Owner Air France - KLM Committee member Platform Digital Analytics

@marctollens /marctollens

What is new today…

is the new normal tomorrow.

Customer expectations are getting higher every day.

And we have to keep up.

Our way of working didn’t match the pace of the new reality.

Get requirements

Maintain

Create design

Implement

Verify

6 months

We adopted a different approach.

Product owner Prioritises the work.

Developer Builds the product.

Scrum master Guards the process.

QA Tests the product.

Velocity.

The measure of the amount of work a team can tackle during a single sprint.

Build wheels

Build board

Attach the two

5

2

13

Velocity.

Feature: build a skateboard

Yellow team

Internet check-in

1 Product owner 1 Scrum master

1 Designer 1 Tester

4 Developers

Meet the teams.

Green team

Trip management

1 Product owner 1 Scrum master

1 Designer 1 Tester

3 Developers

Orange team

Profile

1 Product owner 1 Scrum master

1 Designer 1 Tester

6 Developers

So…

We have very talented scrum teams, however our velocity feels quite low.

Any idea why?

And this is the only clue you get.

Enter process mining.

Once something becomes digital, it becomes measurable. Once something is measurable, you can improve it.

The approach

Define scope.

Mine the activity data from JIRA.

Cleaning.

Visualise process.

Start the conversation.

A predefined set of sprints.

Only include items that were started and ended during those sprints.

Only include activities that happen after a story went into progress.

Team yellow process map

Team yellow process map

Open In progress In review In QA Done

77% of the stories are completed in a timeframe that fits within a sprint

62% of the stories are not completed in a sprint

40 working hours it takes to QA stories.

55% to next step 18 working hours till next step

60% to next step 40 working hours till next step

100% to next step 19 working hours till next step

Throughput rates and times looking only at the direct steps in the ideal development flow

Team yellow outcome.

Team green process map

Team green process map

Open In progress In review In QA Done

11 working days the average time it takes to complete a user story.

0% of stories followed the ideal development path without any deviation.

66% of stories followed the ideal development path without any deviation when ignoring those who were only moved a sprint.

17% to next step 52 working hours till next step

50% to next step 61 working hours till next step

80% to next step 56 working hours till next step

Throughput rates and times looking only at the direct steps in the ideal development flow

Team green outcome.

Team orange process map

Team orange process map

Open In progress In review In QA Done

17% of the stories went from progress to review within a sprint without deviation.

53% of the stories were adjusted (estimations, content & design) after they went in

progress .

6 working days the average time it takes to complete a user story.

17% to next step 2 working hours till next step

67% to next step 2 working hours till next step

100% to next step 13 working hours till next step

Throughput rates and times looking only at the direct steps in the ideal development flow

Team orange outcome.

In progress In review In QA Done55% to next step 18 hours till next step

60% to next step 40 hours till next step

100% to next step 19 hours till next step

In progress In review In QA Done

17% to next step 52 hours till next step

50% to next step 61 hours till next step

80% to next step 56 hours till next step

Orange team

Yellow team

Green team

In review In QA Done

17% to next step 2 hours till next step

67% to next step 2 hours till next step

100% to next step 13 hours till next step

In progress

Comparing the teams.

Maturity, stability and preparation matters.

QA overload > Slicing up user stories in subtasks.

QA overload > Review scope acceptance criteria.

Deviating development paths > Not ready, not in sprint.

Suggested improvements.

Team yellow process map period 1

Team yellow process map period 2

Team orange process map period 1

Team orange process map period 2

The good -Getting data out of JIRA was easy, either manually or via the API. -Lots of variables available. -Visualisations help non-data savvy people understand what is happening. -JIRA projects for the different teams followed a uniform process.

The bad -Deciding on what keep (e.g. comments like “Is available on test environment”). -Lots of activities during the planning session.

The ugly -Dealing with flexible working hours and working remotely (timezones). -Lack of timely JIRA administration by scrum team.

Take-aways.

Pictures say more than words.

Data is black or white, reality is not.

Don’t offer solutions, pave the way instead.

Once a measure becomes a target, it ceases to be a good measure.

Thank you!

marctollens@gmail.com @marctollens /marctollens