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

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

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.

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.

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

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!

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!

@nick.jenkins how did you get there 😄

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

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

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

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?”

fair question.

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

how? what did you adopt?

@eduardo.escarti sound like they lack competition.

And yes, I agree on the team morale

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

Yes! This!

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

https://www.youtube.com/watch?v=MHK16QNVXXU

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)

nice.

Very nice

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

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

trunk based development is a great catalyst

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

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

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

nice

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

they didn't believe they could do it

but they trusted us enough to try

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

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

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

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

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.”

Great to talk to live! 🙂

"Continuous Learning" culture

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

Ensure that incentives are balanced

Discussing mindset

Invite over inflict. Generate social proof

Changing behaviour takes time

People have a limited velocity to unlearn and relearn

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

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

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

Again, learned so much! Thank you all.

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

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

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

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.

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.

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.

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