How Agile Failed at the BBC and the FBI | Gojko Adzic In The Engineering Room Ep. 3

Рет қаралды 24,693

Күн бұрын

In this episode, Dave Farley chats with Gojko Adzic. Gojko is a prolific author, international speaker on software and expert practitioner in DDD, BDD and an AWS Serverless Hero. Dave and Gojko chat about a wide-ranging series of topics on product development, steering development organisations to success, Palchinsky principles and how agile development failed for the FBI and the BBC. It’s a fun episode! ( ➡️ gojko.net)
Welcome to "The Engineering Room", a series of wide-ranging conversations with thought-leaders from the software engineering industry. This is a new mini-series of additional content on the Continuous Delivery Channel.
-------------------------------------------------------------------------------------
LINKS:
Gojko's new text-to-speech video maker ➡️ www.narakeet.com
MindMup - MindMapping tools ➡️ www.mindmup.com
PAPERS/ARTICLES:
Why FBI cannot build a case management system ➡️ www.computer.org/csdl/mags/co...
At the BBC, Agile means 'making it up as we go along' ➡️ www.theregister.co.uk/2016/05...
Shades of blue at Google:
1️⃣ www.theguardian.com/technolog...
2️⃣ www.cnet.com/news/google-desi...
-------------------------------------------------------------------------------------
📚 BOOKS:
🚨 MY NEW BOOK! 👉 📖 "Modern Software Engineering" is now available on Amazon ➡️ amzn.to/3DwdwT3
In this book, Dave brings together his ideas and proven techniques to describe a durable, coherent and foundational approach to effective software development, for programmers, managers and technical leads, at all levels of experience.
📖 "Continuous Delivery Pipelines" by Dave Farley
paperback ➡️ amzn.to/3gIULlA
ebook version ➡️ leanpub.com/cd-pipelines
📖 The original, award-winning "Continuous Delivery" book by Dave Farley and Jez Humble
➡️ amzn.to/2WxRYmx
The Lean Mindset: Ask the Right Questions, Mary Poppendieck ➡️ amzn.to/2yBDOpz
Four Disciplines of Execution, by Chris McChesney, Sean Covey and Jim Huling ➡️ amzn.to/2QqzE9T
Adapt, by Tim Harford ➡️ amzn.to/2XPvn3i
The Ghost of the Executed Engineer, by Loren Graham ➡️ amzn.to/3lrUQxi
NOTE: If you click on one of the Amazon Affiliate links and buy the book, Continuous Delivery Ltd. will get a small fee for the recommendation with NO increase in cost to you.
-------------------------------------------------------------------------------------
Also from Dave:
🎓 CD TRAINING COURSES
If you want to learn Continuous Delivery and DevOps skills, check out Dave Farley's courses
➡️ bit.ly/DFTraining
📧 JOIN CD MAIL LIST 📧
Keep up to date with the latest discussions, free "How To..." guides, events, online courses and exclusive offers. ➡️ bit.ly/MailListCD
-------------------------------------------------------------------------------------
⭐ SPONSORS:
This series is brought to you by Equal Experts.
Equal Experts is a product software development consultancy with a network of over 1,000 experienced technology consultants globally. They increase the pace of innovation by using modern software engineering practices that embrace Continuous Delivery, Security, and Operability from the outset ➡️ bit.ly/3ASy8n0
-------------------------------------------------------------------------------------
CONTENTS:
00:00 Intro
03:28 How to start something new
05:03 “Behaviour-change” is an incremental indicator of direction
06:00 Agile development as cause of multi-million pound loss at BBC
10:18 “Impact Mapping” and steering product direction
12:28 Finding a route to a solution
13:50 “Adapt: Why Success Always Starts with Failure”
17:50 Organise work as a series of Experiments
22:30 Identifying the right things to measure
26:29 It’s tough to stop bad ideas - “Lockheed Martin has better lawyers than the FBI”
32:00 Palchinski Principles - Agile thinking 100 years ago
37:30 Humans vs Computers
42:11 Is “Observability” just good monitoring?
46:47 The Netflix “Canary Index”
47:24 Impact of the Cloud - A two-person company with millions of users
51:04 Why is the cloud so difficult for big businesses?
57:14 The importance of the “protocol” in design
59:32 Cloud - Raising the level of abstraction
1:03:20 Cloud - Elastic scalability for (almost) free - “15,000 Russian teachers”
1:11:16 Event-driven systems & Actors

Пікірлер: 65

@robertruzitschka7154 Жыл бұрын

Gojko is an amazing story teller - his talks are very inspiring as he synthesizes a lot of knowledge from different areas and presents them in an engaging and lively way. A lot too learn! Thanks, Dave, for bringing him in!

@micheljtremblay4890 2 жыл бұрын

Very interesting refreshing to be able criticizing big projects .. a good point was... We are measuring too often what is easy to measure and not what it's important to measure... I enjoyed listening this conversation, thanks

@bakedbeings 2 жыл бұрын

The extra work adding chapters is much appreciated 🙏

@mr.ssergeev 2 жыл бұрын

Gojko is one of those people who will drive the people in the industry in following decades. Amazing how many different things he knows and how passionate he is, how interesting his books are.

@63kOhm 2 жыл бұрын

gojko is a force of nature. I know it's a strong word, but i love this guy. great talk. i can't belive we got this one for free.

@quinnjones1221 2 жыл бұрын

Gojko is one of the FEW creators of a software system\framework that would ALWAYS answer any question I had on implementation and issues\concerns AND more importantly he always helped me run up the J-Curve especially with DBFIT. I guess what I am saying is you are SPOT ON with your comments about Mr. Adzic

@jpokroy 2 жыл бұрын

Very interesting discussion! One minor correction about the BBC. The *DMI* programme was indeed a costly & miserable failure, whereas the later *myBBC* programme was in fact regarded as a success (the current BBC Account services that are in use at massive scale across the BBC's suite of products were created under myBBC). This error, repeated by Gojko in his discussion of this topic, is in the article from The Register that is linked to in the description.

@paladinsorcerer67 2 жыл бұрын

Summary of the talk: 1) come up with many ideas, so that if you reach a dead-end, you can back out of it and switch to a different idea. 2) developers focus on their "zone of control" or "sphere of influence" because its easier to work with what you know/what you can affect. 3) the change in behavior that you witness in users will indicate to you how to change the software. 4) measure what actually gives you value, rather than what is easy to measure. 5) dont measure intermediate steps, rather measure what will get you to the product end-point. 6) adapt and reassess early in a project to avoid spending $50M on a product that delivers no value. 7) monitor the product from the inside and outside of the app, looking for the unexpected. 8) take advantage of the latest abstractions so that a small team can have a big impact. 9) to address apps that have poor performance, look into the levels of your tech stack and identify where the inefficiency is coming from. 10) if edge cases could happen 1 out of a million times, but your users are interacting with the system 1 million times per day, then the edge case becomes one of the main uses cases to address.

@vladvesa8296 2 жыл бұрын

I appreciate a lot the book references. Keep these interviews going.

@troelsirgens-mller9922 9 ай бұрын

Enlightening discussion. I wish The Engineering Room was published as a podcast, it would make it possible to listen to it on the go. KZfaq videos are not made for bike rides.

@jonathanaspeling9535 2 жыл бұрын

Super inspired to read a lot more! It's a common thread shared between all industry leaders I've observed. Ferocious Readers! Books are to the mind what the whetstone is to the sword

@Oswee 2 жыл бұрын

The first thought which comes into my mind is that developers should learn to capture their knowledge early. One of the great discoveries of mine in this context was Zettelkasten method and the Obsidian software. Links and the backlinks is all you actually need to capture and revisit your knowledge. Eventually we all will end up in consulting and and sharing our experience for the new and faster generation. So... to prepare for that we should collect our little gems. I do really love this series!!!

@kikitauer 2 жыл бұрын

So this was a delight indeed! Thank you for this interview. I've been thinking about the abstraction state of development and software creation and I share some of your concerns. On the other hand I am very grateful for it because it means I can call myself a web developer while not even a year ago I was working in entirely different field. Anyway I really enjoy this podcast format with various interesting people and I hope there will be many more episodes 😊

@dinoscheidt 2 жыл бұрын

I love the story telling in the mid of the talk. Lovely - thank you two!

@fmkoba 2 жыл бұрын

awesome!!!! I love Gojko’s books and talks

@centerfield6339 2 жыл бұрын

"Stateful serverless" - see Clouflare Durable Objects. Fascinating.

@alex_2_ 2 жыл бұрын

Very interesting and insightful! Thanks!

@callumw9067 2 жыл бұрын

thanks - very similar conversations we are having in the world of security - too many security solutions focus on nothing that gives business value (or anti-value) because it is too hard to. It also doesn't help that the core security glitterati have never built systems before and are so behind with modern systems thinking.

@stochasmvid 2 жыл бұрын

Awesome! I'm at this very moment playing with Narakeet. You WILL see videos soon! My experience trying to make videos is exactly what his "About" page talks about. This is totally transformative.

@BryonLape Жыл бұрын

I normally don't click videos that have agile capitalized, but I made an exception based on the Martin Fowler and Allen Holub chats.

@Bianchi77 2 жыл бұрын

Vote up, nice video clip, thank you for sharing it :)

@mirzasisic 2 жыл бұрын

I love Gojko's Bug Mangnet extension, I use it almost every day.

@aleksandarpavlovic5052 2 жыл бұрын

High value content, many thanks! Could you please post the link to the referenced Microsoft study ``where they reckoned two thirds of their ideas provide zero or negative value``?

@ContinuousDelivery 2 жыл бұрын

It's from this paper exp-platform.com/large-scale/

@anj000 Жыл бұрын

Cloud is just someone else's computer. I get the sales pitch, but I really think that it will back fire hard time. We are basically giving all the power to very few companies. It simply can not end well. True power and beauty of the internet is that anyone can join in. Someone can write piece of HTML on their computer and essentially put a site world wide. Just because humans are greedy and want cheep solutions to complex problems (essentially that means cloud), we are giving up this freedom. This process is slow and you won't notice much difference only carrying about day-to-day work, but when we go 100% cloud we could never go back.

@edwardharman1153 2 жыл бұрын

I work for a popular website where I learned about A/B testing. My favourite test was when we made the "View Deal" button slightly larger and the data showed that more people clicked it! I felt obliged to mock up a page design where the button was 50% of the page. (Then there were the multiple different colour tests... I think orange was good)

@ContinuousDelivery 2 жыл бұрын

Did people like the big button? 🤣

@redhotbits 2 жыл бұрын

any videos on code reviews here?

@DerylSpielman 2 жыл бұрын

Cloud is so difficult for big business because there is so much process built around whatever already exists it's hard to justify changing anything if it "just works". I believe there isn't enough "observability" on lead/cycle time metrics across business processes, services, and dependencies to understand whether cloud makes an improvement to either time-to-market or speed. You also just can't lift and shift because how you write/architect apps directly impacts cost in the cloud. E.g. a loop making many calls to a messaging system may go past the limit of free requests and programming in the cloud you might change the content of the message so you're not requesting as much. It's a total paradigm shift.

@abhaikollara5811 2 жыл бұрын

18:31 - "very often what people do in our industry is measure something that's proportional to effort rather than measuring the outcome". Slow claps

@konnaf24 2 жыл бұрын

"get the protocol right" what is a protocol in this context? Examples?

@Modzybear Жыл бұрын

When it comes to dumb measurements I would often point out that it is easier to measure the temperature of a boiling pot of water with a thermometer than developing a system that calculates an estimate based on the number of bubbles.

@chaoslab 2 жыл бұрын

Thank you to you both. Any one else miss 68000?

@slr150 2 жыл бұрын

21:19 You're talking about a centrifugal governor.

@dxhelios7902 2 жыл бұрын

The main issue with agile is unpredictable budget - it is "by design". Otherwise it is not agile. May work well for startups and in internal teams. Headache for software production houses.

@rukekakambari4314 2 ай бұрын

I think Gojko has seen a lot and has more to say but time is a big constraint. I wonder how is like to work with him. I really like people discussing how things works under the hood instead the just it works kinda devs

@alk99875 2 жыл бұрын

is there a tldr version? please! I'm interested in the topic but find this video too long

@ContinuousDelivery 2 жыл бұрын

No, this is all there is. There is a timeline showing topics in the description.

@alk99875 2 жыл бұрын

@@ContinuousDelivery thank you! I'll watch the video sometime later

@tomtomtomtom691 2 жыл бұрын

Gojko Andzić sounds like Slavoj Žižek but without the ticks and going off on tangents.

@miodragradosavljevic8517 2 жыл бұрын

Svaka cast Gojko ! Nema tvojih knjiga na Srpskom ?

@gojkoadzic7231 2 жыл бұрын

nema, nazalost nije dovoljno interesantno za domace trziste.

@miletacekovic 2 жыл бұрын

Pozdrav za Gojka od bivseg kolege iz Finsoft-a.

@alessandrob.g.4524 2 жыл бұрын

Dude never lets Farley talk lmao

@cyberpunkdarren 2 жыл бұрын

Agile is a bloated mess. Endless meetings. Too many roles, charts, terminology. Nothing like what was originally intended.

@elfnecromancer 2 жыл бұрын

That's not agile. You are probably talking about Scrum or Scaled Agile (SAFe). Scrum is a methodology older than Agile often mistaken for Agile, which it is not. SAFe is a fraud.

@dawidwielgos1080 2 жыл бұрын

@@elfnecromancer I doubt he is talking about scrum. It has three roles only and 4 meetings that are supposed to take care of all meetings you should have.

@cyberpunkdarren 2 жыл бұрын

@@elfnecromancer Gotcha. Then yeah. What you said.

@cyberpunkdarren 2 жыл бұрын

@@pm_ordinarychap Endless. That's right. Lots of meetings that go on forever. Tell me. Do projects on github use these meetings? No.

@cyberpunkdarren 2 жыл бұрын

@@pm_ordinarychap people who develop complex projects on github and in fact the entire workflow of github projects is "meetingless". Now im not saying within a business you cant have meetings AT ALL. But the current agile, scrum, safe landscape is obsessed with meetings. When i say 'endless' i dont mean the duration of the meetings i mean the recurrence of them. That should have been obvious. These meetings are more ceremomial and rarely productive.

@dxhelios7902 2 жыл бұрын

Nothing about what was in the title. At least one thing is right: serverless is the cloud, containers is big BS that must die in pure form. Should be wrapped in serverless. Containers suck from maintenance and security perspective, host interaction. Discussion starts with some idols and books. 30 mins passed - still idols and books. Pfff. So what went wrong? @Dave "you don't need to take care about the tech underneath with serverless". Data exfiltration? Enterprise security? Hybrid? You need to take care. Effort is smaller of course. Maintenance simpler. But we need 5 years to make it standard - to minimize effort. Today we try to mirror on-prem in the cloud, we need to transition firmly to be able to mirror cloud in on-prem. Then we can say more or less "you don't need to take care". "Inconsistency is fact of life" - agree. You have to make eventual consistency fact of life as well and adjust to biz reqs. "Where to keep state?" Not a lot of choice: RDBMS and/or Cosmos DB. Lakes are for inactive states. Nothing else was invented yet. Cosmos DB is actually good. Support for eventual consistency is of course an issue that should be solved in both theory and in products.

@retrodad9390 2 жыл бұрын

Or more "evil" people know what to measure but just don't it, so they can fail secretly..... only use shallow KPI's to sell their story… for me is the discussion of adding better measurements is a measurement to see is people or companies want to change... sometimes it can be changed with coaching and sometimes not and discussions are just ways of not making the hard decisions. Good video BTW and books!

@xtrailz 2 жыл бұрын

Gojko - "if you are the BBC and are funded by public subscription you can waste as much money as you want" Yeah, that's what happens when the service is funded by a compulsory licence fee.

@seamusconnolly9710 Жыл бұрын

A bad workman always blames his tools. Agile and Scrum as a framework within is a tool.

@Daniel_Zhu_a6f 2 жыл бұрын

"Stalin didn't want energy, he wanted a big ***g dam" -- that's just stupid. I mean, Stalin was a communist and communism is naturally about optimization and cybernetics. it was basically born from the idea of transaction cost optimization. it just was not phased in those terms at the time.