5 ms·

Reducing Cognitive Load in Agile DevOps Teams Using Team Topologies

57 points by kiyanwang 4y ago

c0l0 4y ago
I find it exceedingly hard to tell whether headlines like these lead to articles that are in fact satirical, or not...
- gilleain 4y ago
  The use of the word 'Topology' is especially ... odd. To me, at least. I understand that it is possible to use technical terms like this in a more casual sense. Somehow it makes me think it is an attempt to use adopt 'serious gloss' of another field.
  - an9n 4y ago
    I've noticed people starting to use the term 'socialise' when they mean 'to share': 'And then we'll socialise these information products with stakeholders' instead of 'I'll email some documents to the managers'. Because they think it sounds cleverer heh
    - gav 4y ago
      This isn't a new phenomenon, 70-years ago people thought serviette was posher than napkin: https://en.wikipedia.org/wiki/U_and_non-U_English https://en.wikipedia.org/wiki/U_and_non-U_English
  - asplake 4y ago
    If "organisation" was mainly about the relationships between things, that word would do. Unfortunately, it tends instead to refer to formal structure so another one is needed. The article's introduction to Team Topologies is very dense and I'm not sure that it does it justice. The book is actually quite approachable – I've listened to the audiobook twice now.
- thedougd 4y ago
  The headline certainly increased my cognitive load.
  - akhmatova 4y ago
    That exactly my take as well. It was like, this has to be parody.
faeriechangling 4y ago
The sheer density of jargon and management buzzwords, none of which points to any actual argument validated by a shred of empirical evidence, is mind numbing.
sirwhinesalot 4y ago
Keep your teams to max 10 people (counting the PO). Allow them to self-organize. Treat each other internal team's project the same way you'd treat an untrusted open source dependency. Ignore the article above. Thank me later.
- Cthulhu_ 4y ago
  How would you coordinate work across teams?
  - sirwhinesalot 4y ago
    The same way you "coordinate" work across your open source dependencies, you post an issue in their issue tracker. As far as those other teams are concerned, you are their customer, and they need to prioritize their work as usual. If a team is consistently ignoring the issues posted by another and causing issues in the overall project, that's up to higher management to resolve and reprioritize things. Higher-management needs to collaborate and prioritize issues across teams, as their "own" team, since they should have a higher level overview of the project. To make it a bit more concrete, lets say you have 10 teams of 10 people, each managed by a manager. Each of those teams is an independent "project". The 10 managers themselves form a team that has to ensure those independent projects form a coherent whole by organizing amongst themselves and prioritizing tasks across teams accordingly. EDIT: this split can work (albeit poorly) at up to 3 levels deep, so ~1000 employees total on a "big project". If you can't make do with that many, you're screwing up somewhere, but 100 should be enough IMO.
    - djKianoosh 4y ago
      in an organization that large, the 10 managers in your scenario would have to be some of the most selfless and honest humans, all able to communicate freely and openly without envy or ulterior motives.
      - sirwhinesalot 4y ago
        In most companies those 10 managers are not a team, unfortunately. It's more like there's a "top" manager who has 10 separate sub managers of 10 teams. But those sub managers are mostly independent. At least that's how it is in most places, communication between middle managers goes up and down, not sideways. What I'm talking about is different, it's not just 10 managers that "have to talk", it's 10 managers in the same team with the same goal. They just happen to each coordinate another 10 person team. I haven't really seen that done anywhere, but I've seen some chair shuffling that approximated it. Would love to see it taken to the logical conclusion.
troelsSteegin 4y ago
The underlying "team topologies" idea [0] as I interpret it: Any work function evaluates to return a work product; one team's work product is another team's input to its function; the work plan for the organization looks like a distributed evaluation graph; design teams to minimize blocks on over all system throughput by factoring them into one of four functional patterns. If only value was immutable... [0] https://teamtopologies.com/key-concepts https://teamtopologies.com/key-concepts
GiorgioG 4y ago
Stop using complex systems designed to solve problems you don’t and won’t have.
deleted 4y ago
[deleted]
goodpoint 4y ago
DevOps is now a parody of itself. "Automate Ops and make sysadmins redundant"... by increasing complexity 10 times. Now you have to hire a whole team of highly paid "cloud engineers" that spend hours at writing YAML files.
- 100011_100001 4y ago
  As a person that works in DevOps (but doesn't write YAML files all day), the problem is using the wrong solution for the scope. I think DevOps groups a lot of times end up doing the work that the groups they support should have done for themselves. However, the working yourself out of a job is a very real thing. This is happening with DB Admins and QA primarily. Cloud technologies is displacing the rest. If your company has 1 dev, 1 sys admin, 1 DB admin and 1 QA person, creating a DevOps team won't produce more efficiency, it will have the opposite effect. On the 10x complexity comment, if DevOps is done correctly it's invisible to the user. In practice any decision made automatically has drawbacks. On the flip side, a lot of developers are unaware how things work or lack consistency that automation can put in place.
jjtheblunt 4y ago
Not using Agile reduces cognitive load perhaps too. When i've seen agile in use, it's because incapable managers lack the insight or trust to let teams surface valuable work through emergent properties of what they're working on, so they, in politburo fashion, try controlling things, which just lessens the attention spent on work.
denhaus 4y ago
This has to be a joke. The sheer buzzword/BS density is just too high for this article to be real.

57 points by kiyanwang 4y ago

c0l0 4y ago

I find it exceedingly hard to tell whether headlines like these lead to articles that are in fact satirical, or not...

gilleain 4y ago
The use of the word 'Topology' is especially ... odd. To me, at least. I understand that it is possible to use technical terms like this in a more casual sense. Somehow it makes me think it is an attempt to use adopt 'serious gloss' of another field.
- an9n 4y ago
  I've noticed people starting to use the term 'socialise' when they mean 'to share': 'And then we'll socialise these information products with stakeholders' instead of 'I'll email some documents to the managers'. Because they think it sounds cleverer heh
  - gav 4y ago
    This isn't a new phenomenon, 70-years ago people thought serviette was posher than napkin: https://en.wikipedia.org/wiki/U_and_non-U_English https://en.wikipedia.org/wiki/U_and_non-U_English
- asplake 4y ago
  If "organisation" was mainly about the relationships between things, that word would do. Unfortunately, it tends instead to refer to formal structure so another one is needed. The article's introduction to Team Topologies is very dense and I'm not sure that it does it justice. The book is actually quite approachable – I've listened to the audiobook twice now.
thedougd 4y ago
The headline certainly increased my cognitive load.
- akhmatova 4y ago
  That exactly my take as well. It was like, this has to be parody.

faeriechangling 4y ago

The sheer density of jargon and management buzzwords, none of which points to any actual argument validated by a shred of empirical evidence, is mind numbing.

sirwhinesalot 4y ago

Keep your teams to max 10 people (counting the PO). Allow them to self-organize. Treat each other internal team's project the same way you'd treat an untrusted open source dependency. Ignore the article above. Thank me later.

Cthulhu_ 4y ago
How would you coordinate work across teams?
- sirwhinesalot 4y ago
  The same way you "coordinate" work across your open source dependencies, you post an issue in their issue tracker. As far as those other teams are concerned, you are their customer, and they need to prioritize their work as usual. If a team is consistently ignoring the issues posted by another and causing issues in the overall project, that's up to higher management to resolve and reprioritize things. Higher-management needs to collaborate and prioritize issues across teams, as their "own" team, since they should have a higher level overview of the project. To make it a bit more concrete, lets say you have 10 teams of 10 people, each managed by a manager. Each of those teams is an independent "project". The 10 managers themselves form a team that has to ensure those independent projects form a coherent whole by organizing amongst themselves and prioritizing tasks across teams accordingly. EDIT: this split can work (albeit poorly) at up to 3 levels deep, so ~1000 employees total on a "big project". If you can't make do with that many, you're screwing up somewhere, but 100 should be enough IMO.
  - djKianoosh 4y ago
    in an organization that large, the 10 managers in your scenario would have to be some of the most selfless and honest humans, all able to communicate freely and openly without envy or ulterior motives.
    - sirwhinesalot 4y ago
      In most companies those 10 managers are not a team, unfortunately. It's more like there's a "top" manager who has 10 separate sub managers of 10 teams. But those sub managers are mostly independent. At least that's how it is in most places, communication between middle managers goes up and down, not sideways. What I'm talking about is different, it's not just 10 managers that "have to talk", it's 10 managers in the same team with the same goal. They just happen to each coordinate another 10 person team. I haven't really seen that done anywhere, but I've seen some chair shuffling that approximated it. Would love to see it taken to the logical conclusion.

troelsSteegin 4y ago

The underlying "team topologies" idea [0] as I interpret it: Any work function evaluates to return a work product; one team's work product is another team's input to its function; the work plan for the organization looks like a distributed evaluation graph; design teams to minimize blocks on over all system throughput by factoring them into one of four functional patterns. If only value was immutable... [0] https://teamtopologies.com/key-concepts https://teamtopologies.com/key-concepts

GiorgioG 4y ago

Stop using complex systems designed to solve problems you don’t and won’t have.

deleted 4y ago

[deleted]

goodpoint 4y ago

DevOps is now a parody of itself. "Automate Ops and make sysadmins redundant"... by increasing complexity 10 times. Now you have to hire a whole team of highly paid "cloud engineers" that spend hours at writing YAML files.

100011_100001 4y ago
As a person that works in DevOps (but doesn't write YAML files all day), the problem is using the wrong solution for the scope. I think DevOps groups a lot of times end up doing the work that the groups they support should have done for themselves. However, the working yourself out of a job is a very real thing. This is happening with DB Admins and QA primarily. Cloud technologies is displacing the rest. If your company has 1 dev, 1 sys admin, 1 DB admin and 1 QA person, creating a DevOps team won't produce more efficiency, it will have the opposite effect. On the 10x complexity comment, if DevOps is done correctly it's invisible to the user. In practice any decision made automatically has drawbacks. On the flip side, a lot of developers are unaware how things work or lack consistency that automation can put in place.

jjtheblunt 4y ago

Not using Agile reduces cognitive load perhaps too. When i've seen agile in use, it's because incapable managers lack the insight or trust to let teams surface valuable work through emergent properties of what they're working on, so they, in politburo fashion, try controlling things, which just lessens the attention spent on work.

denhaus 4y ago

This has to be a joke. The sheer buzzword/BS density is just too high for this article to be real.