Cognitive scientists tell us that we are more productive and happier when our behavior matches our brain’s hardwiring—when what we do and why we do it matches the way we have evolved to survive over tens of thousands of years. One problematic behavior humans have is that we are hardwired to instantly decide who we trust. We generally aren't aware of these decisions—it just happens. Linda explains that this hardwired “trust evaluation” can get in the way of working well with others. Pairing, the daily stand-up, and close communication with the customer and others outside the team go a long way to overcome our instant evaluation of others. As Linda helps you gain a better understanding of this mechanism in your behavior and what agile processes can do to help, you are more likely to build better interpersonal relationships and create successful products.

Q&A

Question: Was the clogged water pipe so effective because it was a common threat to both groups equally? in the sense that “my enemy’s enemy is my friend”?

Answer: The clogged water pipe was not a common enemy. In fact, the idea that we would be united against a common enemy is proving to be false. Witness the current pandemic. It is a common enemy but it has not united us. Sad but true.

Question: how important is the language used when trying to reduce dividing lines between groups? "us" and "ours" vs "them" and "theirs", is the language important, or a trivial factor?

Answer: Words matter. Language is important. That's why females make such a big deal about the use of "mankind" :)

Question: Are “agile” workplaces really “better” environments in this regard? isn’t the whole agilist industry reliant on maintaining the “us vs them”/“business vs tech” divide in order to justify continued investment in specialist roles and career paths (scrum master, release train engineer, agile coach, trainers, book authors, conference speakers etc)?

Answer: I guess I mean "agile" in the best sense of the word. I'm an idealist. I also know that agile has been translated to a lot of settings that are definitely not agile.

Question: Thank you for your talk, Linda. I would like to know your views on possibility of using “us” vs “them” positively for healthy competition, without making it “us”.

Answer: It's really hard to have "healthy" competition. I can recall several retrospectives where I was called in to facilitate a contentious meeting about t-shirts! "They" got t-shirts and we didn't even though we worked just as hard as they did! T-shirts? Yep. T-shirts. I think you have to be careful with team identities, language, and symbols.

Question: I am not sure if this is worldwide or just in Australia but pairing is not as common as (I reckon) it should be - what do you think is the impact of dropping this practice on trust levels in "Agile" (Scrummy) workplaces?

Answer: As I said, I think pairing is the least appreciated but most powerful of the agile practices. It has been around for decades, so it's not new. It has measurable benefit and even though there is evidence (as opposed to many agile practices) of its effectiveness, it's not widely used. Sad :(

Question: "catch them doing something right" is a well used phrase in teaching as well. Linda, how much crossover did you find between teaching at a university and working in the business world in terms of peopleware?

Answer: My university teaching was at a university that worked closely with industry, so there was a lot of overlap. In many academic environments, this is not the case. I was lucky.

Question: Interesting that all the studies were on “boys”… Linda were there experiments that were girls or a mix of genders?

Answer: Sorry about only using experiments on young boys. I always get that comment ! The experiments have been done in several cultures with different genders and ages. I think I like these two because they are similar but so different.

Question: In all I do I’m learning more and more that, generally speaking, we are emotional creatures much more than cognitive ones. Do we need to reacher higher for cognition rather than settle in with emotions?

Answer: We are not primarily rational creatures. Read "Thinking Fast and Slow" -- or just search for my talk on YouTube. Daniel Kahneman won the Nobel prize for his work in behavioral economics that illustrates how flawed our decision making is. This doesn't mean we are never rational -- it's just that the driver (System 1) is in control.

The evidence suggests that we need that emotional component to make any decision. Studies of brain damaged people without areas in their brains that are tied to emotion cannot make even simple decisions. System 2 is good at laying out the logic but System 1 is in charge. And that, for the most part, works well. Every now and then System 2 has to override a System 1 decision. I really wish we could meet face to face. I never feel I'm doing a good job of anything by typing! Thanks again. Be well and stay safe!

Question: Have you ever encountered (or heard of) a situation where all the tools you could bring to bear, could not get the team to "unlearn" these habits of mind?

Answer: Oh yes. When I worked on the 777 airplane -- I was supposed to be the resident Ada guru and I struggled mightily to get people to move from FORTAN and Pascal. Of course, that was long before Fearless Change. I wish I had known more when I was younger -- a common regret among older folks :(.

Question: what advice would now-Linda give to past-Linda?

Answer: The biggest piece of advice is to don't rush in and tell people stuff -- take time to listen and don't believe that because they seem to be resistant that they are stupid. I have made that mistake so many times and I'm making it now in my community watching the political signs go up in my neighbor's yards.

Question: Not entirely related to the talk... but I'm interested on your thoughts about the tech environment these days for women and whether you think it's changed much since you started. Seems like there's still a lot of cases of "I'm the only woman on the team, and..."

Answer: The world is so much better for women -- not just in the tech environment. Soooooo much better! In my first job interview (1963) I was asked what kind of birth control I was using and what plans my husband had (he was then a sophomore medical student) after graduation. That would not happen today. We don't want the world to swing too far in the other direction. One of the worst teams I worked with recently was all women. Not good.

(Balance & Diversity lead to better outcomes.) That's what the evidence shows. Diversity -- people with different genders, races, educational background, experience, and, yes, political persuasions.

I hear many "agile organizations" say they are hiring for "culture fit" -- which I think is code for "just like us" -- when that should never be the goal. Unfortunately, we like people who are like us and believe that's the best way to work. Lots of evidence shows that homogeneous teams are not as innovative, creative, productive, or efficient!

Question: Sometimes those same companies hire for “diversity”. Can you have both at the same time?

Answer: That's good. Sometimes they do say that, but they mean, something like a little bit of strawberry with the vanilla, not a radical Moose Tracks :) . And, really, this is hardwired. We spent thousands of years in small groups (no more than 150) of people we had known all our lives. We feel comfortable with that. These nice people we know well. Not too upsetting.

I hate it when my husband calls out some biased statement and says, "See, you do it, too!"! :). That's Kahneman's biggest argument for diversity. We can't see our own biases, but teams of diverse individuals have some hope of overcoming at least some of those distorted viewpoints.

How can we apply technology to drive business value? For years, we've been told that the performance of software delivery teams doesn't matter―that it can't provide a competitive advantage to our companies. Through six years of groundbreaking research, the DORA team set out to find a way to measure software delivery performance―and what drives it―using rigorous statistical methods. This talk presents the findings of that research, including how to measure the performance of software teams, what capabilities organizations should invest in to drive higher performance, and how software leaders can apply these findings in their own organizations.

Q&A

Link:

http://bit.ly/dora-bfd

https://cloud.google.com/solutions/devops/devops-culture-westrum-organizational-culture

bit.ly/hsbc-devops

Question: I’ve found it really hard with most of the technologies we use (Java/Typescript) to have (and maintain) a set of tests that are fast enough to run on every commit. Do you have any tips?

Answer: I recommend checking out this blog post from my former TW colleague Dan Bodart: http://dan.bodar.com/2012/02/28/crazy-fast-build-times-or-when-10-seconds-starts-to-make-you-nervous/

He did a talk too: https://www.youtube.com/watch?v=nRDlYvIbSBU

Question: For Lead Time -> do you consider time to get to a dev team? i.e time from conception of an idea to production? or just from commit to production?

Answer: Just commit to production. The "fuzzy front end" is a fundamentally different domain (product development) where high variability is a good thing. The delivery domain is supposed to be low variability.

Question: Have you captured “age” as part of your “firmographics”? Age is often sometimes equated to maturity but does it correlate with organizational performance in any way?

Answer: You mean age of the organization? No, we haven't looked at that. I have doubts as to its reliability as a measure because so much of performance is team level, and the "age" of a team is super fuzzy - how do you control for the impact of re-orgs, people leaving and joining, changes in management etc. Determining if there is any evidence that organizations get better or worse over time (when corrected for other factors) would require a longitudinal study, which is a good idea, but we don't do that.

Question: How well do you think your “secrets” could be applied to government? Do you think it could improve the management of pandemics?

Answer: We actually got a nice message from a team in the NIAID saying the changes they'd made as a result of the assessment we did there had helped them move more quickly when COVID hit. So yes, I think it can. And my personal experience working on the cloud.gov team is that these ideas definitely work in government. (Also, we find in our analysis that the results apply equally well for respondents who say they are in government).

Question: Will there be a DORA State of DevOps Survey and Report in 2020?

Answer: We have some things in the works but there's nothing I can talk about at the moment. Nicole is now at GitHub, and she released something related to your question back in May: https://github.blog/2020-05-06-octoverse-spotlight-an-analysis-of-developer-productivity-work-cadence-and-collaboration-in-the-early-days-of-covid-19/

Question: Is it possible to have highly aligned, loosely coupled teams working on the same delivery? Is scaled agile advisable? Does it come down to how you slice up the work so you aren't stepping on each other's toes?

Answer: It really depends what you mean on "same delivery". If you mean, working towards the same outcome: yes, and Scaled Agile isn't necessary. If things are tightly coupled that is going to be harder, and scaled agile can help as a countermeasure, but ultimately it can only get you so far: you really have to invest in decoupling organizational structure (small, cross-functional, autonomous teams) and enterprise architecture (making sure you can independently test and release your services - in other words, having a true service-oriented architecture)

Question: Is chaos engineering a core part of google cloud too? Just had that question when you shared about the DiRt remarks.

Answer: With the methodology we use to do the research, we can only really look at practices that are reasonably widely adopted. Chaos engineering is still very emergent. It's definitely very closely related philosophically though. Oh sorry, you're asking about whether we do chaos engineering of the Netflix flavor at Google in particular - I am still very new to SRE so I don't actually know the answer to that, sorry.

Question: Asking for a friend: organisational transformation through building communities and seeding PoCs takes time for the gnarliest of problems. It doesn't look like anything's happening, whereas a rolling out of Best Practices from a Centre of Excellence looks and sounds like Great Strides are being taken. Even if the grassroots efforts are regularly communicating progress and success, if the problem is hard enough that it takes effort to understand the subtleties, then most decision makers in the organisation - who are busy with other things because of the trying-to-do-it-all-at-once problem - will buy into the easy, just-do-what-the-Centre-of Excellence-tells-you-to-do option. Any advice on the most effective lever to attempt to pull here? Get the communities of practice shouting louder, tell the CoE to learn patience, or (somehow) reduce WIP across the org?

Answer: (Nick) Make the work visible. Then people can discuss the work in the CoP's and you get real synergy. CoE's are pretty much useless IMHO (see DORA metrics 2019). But you have to be careful not to let management co-opt the process.

My favourite Deming quote is "when a measure becomes a target then it stops being a measure". So, for example, if you make the number of passing/failing tests visible at each level, some bright spark will put a 90% coverage target on it or something. Every team will then hit 90%, no matter what it takes, rendering the measure useless.

(Jez) Targets of this kind can work provided they are set by the team. What leads to the behavior you describe - and which I have certainly seen - is targets set from above.

(Nick) Also on reducing WIP, I'd say the same - make the work visible. Often it isn't visible so if you make it visible the burden becomes obvious and people start to talk about it. One way you can provoke this is to make batches smaller (which leads to faster cadence). In big batches it's easier to hide the WIP and the overhead it produces (aka Don Reinertsen "Flow"). It will also expose bottlenecks where the WIP piles up. In Lean they call this "lowering the water level to see the rocks".

(Jez) In addition to what Nick said, I think there's also a cultural change that needs to happen. Managers and execs need to see their role less as making stuff happen, but rather as creating a culture where the people doing the work can get stuff done, removing obstacles, helping people acquire the necessary skills to succeed, increasing alignment and transparency.

One way I've seen to demonstrate progress is for management and execs to invest in community events, like an internal devopsdays where everybody gets a day off and - crucially - the people doing the work get to set the agenda, including an open spaces where anyone can talk about what they've been doing.

Databases are everywhere, but did you ever wonder what goes on inside the box? In this talk we’ll dive into the internals of Neo4j - a popular graph database - and see how its designers deal with distributed systems challenges now and in the future. Borrowing heavily from the academic literature, we'll see why computers are far too easy to program and why oppositely distributed systems are far too hard. We'll follow that with some approaches to making distributed systems safer and contrast that with conflicting approaches that make systems more scalable! If that doesn't sound nightmarish enough, we'll finish up by showing how we can build systems that are safe and scalable by borrowing and gluing together a bunch of ideas from folks who are smarter than me. Come experience the last 10 years of my harrowing day job in less than an hour. You might even enjoy it, or at least empathise!

Q&A

Question: How critical is clock sync?

Answer: Clock sync is not important for these classes of algorithms. If we had accurate distributed clocks (and they're coming) then we can make many simplifying assumptions about ordering and perhaps use simpler algorithms where coordination is reserved for worst-case scenarios (see: Google Spanner)

I understand hardware manufacturers are soon able to create accurate GPS clocks nowadays on commodity servers. That was Google-level science fiction until recently.

Question: Awesome progress over the last few years - “amazing and terrible” - tell us the terrible bits?

Answer: Distributed algorithms are really sneaky. You think you designed one that works, but then there's some really, really subtle thing that means in reality the whole thing is unsafe.

Repeat that numerous times.

Of course now we think we have several that work, but that nagging doubt that you've missed something never leaves.

Question: how do you go about testing these?

Answer: We use proofs, which is OK. We'd like to move to using automated model checkers (e.g. TLA+) but we find the effort of doing that is about as high as building the software itself. Perhaps that's because we're unskilled at formal methods?

Question: Has this been used in any real-world application?

Answer: Yeah, the Linear Transactions protocol has been used in a KV store. But the mixture of LT and Raft I think is novel.

One other terrible thing is communicating with management around deadlines. It's hard to explain why getting two computers to agree is so hard and takes so long! honestly it does sound easy to get to computers to agree on a number, right?

Question: Do you think these Spanner-type databases will soon become a more mainstream choice because you no longer need to trade off consistency for scalability and availability?

Answer: I think for cloud providers, yes. They have the hardware, while there definitely are trade-offs, ownership of the full stack means you can actively manage those trade offs.

Question: now we can only hope that Spanner becomes more economical for smaller use cases. but there are other hosted options like Yugabyte and Cockroach.

Answer: Yeah, those are interesting. Cockroach in particular has a novel transactional setup (raft again) that obviates the need for clocks, but trades off Spanner performance in the edge cases.

Question: I love all this stuff... I'm crazy enough for my mind to idly contemplate coordination challenges while going through the motions of life but I'll never be smart enough to contribute to the field. Thank you very much Jim.

Answer: You have the smarts - it's no different from single computer programming in a way, you have to wallow in the field, spend time being petrified, and then take tentative steps into building terrible algorithms. Over time, you get a bit better.

Question: Are the Raft capabilities available via projects like SpringData-Neo4j, or only when working directly with the drivers?

Answer: They're built into the database servers, so however you access the database, this infrastructure is activated (unless you explicitly use a single server). The causal clustering protocol is handled by drivers as you hint, but those drivers are used by the Spring Data, so you're all good.

Question: General graph DB question (for someone who hasn't used them in anger) - have you ever had a situation where you thought - hmmm I can't do this in a graph DB I need to switch back to a common-or-garden-variety DB?

Answer: yeah, graphs are pretty general purpose, but I wouldn't use one for bulk storage, blob storage, etc because there aren't relationships in those kinds of data to be exploited.

Looking back at the times I used RDBMS when I worked for ThoughtWorks (hi, folks) it seems to me that most of those times a graph would have been a more humane and performant tool to use, if only they'd been around.

Question: I guess then conversely: what are the signs to look out for that would let you know that you should be considering a graphDB? like the London Underground example perhaps obviously looks like something with nodes but maybe ppl just don't know when or how to change their view of a problem?

Answer: E.g. If you have a RDB which is join heavy, that's probably a graph.

We call this the "graph problem problem" at Neo4j, and we're trying to solve it through education. E.g. there's a new, free "For Dummies" book out on graph dbs that you can get from the Neo4j web site.

Question:I think the consensus algorithms you went through were general case … Is there any scope for consensus algorithms tailored to specific contexts to achieve better X,Y,Z? Don’t know if I have a specific example.

Answer: I don't know of any off-hand, I suspect you might be able to take advantage of knowing the number of parties to coordinate, or timeliness (e.g. coming from compliance) etc to simplify/streamline the protocol.

Question: I work on the client side of distributed simulation but have thought about what distributed systems concepts go into the simulation algorithm. Consensus around time is important, as is some knowledge about how many messages each connected simulation application has sent.

Answer: Oh very cool. I've never done any distributed simulations, but did some work over the last few years simulating what goes wrong when your consensus (actually your consistency model) is weak. Spoiler: it turns to poop.

In that setup, we used an (expensive) simulation to calibrate a (cheap) numerical approximation for figuring out how quickly your data would rot. Quite useful.