This document summarizes the experience of using Kanban to improve software development processes at Petrobras, Brazil's largest oil and gas company. It describes how Kanban was initially introduced to a software development area with 30 teams. Kanban practices like visualizing workflow, limiting work in progress, and managing flow helped improve throughput and productivity for many teams. However, some teams struggled with lasting change. The document then focuses on how Kanban helped three "non-agile" teams that supported critical legacy systems by limiting work in progress, measuring and improving flow, and implementing feedback loops with customers. These practices addressed issues like long lead times and too many non-value-adding activities.

1. Solving the right problems with
Kanban
A tale of 30 teams
Amanda Varella
1

2. 2
About me
Agile/Kanban Coach
One of the 2014 Brickell Key Award
winners for the Kanban adoption at Petrobras
8 years as change agent
Agile/Kanban Coach

3. Context
3
Petrobras is the biggest oil and gas
company in South America
The company is formed by business
areas of Exploitation and Production
of oil and gas, and also other
supportive areas. Its huge IT sector
is segmented by business support

4. 4
Context
Our IT area supported the main business of
the company, developing systems to
support the production and exploitation of
oil and gas.

5. Structure
5
Databases Infrastructure
Software
Development

6. SNEP – Software Development Area
293people
4coordinations
~30 teams
... and a forward
thinker manager

7. Software Development Area
7
QAs
Data
base Desig
ners
Teams
(developers
and leaders)
Scrum Teams
No metodology
teams
Corporate
Systems
Business specific
and scientific
Systems

8. Continuous Improvement Team
Purpose: help the teams get into a state
of continuous delivery
8

9. 2008
2009
2011
2013
2015
First Scrum
team
Expansion to
other teams
Kanban
(Visualisation)
Another story
begins
Maturing of Technical Practices
9
Journey
Kanban
(Metrics)

10. The experience was not a rose-
strewn path
10

11. Culture
Interface
with other
areas
Low interest in
adoption of technical
practices
Many teams
People working together
for too long with
specific ways of working 11

12. The changings that the teams
are passing through are
longlasting?
Have they really transformed into
Results?
12

13. Some teams had great improvements and kept
going
Others got better, but took some step back
Others stayed at the same
Fortunately no team got worse than before
13

14. Challenge: how to promote
longlasting changes?
14

15. 15
Scrum was running good enough
for most of the teams, now the
bottleneck was moving
Databases
Infrastructure
Software
Development

16. 16
David Anderson
gave his second training
in Brazil in 2010,
where I knew Alisson
Vale
In that same year, I hired
him to help us improve
things
2011

17. 17
Databases
Infrastructure
Software
Development
Initial Idea: trying to convince the managers from
Infrastructure, and Database areas start with Kanban
Kanban
Kanban
Scrum

18. 18
Databases
Infrastructure
Didn’t work… the managers initially liked the idea,
but didn’t put the effort to choose a pilot, make it
work. It was someone from outside
proposing something...
Kanban
Kanban

19. 19
And then we had Alisson, how could we use his
services now that the original plan had failed?
Well, let’s work inside the
software development area,
after all, we still have many
things that can be improved.

20. Start with what you do
now
20

21. 21
QAs
Data
base Desig
ners
Teams
(developers)
Corporate
Systems
First experiments: Kanbanizing the services consumed
by the software development teams
The structure had worked that way
for many years.
We thought that making these professionals
work in cross-functional teams would be
very disruptive and could hurt their
identities, hence, provoking more
resistance.
Also, there were economical reasons that
could justify the functional groups.
We just didn’t know if would work, we just
tried.

22. 22
Internal Database Group as a Service
Data
base
Teams
(developers)
Corporate
Systems
Databases
The database area takes care of the huge Oil
and Gas data from Petrobras
There were strict rules in how to interact
with this database
The internal database group helped the
interaction between the software
development teams and DB area.

23. 23
Internal Database Group as a Service
Experiment worked.
The team was formed
by 4 people, and the level
of service provided to the teams
was enough. No complaints!

24. 24
QA as a service
24
Teams
(developers)
Corporate
Systems
QAs
QA was a traditional testing group.
They received code to test after developed,
needing much more documentation
than was needed.
Service levels were not met
With the constant complaints
of the developers, it was clear
that the model wasn’t working
Now, It would be easier to change.

25. 25
QA inside teams
25
Teams
(developers)
Corporate
Systems
The QA were assigned to the teams
Some of them were assigned to 1 or
2 teams
Some teams stayed without
a QA role
The assignment was based
on the criticality of each
System developed

26. 26
Designers as a service
26
Teams
(developers)
Corporate
Systems
Due to the nature of the systems,
most of them didn’t need full
time designers
Desig
ners

27. 27
Designers as a service
Experiment worked!
They classified the job using T-Shirt sizes
and assigned SLA targets.
Most of the times they had a DDP of 90%
or more.
Plus, the development leaders evaluation
saying that everything was okay
IN OUT

28. Navigating through
Kanban Practices
28

29. Visualise
Limit WIP
Manage Flow
Make Policies Explicit
Implement Feedback Loops
Improve Collaboratively, Evolve Experimentally
29

30. Continuous Integration
All jobs green in 1
week 30

31. 30% reduction of
Technical Debt in 1 year
31

32. 32
4coordinations

33. 33

34. 34
Team Boards – Kanban Systems

35. We started with many physical boards
35

36. We moved buildings, space has changed,
some teams started using Jira
36

37. We lose some things,
gained others
37

38. Evolving other Kanban practices
38
Visualise
Limit WIP
Manage Flow
Make Policies Explicit
Implement Feedback Loops
Improve Collaboratively, Evolve Experimentally

39. Kanban with non-agile
teams
39

40. 4040
Scrum Teams
No metodology
teams
Do you remember those
#nometodology teams?

41. 41
No methodology teams
• Supporting core Business functions: production of
Oil, Gas and Water
• Each team had an average of 10 years of existence
• Development regulated by SOX. Requires formal
approvals and acceptance
• Legacy technology: Centura
• Senior Developers (experience and age!)
• Critical systems. If they stop, Petrobras loses millions
Conclusion: No Agile kids around here!

42. And from a specific problem, an
opportunity arises
It all started with their Delivery
Manager asking…
42

43. Amanda, can you hide who is doing
what on Jira?
Lean Kanban India 2017
43

44. Look, that is no way of doing it….
...but, why do you want this?
44

45. The customer
wants to control
our work
He wants to say
who does what
in the team
He said that he
will come here
every week
He snoops Jira daily
to see who is doing
what
45

46. New representative of
an old client
3 teams, similar problems
What was happening...
46

47. Hiding who was
doing what in
Jira definitely was
not going to solve
the problem
And possibly, the problem was...
47

48. Hypothesis
New customer
doesn’t trust team’s
work
48

49. We had a conversation with the customer, explaning
the changes that we would like to implement
Nothing would change too much, except for the fact
that we wanted to start a limited prioritisation scheme,
that this would make items move faster...
But, if you want to reprioritise, something must leave.
Avoid reprioritise what had already started. Only
prioritise what you really need.
We told that we were going to do some experiments
with it. If didn’t work, we could rollback again.
Meeting with the Customer
49

50. Kanban to the rescue
Visualise
Limit WIP
Manage Flow
Make policies explicit
Implement Feedback Loops
Improve collaboratively, evolve experimentally
50

51. Software development Board
Customer Board – Used for Prioritisation and condensed view of In Progress items
Visualise
51
Being a SOX regulated system, all User Stories needed to be approved by the customer
(moved in the board by him) and in the end, accepted also by him.
Also, there were several Jira rules in terms of other work: developer, testers...

52. Limit WIP
Teams with 3 people
had 20 items in
progress
52

53. Manage Flow
Cumulative Flow
Run Charts
Throughput
Lead Time
Failure rate
... and other measures
53

54. SAG
Work starts
Many things waiting
for Deploy
Less WIP in waiting
for Deploy
???
Managed WIP
Manage Flow
Cumulative Flow
54

55. Work Starts
Coach
leaves
Some irregularity
after
Not respecting
WIP
Going back
to normal
55
Manage Flow
Cumulative Flow

56. Work starts
56
Manage Flow
Cumulative Flow
This team was doing well,
but they were not so disciplined
with the tool...

57. Manage Flow
Run Chart– Team 1 – User Stories
57

58. 58
Manage Flow
Run Chart– Team 2

59. 59
Manage Flow
Run Chart – Team 3

60. 60
Problem: Customer is not
satisfied with our throughput, he
also says that things take to long to
finish
Let’s understand why...

61. 61
Manage Flow
Cumulative Type Chart
0
10
20
30
40
50
60
70
80
Defeito
Reunião
Consultoria
Suporte
Story
Problem: we give too many support calls and go to many
unnecessary meetings

62. 62
Manage Flow
0
10
20
30
40
50
60
70
80
Defeito
Reunião
Consultoria
Suporte
Story
Maximize value adding activities
Minimize non-value adding activities
Problem: we give too many support calls and go to many
unnecessary meetings

63. 0
10
20
30
40
50
60
1 2 3 4 5 6 7 8 9 10 11 12
Support calls
Suporte
63
Support Calls
Manage Flow Problem: we give too many support calls and go to many
unnecessary meetings

64. Manage Flow
Throughput
AVG = 7,5 stories/month
AVG = 10 stories/month
AVG = 5,3 stories/month
64

65. User acceptance times
65
Manage Flow Problem: customer takes too much time to accept features

66. 66
1%
15%
2%
3%
4%
73%
2%
Percentage of User Acceptance Time
Impedimento
Fazendo
Aguardando Teste
Em Teste
Preparando Homologação
Em Homologação
Homologado
Problem: customer takes too much time to accept features

67. 67
Manage Flow
Defects Rate

68. 68
Manage Flow
Lead Time

69. Make policies Explicit
Work Item Types
69

70. 70
Make policies Explicit
Visible policies at team area
WIP and standup
policies
Work item type
definitions
Jira policies…

71. Implement Feedback Loops
Weekly replenish meetings with customer
1
2
3
4
5
1
2
3
4
5
71

72. Monthly
Team + Delivery Manager
Analysis of data, what happened and
opportunities for improvement
72
Implement Feedback Loops
”Operations Review”- Current Service Delivery Review

73. 73
Implement Feedback Loops
”Operations Review”- Current Service Delivery Review
The teams were very comfortable with the meetings, and they
were seeing value in analysing good metrics for teams and managers.
Until now, I have never seen such a thing!
“The best management tool to not
mess up with the data!!"

74. We started doing standups with the 3 teams
Some of them decided to keep, others not
As they were working together for many time,
comunication was not a issue
Also, the new boards were self explanatory
74
Implement Feedback Loops
Stand up meetings

75. Improve Collaboratively, Evolve Experimentally
Problem
Hypothesis
VisualisationMetrics
Results
75
We entered into a virtuous cycle of
instead of jumping into a solution
of a problem, we first built some
visualisation or chart that would
help us understand better the
nature of the problem
Many of them were solved without
us taking any action!

76. Results
There was no need to
hide from the customer
who was doing what
76
Lean Kanban India 2017
Lean Kanban India 2017

77. Customer stopped asking
about it
There were still some minor
attempts of task assignment,
but the Delivery Manager
handled the naughty behavior
77
Results

78. Teams got more visibility
of their own activities
They achieved a structured software
development process
(it became a benchmark in the company in terms of SOX
Compliance)78
Collateral Effects

79. The frequency of replenish meetings started to decrease
The customer started to prioritise the work directly on Jira, and doing on-demand
replenish.
He knew exactly what was happening during the development
Customer stopped appearing!
That was not exactly what
we wanted!
79
Collateral Effects

80. 80
After these 3 teams, 5 more teams
adopted this same approach of Service
Delivery review
Tackling the right problems with
Kanban

81. 81
Transparency Balance Customer Focus
Collaboration Flow
Understanding Agreement Respect
Leadership

82. 82
Thank you
Solving the right problems with
Kanban
A tale of 30 teams