Putting the XP in Scrum • Roy Osherove • GOTO 2021

[@PaulSebastianM]

Splendid down to earth explanation of what continuous delivery is. Like you would explain it to a stakeholder.

[@anitsh]

Insightful and a very useful presentation which points towards the current deeper problems which many engineering teams are not fully addressing.

[@GG-uz8us]

Always learn a lot from Roy’s talk. Thank you. It is indeed very said. All the companies I have worked, none of them really have solid automate tests, not even mention TDD. I feel like lots of them do not even care. And people become hero by fixing the mistakes they make themselves by not practicing TDD, or having automate tests. I think solid automate tests is the foundation of CICD, and agile.

[@illyam689]

Unfortunately, this is just how things go in software development. As a professional, I put in tons of effort to get better, but the reality is, I hardly ever get to use what I've learned because the mess is so deep. And to top it off, I feel like I'm fighting these battles all alone, with no one else really giving a damn.

[@illyam689]

"And people become hero by fixing the mistakes they make themselves"

[@psingh007]

Nicely put. Thank you very much! I really like the stages of leadership and the mention about the value stream mapping and how can it help identify the true bottlenecks and help orgs leverage them and courage

[@vitaliykonokrad4566]

thanks for the talk 👍

[@BenHall-g4l]

Love this talk! Anyone got another over recommendations for good Roy videos?

[@HumanoidTyphoon91]

9:43 it has a huge... pyra... business that enables coaches to be certified hahaha

[@caketubs]

He nearly called Scrum training a pyramid scheme. Ha!

[@おす-qz7kp]

It is not a matter of a process, it is a matter of people

[@RU-qv3jl]

I’m only part way through this talk, so with that in mind, why use scrum? XP has values, principles and practices. It has iterations, retrospectives and dailies, it tells you to work closely with your customers, etc. What is the benefit of scrum? XP does not need scrum at all. Just ditch scrum and use XP. It’s a lot easier and you don’t pay into the certification pyramid scheme.

[@forallofme4441]

The issue with presentations like this is that the presenter starts with an assumption (TDD IS good, pipelines CAN be automatically tested to be green to go), and then prods the rest of us to do it. Perhaps stop to consider that the idea of automated testing may be terrifically attractive to the geeky mind but it does NOT work in practice. I cannot think of a single real life bug recently that automated testing would have caught. Testing is an area we need to solve and pretending that we've already solved it is a major roadblock to successful delivery.

[@andreimorozov317]

> I cannot think of a single real life bug recently that automated testing would have caught TDD is more than this. But if you don't see a reason for it you probably haven't ran into a project big enough to merit that or you're code is hardly refactored which again is bad overtime. Does every project need these practices. Probably not, but the fact you cant think of a single real life bug simply means you're either testing incorrectly or simply your code doesn't change.

[@forallofme4441]

@@andreimorozov317 This is exactly the kind of blind-faith thinking that I'm talking about. I am working on pretty large systems with a medium sized team and delivering value to thousands of users but yeah - maybe there's some magical testing I've missed out on.

[@askingalexandriaaa]

@@forallofme4441 thousands is incredibly small

[@forallofme4441]

@@askingalexandriaaa How is that relevant?

[@gruttewibe76]

There will always be challenges in testing, manually or automatically, so in some way, indeed the testing problem isn't solved. We have to keep thinking. But you don't want humans to be repeating the same tests over and over every time the same code gets touched. That's what test automation is for. To automate away the boring parts. I have seen such tests catch bugs in practice, but fixing a failing test becomes such a routine thing that we don't keep count. There will still be need for a human QA for exploratory testing, updating the automated tests for the new features, collaborating with product owners and developers to get a shared understanding of what needs to be developed and what needs to be tested where and how, etc. TDD is both about driving the design of the code (designing it to be testable) and building a safety net for developers to freely refactor. But any test automation, on any level, needs serious engineering or it will go bad. For example unit tests which are written after the fact, using complicated mocks even for the internal collaborators, providing no confidence, and cementing the internal design instead of supporting us to safely refactor. Or flaky, slow and unmaintainable end-to-end tests because QAs and developers didn't collaborate on them.