Oh - I think you are answering that now!

yes 😉

basically the 'Shell' app that is in the Apple App Store and the Google Play Store. It's main functions are information about gas station (location, services), paying with the app for gas or services, and insights in your own driving behaviours or carbon footprint/impact

> insights in your own driving behaviours or carbon footprint/impact Cool!

insights in your own driving behaviours or carbon footprint/impact -> how is this connected to the app?

basically we started working hand by hand with the teams - doing engineering activities too. We brainstormed together and informed them about practices or changes we could do to make their life easier. Then based on that we started the improvement

always giving what the teams and different department needed, not just our happy (and most of the time crazy) ideas

So were you embedded in those product teams rather than a central transformation team?

most important here (in my opinion 😉) was that we stressed that we were there to help them, instead of telling them how things are going to be changed. That also helped focussing on things that were really important for the teams and helped finding the low-hanging fruit that wasn't immediately obvious without these first steps.

we’re a central transformation team that is actually embedded in the teams. If we’re too much high level, we won’t never know what they really need and how they are really delivering.

so we have to stay connected with the most juniors developers as well as with the CTO

Cool, so we are then talking about some common and collaborative goals set with them. Plus the necessary link back into CTO for common patterns, reuse, learning etc

Indeed, we are (sort of) part of the team. Especially from a technical point of view. So we showed them initially how they could do things and build stuff like pipelines for them. Then we slowly try to get the teams to pick things up themselves. Besides the engineering part, coaching them was also a big and important aspect.

Thank you. Do you have both Transformation and delivery skills within your team that longer then looks to the product team to build their capabilities

yep, we ourselves do engineering activities but also politics. Sometimes is too much, but it feels it works fine

Depends on what you mean with measure. If you mean the impact/value it has on the business, then there is only one real way: releasing the 'story' ASAP to the customers. That way, you can validate your assumptions.

That is really helpful, because it helps focus your efforts on what matters. Nothing is more wasteful than building features based on assumptions about how you think your users are going to be using them, when it turned out that those assumptions were wrong. If you released those initial assumpted features more quickly, you could have measured that it was not worth it to continue down that path.

In one of the slides you talked about your before and afer metrics - including number of stories per sprint. I’m wondering what is counted as a single story.

ah okay, let me explain those numbers a little bit

I’ll share that at GitLab we measure our development “efficiency” based on MR (our version of PR) per engineer, not issues because they can be varied scope.

the "stories per sprint" measurement was based on a team per team basis, based on their velocity and the average story size. This is really delicate, because understanding those numbers is not straight-forward (especially project management could see those numbers as individual productivity, which is not really fair)

:thumbsup: - Yeah agreed to not consider it individual productivity. Makes sense. Thanks!

then based on the amount of 'overhead' we have found in the plan and assessment stages we can calculate the possible (but realistic) increase in amount of stories

One thing we found when focusing on PRs is that it gives the incentive to break work down into smaller and smaller code contributions which have a higher likelihood of shipping and not getting stuck in long review cycles.

I agree that is is not maybe the best way to measure things like that, but I really want to 'measure' things like this in a transformation, because if you measure, you can validate and keep your KPI's in track. Otherwise it will be a lot of guessing.

@kenny I like that idea. Smaller iterations are easier to ship and even the smallest change brings value to the end customer. And I am kind of overusing the word 'measure' here, but after you release it, you can measure it for real and the base your decisions on that. Especially Product Owners like that (sometimes you need to convince them in the beginning, but once they see the upside to releasing in smaller chunks, they are sold).

Plus, releasing smaller and smaller changes will eventually become 'continuous' releasing, which is like the ultimate goal of DevOps

Agreed - I’m a product owner by trade and you want to ship perfection but after some time operating in a high iteration environment you love the constant learning.

yes, we used Sonar for that. It’s of course a not fully accurate metric, but at least it gives the team the perception of code quality

initially (2 years ago) we were releasing every 3 months although quite random way to measure 3 months. With Improvements we placed fixed releases every 3 months. Then 2 months, Then 1 month. Now 2 weeks (sprint length). And currently our systems allow each of the teams to release their components (Android, iOS, NodeJs…) every day if they want. But still we require more fear-removal to do that.

Great progress!

:thumbsup:

yes, we work on that. Everything to satisfy our guys, make them happier, and their life easier. None of the changes we did would work without a mindset change. It’s a lot of new ways to do things, sometimes hard to adopt. Mindset change is crucial

I agree, so this was an assumed outcome/by-product of the way of working and flow of work?

we measure as well “happy points” and conduct team and personal level surveys. Just think about all the improvement actions coming from the retrospective, if you can solve them, the team becomes happier. E.g. debugging is a pain, no one knows which version is where, deployments have to be done manually with a virtual call…..

removing all these things (that requires a HUGE mindset change) makes people happier

do you guys measure the psychological safety of the teams @guillermo.a.martinez

Yes. Because otherwise, changing their way of working wouldn't work properly. They need to want to change themselves! So happiness is really important, but I would say motivation is even more important (which will eventually lead to happier team members of course)

indeed, we’re the DevOps Enablement. We enable DevOps, we have to make the teams become DevOps. They need to want it. Otherwise we achieve nothing

@me1342 I really like the idea of that. It is not currently included in how we have approached this transformation. Now that we are all working from home due to the Covid pandemic, there is a big corporate push from both Accenture and Shell on there psychological well-being, which is kind of nice, but it's not embedded in our process. We are now talking about SRE's, and have been talking about the psychological aspect of that by the way. But I really feel that it makes a lot of sense to more explicitly cover the psychological safety in transformations like these.

It’ll be cool to find a right way to measure and help on it

Would love to have a chat- we live and breathe Psychological Safety as the only sustainable lever of high performance. We make a team solution to measure it yes but more importantly to make more of it increasing the team’s EQ and their People Practice - happy to have buy you a virtual cuppa and show you a demo of what we made if you liked

Hey @guillermo.a.martinez, do we have time somewhere this week? I'm really interested in the demo @me1342 is talking about!

could it be next week? 😅

nah too late, we’ll have been out of all Psychological Safety software by then 😉 will ping you both so we sort it for then - anyone who knows it’s priority is awesome in my book so looking forward to it

I’d be really interested in this as well if it’s an open invite?

Nope, only them:) totally- let me ping you. In fact we still have our Covid-19 response out so it’s free and we’ve been onboarding loads of cool teams but few as DevOpsy woke who actually know the value of Psychological Safety from the unicorn’s mouth 🙂 as everyone here so needless to say l’d love to talk to everybody and get you on even if it were for now while we’re giving it away! The offer should be on the website at http://www.psychologicalsafety.works

baby steps, one week we work in a component or a couple, next week in another one, and so on…

Got it Thanks!

How did you realize the amazing decrease in unit test execution time?

Gradle, XCTest, npm execution improvement mainly -> parallelization, poper machines, caching…

Wow - just think about all that developer time saved. Awesome work!

thanks!!

I know what you feel 😉

Yes, and sometimes the organisation needs to learn by itself and be unwrapped from the bubble wrap

yep - EA should be the ones keeping lookout, acting as air traffic control, not telling people how to build

100%

I don't have a software development background, but as an editor of dev content, it always amazes me how eager participants of every part of the process are for continuous iterations

The buzzwords can get a little funny, but there are real needs there

😀

😂

Exactly what we did at Barclays

In a regulated industry such as banking. There has to be some level of governance. Whats needed is functional boards, not ivory tower boards

i can relate. same boat as you right now.

Yes, and as I say - there’s not a 1-off sign-off if you’re doing agile / DevOps / CD

Because there’s no design phase

So governance needs to be much more sophisticated and continuous

(That section is from what we did group-wide at Barclays for continuous governance)

yes… i think the key to that is driving joint accountability… we are successful as a product unless we meet the criteria that has been agreed upon. if it feels like a “burden” and not “what we do”, then things need to change

Absolutely. Collaboration.

Easier said than done imho :)

Yes, you need a structure to nudge it

for sure! agreed @anand.patil

It was very painful at Barclays with a huge culture of adversarial relationships between the architects and the development teams

We basically took the formal SDLC process and hacked it to bits to force continuous conversations

The new breed of Engineers hate the word 'architecture'

They don't have time to read a 30 page strategy document

They shouldn’t need to really

See later - but most standards/outcomes should be as automated as they can be

And others should be conversational

@anand.patil - what i did before is to simplify things. just boil things down to Strategic Intent, Tactical Objective, Constraints (time, budget, tech, etc), Restraints, and Resources. Then have them come up with a solution on their own. that allowed me to have independent teams move on their own. the conversational part was the one i was missing.

It depends, is always the answer :)

Building relationships is a key trait for EAs

Social capital is so crucial

I see. Did you find that there was some existing mistrust that you had to rebuilt to get your footing?

With other teams

In many places, yes

Enterprise architects are, as I quoted Mark Schwartz as saying, seen as bureaucrats

So people avoid them

You have to be seen as generating positive value for the organisation

Also depends on whether they see any value in the interruption by the architect. What’s in it for them to interact - in the old world it was ‘you have to talk to me because I’m governance’ - in the new world you need to offer them ways to improve what they do

Exactly exactly

More carrot than stick

Ah fair enough. I saw the "ivory tower" comment in the other thread, and that gave me an idea about possible sentiments

It can be but also that can be a convenient defence.. I’ve worked with architects who are more in love with the process and metamodel than the impact it has on the ability to deliver

Also architects need to show respect to the developers and experts knowledge and experience

It goes both ways, coming from our architecture group, I get a lot of resistance when working with the dev team because they assume I am just there to meddle or tell them how to do things because of past architects. Been working on fixing our brand over the last year

And that would be the point of convergence where governance becomes more of a perceived strain than an added value

I find that it’s best if you come bearing gifts. Like we had a team that could not get a message bus as part of the platform and they implemented some crude message passing in shared relational database and the feature kept causing problems both to ops and devs. Solve the problem for them, get them the correct technology to implement the feature, pass it through the hurdles and you make the listening easier.

That's what I was getting at/wondering too @joyner.matthew.

yep - often the ‘why’ of governance falls back to ‘just because’ or ‘legal or industry compliance’ as these are easy defences

you need to explain why it benefits them

"Come bearing gifts" I really like that

Seems like both sides have to kinda level their walls to get to the continuous conversation goal. Really drill down into the need and benefit of governance with respect on and for both sides

Yep. I use a ‘placemat’ (a diagram with boxes round it for questions, requirements, goals etc) as the basis of the conversations as it acts as a grounding point. Along with the questions - is this right? / what am I missing?

Am I right in thinking that those questions have an implied "people element" to them?

In other words, not just "Is this technically right?" but "Am I doing right by my stakeholders?" @m.goble

kinda - the first (is this right) is more to start a discussion around the diagram and notes on what we’re trying to achieve - it’s not unusual to find people think things are being done for multiple reasons) also personally I always work from the assumption that I could of gotten things wrong so always best to check. In terms of the what am I missing - am i missing key requirements, context, components but also people - i.e. who else should I speak to about this?

I once did an internal study in our company where I asked if people knew the company strategy - the vast majority said yes - however when I asked them to give me details of the strategy most were wrong - alignment is key as things move and context change. Why it’s important to do something is key

Ah ok. I think I misunderstood the process; thanks for clarifying. I'm really interested in trying this on my own team; looks like a really good tool to drill down and cover all bases around conversations like this

This is a long answer! Will get back to you in a few mins :)

Effectively you are going to need a new team for the new Microservice. It’s both adding a layer to the old system but also reducing its complexity.

But have a look at Team Topologies book

It's on my list 🙂

The slidedeck is also already available on Github: https://github.com/devopsenterprise/2020-London-Virtual/blob/master/Day%201/Breakouts/Simon%20Rohrer%20-%20EA%20is%20dead%20long%20live%20EA.pdf

Oh! Treasure trove!

Long story - 10 mins and I’ll at least start it :)

So in Barclays we used a forcing function

It’s written up in Sooner Safer Happier - but we created Control Tribes and included EA there, per effective value stream

In Saxo we inherited one - luckily it was already the way of working when I got here

It will depend on your context. Where are you? what’s the current setup?

The customer I'm consulting still have architects that lead the way. Also they are in the process of setting up self-service private cloud infrastructure. I see a move in the right direction (private cloud already contains architecture principles), but we can make more steps and I think your idea of having an architecture community will certainly help. I can see that knowledge of devs will also help automate certain principles.

Yes, cloud helps with automating principles, outcomes & standards definitely. Self-service within constraints is the ideal.

For me, working with Continuous Delivery as a principle and working out practices backwards from that has been the key.

“If we’re going to go from concept to cash - idea to production - within 1 hour, without asking permission - how can we do that?”

Great! Thanks for your thoughts!

Thank you so much, much appreciated! Happy to chat about more detail if you ever need.

I have seen a few failed transformation in the past 😉

But we see that targeting all pillars, Automation, Architecture, Processes and Business Agility, together is needed to achieve stable transformation. And it is a long journey, especially on the Networks area, where Vendor and CSP shall collaborate and explore together

The key aspect is alignment

Alignment is key, but you also need to improve on multiple aspects. Culture of trust will not come without a safety net, that helps reducing the impact of any bad decision (so we can actually celebrate failure) Automation, and new technology is very much key as well (as always)

I mean alignment at every level. Align on why and what at every level. As leaders, creating a psychologically safe environment should be one’s top priority if they want to drive innovation and Transformation. The other levers around technology, new ways of working etc. are critical as well..

Aligning and re-aligning that Why and what! Yes. That is a good base to start building on

it could be very daunting for a new person to the team

@richard.herrett yes, this is what I have seen as well. The newcomer was afraid to see this is the style. On the other hand the team itself is delivering excellent results, and trust each-other fully

but a team changes over time - it happens, even with the same people (their private life changes, therefore they change) and what was OK may not be OK in time.

I like to ask "If a stranger to the team observed the team, would they want to join in or not?" if not...

So behavior shall stay within good standards, in whatever circumstances, to keep the team running on long term!

The team should decide their social contract - acceptable behaviours and actions in the team environment. There is no “one size fit all” - the culture plays a big part..

Totally agree!

It seems very important to both call out performative messaging and allow the person/org to learn from their mistakes.

Agreed @michael_winslow I think we can influence that, and we're getting there

Thank you @pnuwayser glad you iked it

Thank you @arnab.nandi 🙂

Thank you @michael_winslow

Thank you @tom521

I agree @tal927. There are already pushbacks from large silicon tech giants so I hope it won't pass.

Thank you @laurafernandezvillar for attenting 🙂

Thank you @ciaran.byrne

You can find them on Github: https://github.com/devopsenterprise/2020-London-Virtual/blob/master/Day%201/Breakouts/Shaaron%20A%20Alvares%20%20-%20Shaaron%20A%20Alvares%20-%20DOES%20London%202020%20-%20INCLUSION%20IN%20TECH.pdf

Thanks!

@fokkov all the references are hyperlinked 🙂 so you will find them in the decks. BTW 🙂 note that Octavius Black And John Skeet are British 🙂

I also loved the team culture agreement - which I can see being a good aid to the "only one" culture. Being an only is easier in an environment that is conscious and supportive. So many good ideas shared in this talk!

@thank you @paula.thrasher I'd love to keep working with anyone interested in developing tactics 🙂

Few years back, in a one nationality/one language team (within a Multi) we decided to hire some foreign speaking person to each team. This helped a lot to push for daily communication in English, and also improved team cohesion as people started to support the "foreigners " with personal manners as well. Relocation was supported by HR, and paid back in team spirit

Yes they should be shared already on GitHub, let me find out 🙂 @shager

These are on Github: https://github.com/devopsenterprise/2020-London-Virtual/blob/master/Day%201/Breakouts/Shaaron%20A%20Alvares%20%20-%20Shaaron%20A%20Alvares%20-%20DOES%20London%202020%20-%20INCLUSION%20IN%20TECH.pdf

Thank you @bahram.bahrambeigy