Fork me on GitHub
#bof-transformation-journeys
<
2020-06-23
>
Jose Mingorance08:06:32

GM Bryan how are you? A bit early here in the US, I am also part of the DOJO Consortium.

Jose Mingorance08:06:32

GM Bryan how are you? A bit early here in the US, I am also part of the DOJO Consortium.

Matt Cobby (Director of Engineering, Deloitte)08:06:54

I'd love to hear from people with Dojo experience (hi @jose_mingorance) , particularly from an view of teaching engineering capabilities. I run the Cloud Guild for a bank and setup a large scale academy style training programme which has lead to 1451 people become cloud certified (2330 certifications) over the last 2 years. In the last 6 months we've started running Engineering Bootcamps to help teach people how to use our shared platforms and align practices. Happy to share experiences about how we helped drive change, the problems, the hacks and the failures.

Matt Cobby (Director of Engineering, Deloitte)08:06:54

I'd love to hear from people with Dojo experience (hi @jose_mingorance) , particularly from an view of teaching engineering capabilities. I run the Cloud Guild for a bank and setup a large scale academy style training programme which has lead to 1451 people become cloud certified (2330 certifications) over the last 2 years. In the last 6 months we've started running Engineering Bootcamps to help teach people how to use our shared platforms and align practices. Happy to share experiences about how we helped drive change, the problems, the hacks and the failures.

Jose Mingorance08:06:06

Let's connect @matthew.cobby. We can give you a virtual tour of our DOJO.

Deepak Ramchandani Vensi09:06:35

it's great to see Dojo's being adopted by soo many organisations out there. Personally, I find it to be the move underrated tools that organisations have their kitbag when looking to upskill a sizeable workforce. Dojo and Engineering Game Days are a must for me, specially when looking to move into the world of SRE!

Deepak Ramchandani Vensi09:06:35

it's great to see Dojo's being adopted by soo many organisations out there. Personally, I find it to be the move underrated tools that organisations have their kitbag when looking to upskill a sizeable workforce. Dojo and Engineering Game Days are a must for me, specially when looking to move into the world of SRE!

Edu Escartí11:06:45

@nick.jenkins how did you get there 😄

Nick Jenkins (Director, Mech Rock DevOps, Perth, Oz)11:06:14

We cheated. We're a consultancy so we adopted the practices out of the box and now we try and teach clients.

Nick Jenkins (Director, Mech Rock DevOps, Perth, Oz)11:06:39

A couple of key features of ours that were organic were test first principles (tdd/bdd) and being cloud native.

Nick Jenkins (Director, Mech Rock DevOps, Perth, Oz)11:06:00

that made it a natural fit for everything-as-code pipelines

Edu Escartí11:06:52

We are currently running out of our first trials pilots and we are facing the full-scale with team that already have good KPIs saying “naah… we are already very good, why do we need this?”

Edu Escartí11:06:10

In my team we are barely starting but we have experienced a rapid increase in productivity, throughput and team-morale

Bryan Finster - Walmart (Speaker)11:06:42

@eduardo.escarti sound like they lack competition.

Bryan Finster - Walmart (Speaker)11:06:10

And yes, I agree on the team morale

Edu Escartí11:06:10

We were agile, working with Kanban but the process was just not feeling smooth, so we sat down for 2 days straight (online, so literally sitting) and challenged every-single-thing , meetings, procedure, agreements, etc. And we played KEEP-CHANGE-DITCH and started building things up from the ground up

Nick Jenkins (Director, Mech Rock DevOps, Perth, Oz)11:06:49

is your productivity all the way to production? or is it just less clutter at the 'fuzzy front-end'?

Edu Escartí11:06:37

we went from 25 deploys per 2 weeks sprints to 50 deploys per 2 weeks sprints and 6 days PR-time to 0.5 days PR-time. (Sorry, 25, so x2 increase)

Nick Jenkins (Director, Mech Rock DevOps, Perth, Oz)11:06:24

I think lowering the 'batch' size is a great way to expose the rocks in your process. but it takes a leap of faith for most teams

Bryan Finster - Walmart (Speaker)11:06:04

The experience I had is that dropping batch size is the only way to make the rocks visible.

Nick Jenkins (Director, Mech Rock DevOps, Perth, Oz)11:06:14

trunk based development is a great catalyst

Edu Escartí11:06:17

And also applying the mantra: “It’s easier to change the environment than change peoples behaviour” we forced ourselves in an environment that would “force” us to our target behaviour

Bryan Finster - Walmart (Speaker)11:06:49

"Why can't we get this code on trunk today?" and fix that problem.

Edu Escartí11:06:56

And yep @nick.jenkins trunk based was one of those decissions

Nick Jenkins (Director, Mech Rock DevOps, Perth, Oz)11:06:17

we talked a team into doing TBD and took them from 3 months between deploys to prod to 3 days

Bryan Finster - Walmart (Speaker)11:06:28

Teams are terrified of TBD until you demo to them and walk them through the reduced risk of merge conflict and regression.

Bryan Finster - Walmart (Speaker)11:06:19

On the flip side is teams trying to release fro head with 2 weeks of work. 😬

Nick Jenkins (Director, Mech Rock DevOps, Perth, Oz)11:06:07

One reason we built metrics dashboards.... oh different thread... anyway, to demonstrate lower risk with TBD and CI/CD.

Jon Smart [Sooner Safer Happier]13:06:57

I will be opening the Birds of a Feather call for Transformation Journeys at 14:25 BST. This will be hosted as a Zoom call: https://deloitte.zoom.us/my/jonsmart?pwd=TE90RFlKMFZpK00zWjRoallDSDd6QT09

Jon Smart [Sooner Safer Happier]13:06:31

Chatham House Rules apply. “When a meeting, or part thereof, is held under the Chatham House Rule, participants are free to use the information received, but neither the identity nor the affiliation of the speaker(s), nor that of any other participant, may be revealed.”

Jon Smart [Sooner Safer Happier]13:06:24

Great to talk to live! 🙂

Jon Smart [Sooner Safer Happier]13:06:44

"Continuous Learning" culture

Jon Smart [Sooner Safer Happier]13:06:13

Reward the desired behaviour: e.g. awards, eCards

Jon Smart [Sooner Safer Happier]13:06:33

Ensure that incentives are balanced

Jon Smart [Sooner Safer Happier]13:06:50

Invite over inflict. Generate social proof

Jon Smart [Sooner Safer Happier]13:06:51

Changing behaviour takes time

Jon Smart [Sooner Safer Happier]13:06:01

People have a limited velocity to unlearn and relearn

Bruno Valente14:06:06

@nick.jenkins/@bryan.finster Are there other things that should be mandatory for successful TBD?

Bruno Valente14:06:06

@nick.jenkins/@bryan.finster Are there other things that should be mandatory for successful TBD?

Jon Smart [Sooner Safer Happier]14:06:11

Great conversation @myki57 @olivier.jacques @scott.prugh @dberkholz @ben.grinnell @mark @ogheneovie.ajemuta @me1342 @dacahill7 and others!!!

Olivier Jacques, DXC14:06:43

Again, learned so much! Thank you all.

Olivier Jacques, DXC14:06:07

I could not capture the quick notes. Can you post them Jon?

Olivier Jacques, DXC14:06:07

I could not capture the quick notes. Can you post them Jon?

Yannick Muller14:06:34

I doing it for my purpose, i going to share in a minute.

Yannick Muller15:06:49

Here's my takeaways (sorry if I miss some) : How do you avoid transformation tools only : • Leadership presence • Leadership team is the N1 team • Transformation leadership • Having them onboard makes the difference. Sometimes, they are not aligned on why they need to change. Focus on outcomes expected from the change. • Recommend reading (Geene's books) for senior leadership teams. • Both bottom-up & Top down and find passionate people. • Reward the desired outcomes (trophy or e-card). Ex: At Barclays every year, teams are rewarded for new ways of working (even for failures). CEO gave teams the trophy. • Don't measure Agile behavior (Nokia example). Transformation is an ongoing effort and can be complex from people perspective and emotions • People have a limited velocity to unlearn and relearn. Confort → Fear → Learning → Mastery • Psychological safety is super important to allow transformation • Invitation over inflection. Try not to convince opponent of the transformation • Refocus on why periodically • Team Re-launch, why, culture • Metrics to follow to catch if teams are ok • eNPS • 10% capacity for personal improvement • Lead time • How many people are watching series around DevOps culture • Spotify health check template • Example of a company who test teams every 3 months with internal & external surveys • Must read on the topic : The Fearless Organization: Creating Psychological Safety in the Workplace for Learning, Innovation, and Growth by Amy C. Edmondso What kind of transformation is best : Evolution or Revolution • Depending on the context but if you have 20 years of delay you need to make a revolution. Small revolution. Small wins. Coalition. • Invite over conflict. • It's not about combatting the critics. How do you keep the momentum during the long transformation • Build a coalition of leaders who sponsor and support an drive • Grow community • Create CoP • Conferences • Core group of people : evangelising • Celebrate success • identify toxic people : address any 'brents' (who love firefighting issues) • ITIL process culture in place can sometimes be an obstacle. Reframe DevOps and Lean in ITIL Language • Continuous learning organization is an ongoing transformation. Not see this transformation as a program. Forcing function : Release on demand • Increase frequency of deployment as forcing function. • Use WIP or Time as the forcing function. As an enterprise level good way : they make people feel the pain.

Yannick Muller15:06:49

Here's my takeaways (sorry if I miss some) : How do you avoid transformation tools only : • Leadership presence • Leadership team is the N1 team • Transformation leadership • Having them onboard makes the difference. Sometimes, they are not aligned on why they need to change. Focus on outcomes expected from the change. • Recommend reading (Geene's books) for senior leadership teams. • Both bottom-up & Top down and find passionate people. • Reward the desired outcomes (trophy or e-card). Ex: At Barclays every year, teams are rewarded for new ways of working (even for failures). CEO gave teams the trophy. • Don't measure Agile behavior (Nokia example). Transformation is an ongoing effort and can be complex from people perspective and emotions • People have a limited velocity to unlearn and relearn. Confort → Fear → Learning → Mastery • Psychological safety is super important to allow transformation • Invitation over inflection. Try not to convince opponent of the transformation • Refocus on why periodically • Team Re-launch, why, culture • Metrics to follow to catch if teams are ok • eNPS • 10% capacity for personal improvement • Lead time • How many people are watching series around DevOps culture • Spotify health check template • Example of a company who test teams every 3 months with internal & external surveys • Must read on the topic : The Fearless Organization: Creating Psychological Safety in the Workplace for Learning, Innovation, and Growth by Amy C. Edmondso What kind of transformation is best : Evolution or Revolution • Depending on the context but if you have 20 years of delay you need to make a revolution. Small revolution. Small wins. Coalition. • Invite over conflict. • It's not about combatting the critics. How do you keep the momentum during the long transformation • Build a coalition of leaders who sponsor and support an drive • Grow community • Create CoP • Conferences • Core group of people : evangelising • Celebrate success • identify toxic people : address any 'brents' (who love firefighting issues) • ITIL process culture in place can sometimes be an obstacle. Reframe DevOps and Lean in ITIL Language • Continuous learning organization is an ongoing transformation. Not see this transformation as a program. Forcing function : Release on demand • Increase frequency of deployment as forcing function. • Use WIP or Time as the forcing function. As an enterprise level good way : they make people feel the pain.

Daniel Cahill - Engineer - Ontario Systems15:06:21

I made notes as the conversation went on. These were originally going to be for my own reference, so I have some personalized notes. Missing some discussion about psychological safety: • You can do something to make a hard job harder or you can do something to make a hard job easier. (Headwind vs Tailwind) • Create awards for Experimentation. Awards are cheap and positively affects morale. Helps find ways to make stories easier to share. • Invite participation don't inflict participation. • "There shouldn't be convincing, so there shouldn't be resisting" 🤯 • Just like there is a limited speed of learning, there is a limited speed of unlearning, specifically in regards to unlearning bad practices • Listen and ask questions more than talk (Two ears, one mouth principle) • To avoid "big bang" when finishing a project, release in incremements. Personal aha moment: The increments I am releasing can't just be benefits that help engineers lives. I need to make sure that some increments are directly related to stakeholders outcomes. This might help stop some of my projects getting canceled in the future 🙂 • A 5 year journey will never succeed because you can't get to the end of that five year cycle and be done improving. We need to be continuously improving. • Mechanisms to force change: • Lower WIP to a size of 1. • Temporarily halt new work to help force swarming to free people up. • Time based mechanisms. • It would be worth trying to find or consolidate a list of mechanisms to help force change. • To help fight burdensome CAB processes, create "Standard" changes and "Normal" changes. Those standard changes should be able to fit the CAB process requirements in an automated fashion to help encourage people to want to use the automated way. It also allows for us to build compliance into our pipelines.

Ovie A15:06:55

Great session guys, I had to leave midway but I see we've shared our notes which is super helpful. Thanks All. 👍