@nick.kritsky @nicolas.nguyen ^

I need to start shaping in the middle of the talk!

https://devopsenterprise.slack.com/archives/C015FGB49UK/p1602601256175100

Luckily I think it can wait the few minutes until we get to the end.

@ds might ask if you’ve folded any paper yet…

i just did

I have, and we use that as our 1:1 meetings and as we work on projects…

oh amazing @denver.martin, how do you use in 1-1s??

As we talk about daily work and how we are applying to improving our daily work and breaking it down to things we can change…

If we look at our daily work as its own project…

This also helps the team talk better and for myself as a manager be a better manager to be in tune with the move towards common and personal goals.

@ds @jtf Congratulations, you got a 5 star review on Amazon!

Excellent! Thank you for taking the time to post that @ferrix!

This is why cargo-culting doesn’t work.

heh "learning opportunities" - but often people don't want to learn... they just do it harder and wonder wy it keeps hurting!

better put than I did 🙂

but then my ideas won't win! 😉

Earmuffs!

You in particular? Yes. 😉

Thanks! I love this affordance of the remote format.

Definitely, #psychological-safety is needed for a real learning and listening environment - safe to speak and safe to listen up

Practicing these methods builds psychological safety @nickeggleston. We cover this in Chapter 3 on building trust where by trust we mean the ability to predict someone’s behavior because you understand their internal story

How does this defininton of trust relate to what we might call acceptance... by which I mean... the idea that you will continue to respect and engage with me even if you disagree with my current thinking or ideas?

#psychological-safety as a group behavioural norm is about accepting you will all commit to behaving in a certain way. This can include committing to disagreeing in a constructive (but passionate!) way

@nickeggleston: I think our version of trust is accepting that different people have different stories. We use the tool of The Ladder of Inference as a mental model to help with that process. The idea that people have different experiences and therefore different ladders should be a strength because it gives us more information. Accepting that is very useful.

Agree with @ffion. We don’t need to agree, except that we agree to that we’re going to put the shared problem, the shared mission, ahead of our own egos.

“…is about accepting you will all commit to behaving in a certain way.” < in particular I believe that psychological safety is the shared belief that everyone is motivated by good intent, that everyone is trying to solve the shared problem.

When coaching I often say that there’s no reason to believe that two people will come to agreement. However you should be able come to mutual understanding, where you each understand what the other person believes and why they believe it. That’s a powerful shift towards acceptance.

When anything you do is an attempt to find out reality, agreeing on the next experiment is enough.

So I am thinking back to the James Damore issue with Google. Not much psychological safety in evidence there, from the research I did on the issue. Ironic, given that Google is often cited for the work in PS. There's something worth studying in that whole debacle, I think.

Does Google have an explicit behavioral commitment?

by design

most of twitter being most of what gets attention?

I guess it can be both if escalation is not possible.

that’s what you get from high “engagement” algorithms

We read the book, and want others to read the book who want others to read it.. :)

That I’m ok with! 😄

frequent

This! Humility may lead you to give up.

how does this related to basic psychological traits like inroversion vs extroversion

I hope your browser doesn't crash

Same!

the save posts button is required at this conference....

No I mean... do you have some groups you are hosting that we can join to practice?

Yep. Take a look at our events page. The London Organizational Learning meetup has online public sessions twice per month.

If the time doesn’t work for you, let us know on the Agile Conversations Slack and maybe we can organize one in a different timezone

@jtf How long does one dojo typically run in duration? how long should a team set aside for one session?

I think I'll dial in some time. I wonder what I can see through comedian's eyes 😄

@alundgren Apparently @jtf's sessions are two hours.

Thank you, @ferrix!

But I bet you are can also opt in to having a fun two-day Dojo with any team with lots of sweat, tears and a few resignations 😉

@alundgren: most of the sessions we ran in-house at TIM were 1 hr. We ran those initially weekly, then fortnightly, for a few years.

I typically run sessions for people new to the material for two hours.

Thanks very much, @jtf!!

Once people have done it once, and then understand the flow of the 4rs, then 1 hr is enough.

@jtf do you have breaks in those two hour sessions? I find that a necessity for the brain in trainings.

haha don't get me started on masks...

Yep, those are the ones.

https://www.meetup.com/London-Action-Science-Meetup/events/ncpxxrybcnbkc/

I say that "I love golf but the feeling isn't mutual."

Will join in 🙂

We're about 1.5 yrs into this transition.. happy to chat.

^^^ and reviews shouldn't glorify heroship

Yep, we try to focus on behavioral attributes in reviews when possible... don't give a laundry list of everything you did.. you are on a team... how did you work better, differently, smarter. How did you collaborate and innovate more.

this is one of the hardest bubbles to breach, IMHO

hello "on call"

They just have the wrong incentives. Right?

They think they are a separate team

the CAB meets ones a week, as long as you have your request in the week before... you might get something next week... if you filled out all the fields in the spreadsheet.

Life goals! 🙂

💯

Love your headline, Duena! Would love to connect and trade ideas.

She has something cool to demo

@bryan.finster You said something nice about my baby! - virtual pint! @fernando.b.rodriguez. happy to. We make a team solution that seeks to measure and improve Psychological Safety and EQ

I like your product.

You can't lead technology. You mend it, you program it, you manipulate it. Humans you can lead.

Yes!!!! I keep saying "Every release is missing the next feature."

we are a retail company...so our customer is not one I would want my infra team to sit with...there are a few that would argue that the business is our customer, but other that say there is only one customer...

but...I will help them get through the "change curve"....minimizing the anger phase as much as possible....move them quickly to exploring

@mavila907 we have just 'one customer' as well.. our external customer... our internal (business / app dev) teams are our 'consumers'... those are who we have the infra product leaders or value stream engineering leaders sit with

Jealous! In my firm the challenge is more how to liberate infra managers/teams who want to operate along the lines of your model from more constraining top-down direction

At what level and how was it operationalized?

@philipday still?:( was hoping it changed since DOES London

Gone backwards in some respects! 🙂

There are some good things going on at grassroots level - organic horizontal collaboration e.g. from the retro of some outage incident

Oh-oh, don't do a side hustle, we've just been told 🙂

Thank you! Makes sense!

We see it as a common pattern and a great way to enable flexible movement of people and teams to priority work

Definitely some impact, but we had embraced WFH for some time. However, as we were rolling this out we were encouraging teams to pick days to co-locate, which obviously didn’t really happen with the pandemic. Thankfully most of us were accustomed to working remotely so we’ve managed to stay connected and productive.

@hbmartin23 who do the scrum masters report to?

@denee.ferguson our scrum masters report to a chapter lead (for all SM across our infra teams)

I have so many slack accounts I get confused which goes whcih which

That’s a great question. I’d say so far the biggest tool we’re using would be adoption metrics and feedback surveys. Unfortunately with Infrastructure it’s not quite as easy as a customer facing tool where you could do some sort of A/B testing. Hope that answers your question

It does. I will reach out to connect as your insight has been super valuable and really impressed with how Discover has fully embraced the CI/CD ideology. Would love the opportunity to share more about how Split's Feature Delivery Platform does measure the impact of feature releases using A/B testing to reduce the amount of wasted features. I learned a lot and looking forward to learning more from your experiences as it helps me to serve my customers better!

What's the interest rate on those? I think the human one is more expensive. (and they cause each other)

It's greater for sure

Organizational Debt > Technical Debt

Complexity Debt

How much of mess have we gotten ourselves into.

Peter! 🙂

Dave! 🙂

@genek101 made me apply for an actual TM for "Human Debt" 🙈 Not like anyone is falling over backwards talking about paying it off :)

@peter.maddison I see where that complexity is coming from but I find human debt and tech debt more actionable.

"We've got too much things!" is not a call to arms that I'd sign up for

@ferrix They are. I find Complexity Debt resonates as a starting point for some before breaking it down into what is causing that complexity.

Interesting. I find it to be beating around the bush.

"I sense complexity, my dear Watson."

Out of all the approaches to sell a change to upper managements VPs of whatnot, I prefer the "Your people are suffering and the re-employable are leaving. You're going down." as effective. and the "I presume you are dealing with a complex constellation of interlinked problems" to be more like pandering to their excellence in dealing even as poorly as they are.

Yes, it is not easy and that may be related to it going poorly. 😄

Yes, exactly. I don't find describing it as any form of "this is how much you messed up" is helpful.

Language is tricky and words are overloaded with context 🙂

Sure. I've read that Agile, DevOps and Clean Code are dead. Approaches like that who don't acknowledge any previous effort will not win any business. Something has been tried and it has been partially successful since the business is still alive.

"You are screwed" and "You screwed up" are very different but they may be heard all the same.

Yes please?

And how is it meaningfully measured?

Is this similar to your talk in June? (great talk btw)

Similar but we have new case studies!

👍👍

Ooo you might get an executive sponsor out of it...

I believe so, as there is a ask to include the patterns and anti-patterns in our global training material 🙂

The book has plenty of patterns and anti-patterns, @rodriguessemensati.e - this should be a good start 🙂 We are planning to publish some visual guidance patterns and antipatterns in 2021. They will be similar to our original DevOps Topologies patterns from 2013 but obviously use the new Team Topologies thinking and concepts. http://devopstopologies.com/

Thanks for replying @matthew. Yes I am currently using the DevOps Topologies for our training material, as the idea is for our organization to provide guidance on what kind of patterns can be introduced across the company to fit the need of each development organization and their DevOps/Agile Maturity level. Do you already know when in 2021 you will be updating this? I would love to create our material with up to date content, so should I just wait or go on and match the content of the book and the DevOps Topologies site?

The TT book 📗 is much more advanced and up to date than the DOTs website. I never really use the DOTs material now except to say "this is where TT came from" 🙂

The DOTs stuff is a good starting point but I'd recommend to use the TT 📗 material if you can.

We don't have a date for the new patterns yet - we're super, super busy with client work until early 2021 at least, so the new patterns may not be published before the middle of 2021.

got it, thank you so much for taking the time and sharing the information!

It depends... 😉 If the HW is stable and what we need are some platform services to simulate tests/update firmware, etc - then I'd see it more as platform.

But if you're developing a product/system where both HW and SW are evolving, I'd tend to see the embedded SW team as stream-aligned. What you might need in that case is more frequent and clear interactions between those different teams.

More collaboration in particular I think tends to be missing in that scenario.

Because HW + SW dev is hard, we tend to try to isolate them but that only shifts problems to later integration stages. HAving those teams interact more often and share common practices would help imho.

Yeah. I haven't read the book yet, but I think I see it the same way

👍

is the platform team embedded in the other products? or is is a standalone product team?

The platform should be managed as a product, so typically you would have separate teams working on the platform. However, you can also get value from having Enabling teams work across multiple Stream-aligned teams to understand needs and feed back that information into the platform.

Depends how "the product" is defined. At the moment I think splitting this up in a basic product (platform incl. HW and basic Sw) and value stream aligned teams (building applications on top of that) would make sense.

@roman - when you read the book, look at the example on page 123-124 - it's about a manufacturing client we worked with. Related to hardware + firmware + software

When the technologies are very different - different skills, different change cadences, etc - it can be A Bad Thing to choose the wrong thing as the platform. Sometimes, it's actually best to use ongoing collaboration until the correct platform becomes clearer.

When the organisation is smaller it is good to use the TT concepts to plan out what the organisation might look like in the future - thinking about how the organisation could grow

What Richard said 🙂

It may also help to identify where people are wearing "many hats" and working across teams

essentially highlighting their potential cognitive load due to context switching

I have begun to discuss Team Topologies concepts with senior leaders, but they pushed back and said we need people to wear many hats... otherwise we would need to hire more people than we can afford.

Also you can apply some patterns even if you don't necessarily have a dedicated team, for e.g. a thinnest viable platform might be a wiki with useful recommendations to get started.

Or you might have a more experienced stream team working in an enabling fashion for a period of time to help a more junior team, etc.

> When the organisation is smaller it is good to use the TT concepts to plan out what the organisation might look like in the future - thinking about how the organisation could grow Aye, I agree with that.

It could help you identify where you might want to "replace" existing team members in those teams

i.e if one person is highly skilled but utilised across many teams, how can you "skill up" someone on one of their teams eventually allowing the highly skilled person to no longer be required within that team

Enabling teams FTW 😉

> I have begun to discuss Team Topologies concepts with senior leaders, but they pushed back and said we need people to wear many hats... otherwise we would need to hire more people than we can afford. @dmaillet63 - it sounds like the organization wants to do more than is really feasible to do. Is the goal to be working on multiple things simultaneously (but probably taking a long time) or instead to have a fast flow of change that enables organizational agility?

@matthew Great question! It is currently more of an over-commitment to do too much rather than have a fast flow of change.

Yep - so try to get senior management to address the over-commitment. Lots of approaches: • Limit WIP and use queuing theory • Wardley Mapping to stop doing certain things • Trial use of Team Topologies in a small area and see the results • All the above 🙂

@matthew Thank you! That's helpful. I've wanted to ask you my initial question since I started reading the Team Topologies book 2-3 weeks ago.

At PureGym, the senior management initially pushed back with the "what happens when we don't have enough work for a team?"

But at the time they were considering smaller "product" teams

the term stream aligned team allowed us to then discuss how a stream aligned team could own more than one domain as long as there was no more than one "complicated/complex" domain

so the "Acquisition Team" owned became responsible for a variety of products/features that aligned with the acquisition stream

@richard.allen Thank you. It would seem my next step will be to identify the streams and domains, in which the work and delivery can be owned by a team. I am also looking at Enabling and Platform teams, which can pull cognitive load away from the streams teams.

@dmaillet63 take a look at Independent Service Heuristics as a strightforward starting point for finding streams: https://github.com/TeamTopologies/Independent-Service-Heuristics It's not perfect but it's much easier to use than more comprehensive approaches like DDD (but you should look at DD too 🙂 )

cognitive load is fascinating as a factor impacting speed and quality of development and delivery

Indeed, team cognitive load should drive many key decisions around architecture, team composition, and so on. The resulting decisions might be quite different when we have cognitive load as a key concern.

In particular, team cognitive load should be a strong input into architecture and system design.

Hi @txjones - what do you mean by "cyber physical design" in this context?

Ah - just seen thread https://devopsenterprise.slack.com/archives/C015DUDD9C5/p1602622167390500

ah good I was just about to reply here again 🙂

Do you mean internal staffing / allocation or more in terms of hiring?

here's an article where we cover a bit on hiring for individual and team purpose alignment: https://techbeacon.com/devops/why-you-should-hire-devops-enablers-not-experts

I believe as Team Topologies ideas become more prevalent in an org, that necessarily has effects on staffing and hiring approaches

I guess my question was more around if you've seen people outside of tech using these terminology. I like the idea here of creating a language to describe types of teams and how they collaborate.

@me1208 so it'd be interesting to hear if diagraming out an entire org or department ends up having a rebalance of people

an example would be aircraft engine design

it’s a lengthy modeling and simulation exercise before you get to manufacturing

I don't have much experience in that area but perhaps this thread with Roman could provide some ideas: https://devopsenterprise.slack.com/archives/C015DUDD9C5/p1602621665374900

Hardwware is going to add more and deeper technical engineering and science knowledge - electrical, mechanical, fuel flow, exhaust flow, etc. The cognitive load is really large. And the archtiecture may not be as decoupled. But I tihnk the concepts still apply.

yes it would be a great place to experiment on how to team. I tried a small experiment for design of an engine fan in a new material

I think the topolgies are the best we know. But the subsystems will be more coupled. And must evolve together. So we will have all teams on a common cadence and be integrating the system end-to-end as frequently as possible. That's what the aerospace and automotive companies do.

I think the principles from Team Topologies still apply in a manufacturing context. I started my career working for electronics manufacturing companies - MRI brain scanning machines, oil & gas sensors, etc. and I completely see the same kind of "platform" and team cognitive load issues in manufacturing as we see in software. (Obviously, software is more "malleable" but that ends up being a detail, I think)

I found that collapsing boundaries between disciplines and focusing them on the outcomes helped the team own the work in a multi-disciplinary fashion and find ways to distribute cognitive load. The next question was ‘how do we scale this’.

@txjones bingo - I've found that setting up an or a few efficient cross-functional team is straightforward ish. Scaling this is where the tricky challenges of planning, coordinating, funding and hey just effectively talking to each other gets much harder. The team API concept fits very well here, as does an eye on minimizing interdependencies. For manufacturing there's some really neat talks about SpaceX & Nasa collaboration on freeing teams up to iterate faster.

Part of the solution is in a ruthless removal of in-flow dependencies. Basically: don't spend your effort MANAGING dependencies, REMOVE them. This means changes to product/service architecture to enable fast flow of changes. It also means moving beyond the "scaled agile" approaches of regular coordination because (although useful initially) these coordination points are really kinds of monolithic coupling.

For them it's mostly improving development practices, ways of working, better tooling, automation, pipelines, etc.

are they including to define standard stacks of development?

They’re considered platform teams I guess?

I'm not 100% sure, but I believe it's more sharing good practices, tooling, tech stack without a specific intent of "standardizing"

We have more details here: https://teamtopologies.com/industry-examples/team-topologies-at-puregym-responding-better-to-business-needs-with-well-defined-software-teams

We can ask @richard.allen who wrote the case study 😄

The DevEx team focused on the developer experience across the different steam aligned teams, helping them get the CI/CD pipelines etc

And the DevEx team is separate from the Platform, right? A separate identity?

Making sure they were comfortable with Infrastructure as Code concepts etc

The DevEx team have their own goals and responsibilities

which is separate from the platform yes

we also introduced the concept of "chapters" for knowledge sharing for things like "front end development" etc

so those that were in the stream aligned teams that were had an interest in front end dev would join this chapter to help share knowledge - the DevEx team would also be involved in these chapters and help encourage good practice in the other teams

@arthur.maltson > They’re considered platform teams I guess? The 4 fundamental team types help to clarify roles and purpose. So the DevEx team at Puregym is an Enabling team - with a set of behaviors and responsibilities separate from the Platform. This all help to keep teams and systems loosely coupled rather than blurring boundaries that leads to Big Balls of Mud. :shit:

It sounds like they were almost like a developer advocate team

For the internal platform

Wonderfull... I appreciate your help. I was in your session last year, I read the book and this use cases it's awesome

Thanks - it's great to hear!

We see pockets within those large orgs where some ideas are being adopted and we've done initial training for some of them. Team Topologies is a 1-year old baby 🙂 Companies that size take a bit longer to change their ways 😉

We hope in 2021 we will be presenting some industry examples of that scale 🙂

@me1208 is there anything you can share earlier? For example, do Team Topologies fratcal up as we scale? We apply them to organize the teams in a subsystem. And, we organize the subsystems that way too - stream-aligned, complicated subsystem, platform, (enabling may make less sense). Thoughts?

Yep - we explicitly talk about fractal platforms.

And fractal stream-aligned too, right? Within a subsystem, my user is another subsystem. The aircraft is the engine's user, as an example. So some subsystems in the engine are stream-aligned delivering value (power) to the user. While others are supporting - platform and complicated subsystem. Is that the right thinking?

We recommend to use the same principles and patterns at all levels of the IT organization at least, and probably into other areas of the organization too. We have heard of GOV departments using TT ideas for things like in-person citizen services. We've heard of financial services companies using TT ideas to extend out to the legal department - getting the legal group to specify the services they provide as an internal "legal platform".

Oh, that's cool!

I think we have to be careful where we place the fractal boundaries. We need to ensure that Stream-aligned teams have end-to-end responsibility for delivery and operation of user-relevant software. Stream-aligned teams should NOT just deliver to an interim internal user.

See this other thread 🙂 https://devopsenterprise.slack.com/archives/C015DUDD9C5/p1602622324394400

Generally we're talking about architecture that supports different business value streams by effectively decoupling different parts that support different business areas (in the sense of DDD bounded contexts). Without that focus we can get to an architecture where many different business concerns are coupled and it becomes hard to align autonomous teams to different business concerns.

At PureGym, the short-term project approach meant that it was difficult to do long term architectural planning because the projects were never quite long enough to have an impact - focus was always on delivering the project rather than making incremental changes to improve the underlying architecture

Having long-lived teams that were stream aligned gave them a longer team view of what the stream and wider business wanted to achieve

@me1208 I see. I am trying to establish a difference between how "long term architecture" (which we might as well call "tech-first architecture" in the old world) and the idea of creating an architecture that allows team alignment, with a business focus instead. Thanks for the clarification. I just got your book from Amazon and I will be reading it to get full context, but this clarifies what you mean. Thank you

We could then determine how the stream aligned/platform/enabling teams might need to interact (through the interaction modes) in order to achieve the desired architecture

Thanks, @richard.allen It seems that you let that long term architecture emerge from the interactions of the teams, and this is what I was looking for. As I see it, for as long as we align our architectural choices to enable iterative feedback from the teams involved, the next cycle of architecture will emerge from that knowledge. Congratulations on pursuing this. Many times this is easier said than done 🙂

In essence, I think we're looking at reverse Conway's Law here. Identify the business supporting architecture based on your business value streams, align teams to the latter, and then set up the team interactions that will allow decoupling the existing architecture (because there's always an architecture already in place).

That's a great way to look at it indeed. We def want to balance the load by having teams with different focus.

But to some extent also reducing cognitive load by upskilling the teams (via enabling teams for example but could be other techniques like training, pairing with senior staff, etc)

How do you measure and visualize the landscape of CogLoad?

as yes that makes sense re: reducing @me1208

We have an early tool here but the field of team cognitive load is quite new... https://github.com/TeamTopologies/Team-Cognitive-Load-Assessment

was just thinking the same

funny how even in virtual conferences sessions can still run over 🙂

I promise not to keep talking on the screen after my video is done 🙂

at an in person event, this would be the time where people are getting up and walking out to get to their next session

😆

I see an opportunity for a product to slightly adjust the speed of the video to fit a 40 minute presentation into a 30 minute session

You tube already has that

why does everyone sound like chipmunks though?

@joel.boekankamp maybe you're just craving for airline peanuts.

I keep giving the conference team feedback that they should leave 10-15 minutes between sessions to handle over-runs and Q&A transitions... anyone who agrees, I'd recommend separate messages to amplify the message. They could try it on day 2-3 and see how it goes... iterate and get fast feedback...

@ferrix we dont serve peanuts at Allegiant 🙂

Even if you have the cravings...

One of the most overloaded terms in IT 😉

YES! ATX!

I think people in our industry, including me, feel like failures if they don't know everything. It's hard to admit you don't. This then pressures everyone else to behave the same way. Is that unique to software development?

Amen to that Bryan. Just today I was working with a team and they really struggled to admit any sort of gaps in their knowledge or needing help from other teams. "We'll learn by ourselves, not a problem". Which is correct, the problem is not the learning, is the time available to learn 🙂

The other classic is of course "we just need better tools"

It also helps when teams ask for help developing a learning path. Everyone seems to want to start from zero and do all the exploration of WHAT to learn and which resources are good resources.

And we have cognitive load everywhere. The structure of companies is not evident, the dependencies between systems are not evident...

When we pride ourselves with slicing models easily, the number of easyish models is something we ignore. So the cognitive load of knowing what all of your dependent and depended teams do becomes a huge cognitive load. And then you are supposed to context switch between that and your software.

💯

That's why this requires engineering.

There are three kinds of leadership: personality, excel and structure. This is a failure in structure and possibly caused by being "cool" or making it look pleasant in a worksheet.

(having a leveled tripod of the three is generally what would be a balanced approach to leadership)

Thinking about cognitive load in terms of groups or teams is quite new. The originator of "cognitive load" - John Sweller - has only recently (2018) published a paper looking at group cognitive load (as opposed to individual cognitive load). It's a new "hot topic" 🌶️ 🙂

Granted. It's just silly how "complexity makes you tired" is a general fact that gets applied to new domains one at a time where you could almost consider it a first principle 😄

Or "If it is hard to grasp, large populations won't"

Yes. Yes it was.

Across many releases/branches

And features cherry-picked forward/backwards...

was that the 4th wall?

I used to LOVE reading the BOFH

I learned about BOFH thanks to @ds while we were working on Agile Conversations

@justin.heimburger we all did. The "excuse cards" were very tempting to use in the daily job.

It was so cathartic to read about someone fictional doing things that seemed totally reasonable, but also career-limiting....

Famous in the 90's!

showing my age!

https://devopsenterprise.slack.com/archives/C015FGB49UK/p1602601261175200

https://twitter.com/JoeBlubaugh/status/1311420399171719169

Oohhh, yeah, I saw that thread. Cringeworthy.

ok… wait… things? 😆

Ha ha, fair

Brian Eno got a mention in an earlier talk. Maybe he could put something together...

Perfect!

I think @jeff.keyes could probably do vocals with his dueling pianos like microphone from his earlier talk

this Eurovision song could be used: https://www.youtube.com/watch?v=1S4drHAd8dA

Hey.... that reminds me.... we had karaoke HH at London-Virtual.