marc tollens air france - klm process mining camp 2018 · 2020. 1. 6. · qa overload > slicing...
TRANSCRIPT
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.
