Putting the XP in Scrum • Roy Osherove • GOTO 2021

This presentation was recorded at a GOTO Night 2021. #GOTOcon #GOTOnight
gotopia.tech/meetups • osherove.com
Roy Osherove - Author of "The Art of Unit Testing" & "Elastic Leadership" and Independent Consultant & Trainer ‪@osherove‬
ABSTRACT
XP Engineering Practices such as Continuous Integration, User Stories, Pair Programming and Test Driven Development can mean the difference between saying that you're agile and actually being able to be competitive in the market and maintain high quality and confidence in your code.
We'll have an open and honest conversation on the process of transforming your team or organization towards a more continuous delivery, pipeline driven organization, and the engineering practices you'll need along the way. [...]
TIMECODES
00:00 Intro
02:32 True continuous delivery
03:34 What's missing?
09:00 Increment-enabling process
09:05 Scrum
13:30 Scaling Scrum
14:12 Pipeline driven automation & culture
19:15 XP - Extreme programming
26:21 12 XP practices
36:45 Learning & practicing engineering skills
38:22 Leadership tactics
41:26 Summary
45:47 Outro
Read the full abstract here:
www.meetup.com/goto-meetups-a...
RECOMMENDED BOOKS
Roy Osherove • The Art of Unit Testing • bit.ly/3obiKNB
Roy Osherove • Elastic Leadership • amzn.to/3fxEgID
Roy Osherove • Notes to a Software Team Leader • amzn.to/3wjroxJ
Dave Farley & Jez Humble • Continuous Delivery • amzn.to/3ocIHwd
Kent Beck & Cynthia Andres • Extreme Programming Explained • amzn.to/3muIlCm
Sutherland • Scrum: The Art of Doing Twice the Work in Half the Time • amzn.to/3Bfz85f
/ gotocon
/ goto-
/ gotoconferences
#XP #Scrum #Agile #ExtremeProgramming #Agility #AgileDevelopment #ContinuousDelivery #ContinuousIntegration #SaFe #ScaledAgileFramework #TDD
Looking for a unique learning experience?
Attend the next GOTO conference near you! Get your ticket at gotopia.tech
SUBSCRIBE TO OUR CHANNEL - new videos posted almost daily.
kzbin.info...

[@retrodad9390]

good pres.. from someone who knows his stuff from code to proces and people interaction and back in an practical way. nice job Roy!

[@vitaliykonokrad4566]

thanks for the talk 👍

[@anitsh]

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

[@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

[@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!

[@user-go5ir2tn3d]

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

[@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"

[@om-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.