How Agile Cost The BBC MILLIONS! | Gojko Adzic On Agile At The BBC & Palchinski Principles
ฝัง
- เผยแพร่เมื่อ 17 ก.ย. 2022
- Gojko Adzic tells us about how the misapplication of agile philosophies lost the BBC MILLIONS of pounds and talks to Dave about Palchinski Principles and agile thinking 100 years ago, and how being an Engineer, in an organisation that doesn't want to listen, can be dangerous.
This clip was taken from Gojko's full Engineering Room Episode that you can watch HERE ➡️ • How Agile Failed at th...
-------------------------------------------------------------------------------------
LINKS:
At the BBC, Agile means 'making it up as we go along' www.theregister.com/2016/05/1...
Management of the BBC’s critical projects
www.nao.org.uk/wp-content/upl...
Report by the Comptroller and Auditor General presented to the BBC Trust Value for Money Committee, 29 April 2016
From Gojko Adzic:
Specification by Example, by Gojko Adzic, amzn.to/2TlfYaH
Running Serverless: Introduction to AWS Lambda and the Serverless Application Model, by Gojko Adzic, amzn.to/2VYrBoB
Impact Mapping: Making a big impact with software products and projects, by Gojko Adzic, amzn.to/3gs3PL8
Fifty Quick Ideas to Improve Your User Stories, by Gojko Adzic, amzn.to/3jXM481
Fifty Quick Ideas To Improve Your Tests, by Gojko Adzic, amzn.to/3oCUByI
_____________________________________________________
🙏The Engineering Room series is SPONSORED 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
-------------------------------------------------------------------------------------
📚 BOOKS:
📖 Dave’s NEW BOOK "Modern Software Engineering" is now available here ➡️ amzn.to/3DwdwT3
📖 "Continuous Delivery Pipelines" by Dave Farley paperback ➡️
amzn.to/3gIULlA
ebook version ➡️ leanpub.com/cd-pipelines
📖 The award-winning "Continuous Delivery" book by Dave Farley and Jez Humble ➡️ amzn.to/2WxRYmx
NOTE: If you click on one of these 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
📧 Get a FREE guide "How to Organise Software Teams" by Dave Farley when you join our CD MAIL LIST 📧
The best way to keep in touch with the latest discussions, events and new training courses, get FREE guides and exclusive offers. ➡️ www.subscribepage.com/organis... - วิทยาศาสตร์และเทคโนโลยี
Worked over 10 years in Software and every single company/teams I joined, all said they were agile. The truth NONE of them were. Because they were all too focused on making the product they wanted to bother listening to what the users wanted. (Video Games Production is probably the most impacted by this).
As a developer I'm always looking for the thing that would add the most value. Not surprisingly, like Gojko, this is often where management and politics are happening. Common sense is a rare commodity these days.
Entirely depends on how you would pitch the idea.
Politics is a simple given result of having organisational structures, dependencies and approval processes.
Hopefully tho good, strong arguments for ideas/initiatives outweigh any politics. However if you fail to explain the benefits, able to provide supporting data, market research on consumer benefits or clear performance/costs improvements that are in line with whatever the company wants to achieve. Whatever you might think of value could be entirely subjective to your thinking and might simply not in line with the company, it's current goals or simply not important (right now or ever). Should it be important later, but not now, you should be able to communicate that effectively.
As a product manager i often see engineers completely fail to communicate their initiatives in an effective way. I remember having talked to one principal engineer of my previous startup where the person said: "we need to change everything to kubernetes". I asked him why and he said: "we're not gonna scale with our current AWS architecture". I asked him to prepare a demo on how many customers we would need to require / roughly how many events we would need to handle to cripple our architecture. A week later he reported it. A simple calculation to our current customer base meant that we would need to grow our customer base by ~8000% in the next 5 years to achieve that. (given that we were a B2B space, that was unlikely) In the end he just really really would have liked to have kubernetes on his resume.
So whenever you think about value, think about clear use cases that exist today. Show trends in data that would indicate a need of improvement in the area. Work together with your product manager to figure this out or question initiatives equally as critical as your own ideas. Do you really know why you're building what you're building?
@@martinherrmann5319 Yes, common sense with developers is also lacking these days.
It indeed depends on the company vision and strategy, if there is one. Even the most soundly reasoned and well presented idea fall on deaf ears among big egos, managers barely grasping what their core business is and how to monetize it. Or simply because it doesn't give them prestige or don't want to stick out their necks because the project might take longer than they have been given time for (ie getting rid of 50 years of technical debt). Or managers just wanting to play around with their own ideas (read the companys money) and failing.
in which days was it abundant?
Whoa there, buddy! You can't just go around making sense, providing sensible solutions to problems, and smoothing out friction!?!? No no no. They can't have any of that "common sense" stuff. Imagine the good it would do?!?!
THAT'S MADNESS! Far too radical.
How will they make any profit from the chaos?
Let's discuss more at the pre-meeting strategy roundtable before regular meeting.
Correction to the title: How agile in name only cost the BBC millions, or: how not to approach agile, ever
But I think that's kind of the point per Agile. In most respects, it is about people following the rituals without understanding them.
@@JohnHall Which in every aspect of life is a bad idea.
Totally agree, @bedroomprogrammer
So often I hear Agile in general or Scrum in particular blamed for bad outcomes when it's a failure of the people, not the framework. If I make up requirements as we go like Gojko Adzic mentions the BBC did in this video, it doesn't matter whether we're Waterfall or Scrum, the organization will waste money.
It's like religion: If I say I'm religious but don't pray, don't volunteer, don't help those in need, don't treat people with kindness, don't give to charity, don't follow the rules written in the holy book, and sin every day... but I go to church once a week... am I _really_ religious? Am I getting the value out of my religion that it's designed to provide? Not at all. No amount of Scrum ceremonies can save a product from people who don't know what they're doing.
It's a clickbait title, unfortunately these annoying practices work and on ad based platforms like yt you need to lower your standards for them clicks/views, I do my best to not get agitated by them, but I sometimes fail..
@@JohnHall following rituals is not agile by definition.
Having met an ex BBC IT manager I can well believe this.
So many good points here, especially the bit about politics which is a social art and science in itself that can appear infuriatingly inconsistent to people from STEM with their more concrete, logical way of seeing the world. Our agenda is first and foremost for our biological interests, even if we pretend that we're logical, rational creatures first.
Jobs to be done (JTBD) Theory has been doing great work on this topic of really understanding what the customer wants, and in some cases, they don't even know they want it yet. We, the agile community, should really start looking beyond the “This is not Agile” comment and start looking at other books of knowledge where the work has been done already. As we spend to much time duplicating effort (Muda) over processing stuff.
in software we solve problems. if agile is so hard to get right then agile IS the problem and not a solution!
Because, the truth is that it is not software or the customers, it is the politics and will of the organization.
Excellent excerpt. I hope I find time for the whole interview.
The core point for me at the moment is: Does measurable outcome match the political agenda? (My view may change as I ponder the issue...)
Interesting, I'll have to take a look at the ghost of the executed engineer
Very interesting discussion!
One 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 from the original (full) interview at th-cam.com/video/DSCWSWME8G4/w-d-xo.html.
I've heard this same objection applied to much smaller amounts of money. How can you spend ONE MILLION DOLLARS on development and STILL not know whether the product is adding value??!!?? Well, the reason why that can happen is because $1MM is a minuscule amount of money, and if the product has high table stakes, the market is emerging, and customers don't really know what they want until they see it, then it's quite possible that you will need more money to achieve product-market fit. You gotta be realistic here. It costs about $10MM per mile to build a highway in the US. Software startup entrepreneurs such as myself are out there starting businesses which DO add value, and are expected to do it with less money than it costs to build one tenth of a mile of highway. But then investors will say "we're not gonna invest a single dime until there's rock solid proof of customer traction."
For a little perspective, $1,000,000 is only 3-4 man years. There are small genius teams that can add big value in just a year, but, without an auspicious situation, it would be idiotic to expect much. Lots of projects do fail.
It's not a good thing to go fast of you're going in the wrong direction (quote from Kevlin Henney I think)
I have been thinking about the edges of design Dave has mentioned in several videos and how they are to be avoided. My experience is the opposite: that the surest way to create value is to embrace the edges and make that your starting point. Because that is where the user is so you can constantly test for value as well as function. I think the examples in this video illustrate my point.
the internet has ruined me. everytime I hear him say BBC I giggle
From the article:
*_"The BBC Trust admits that MyBBC “did not define its its expected benefits upfront”, because because it “was an ‘agile’ project where benefits were to be defined as the project progresse[d].”"_*
That's not agile. In an agile project(I'll go with Uncle Bob's agile), the first thing you do is you define the use cases(user stories) *up front* , before you even have created a folder and a git(or other source control) repository. Then you rate these user stories: how much time they'll take. Then at the end of each sprint(which should be an adequate time like a week or 2 weeks) you have a fully-working buildable and fully-deployable solution that automatically deploys itself with 1 click. That's agile.
If you don't have all of these things in your project, you're not doing agile. There's more to agile, of course, but these are the absolute minimum to call a project agile. Whatever they were doing in BBC wasn't agile, because the project wasn't ready to be deployed at the end of each sprint(did they even have sprints?).
It's like saying that OOP is bad and cost you a lot of time and money when you was creating only concrete classes with concrete dependencies on other concrete classes, and was calling it OOP. Or it's like saying that functional programming is bad, when all you did was creating global free functions that were operating on global variables, and was thinking that you were actually doing functional programming.
In all 3 cases people weren't doing the thing. They just called some other thing the same name.
Sprints != agile and agile != sprints.
As an engineer my self. Way back when I work for a well known company. My voice is heard even if I still in the lower ranks. Its actually good to have a feedback from the lower engineers who does the work. But now in my new company. Leaders will disregard your concern as you are mearly complaining and just lazy to do the work. In which it's not the truth. The methodology and fundamentals of a project is just screwed and just made up so that certain individual in the top management looks good with the CEO. In the end. The project is just wasted and not used. Actually not needed just a waste of implementation.
That's why we have Agile in software development despite what actual experts opinion. You can't talk to a leadership that don't want to listen. Listen to his story about the engineer executed by Stalin.
Key lesson = We all know Agile is not used effectively/properly, it is more important to say we do agile but not doing it to follow whatever the management want us to do. If you open your mouth and speak the truth you get fired. (cf Engineer vs Stalin). Happened to me and I was at C-Level. Dont challenge the propaganda, no one really cares about the truth, the quality of the product, or process... took me way too long to understand it. I was a true believe and very naive about it. What matters is what your boss or boss's boss want.
Thats more like go horse without goals than agile lol
100% go horse kkkk
Clickbait title?
could this title be: "AGILE done wrong because managers gotta' manage cost the BBC..."
just asking
Well I don't think it should be only the responsibility of "managers" to have a vision of where the project is going, but yes, that was certainly part of the problem. The trouble is that working iteratively, as agile demands, is great for giving you good visibility of where you are, but you still need to monitor that and have an idea of where you'd like to be, and in a commercial org, decide whether or not what you are doing is still worth it.
I think that this is a more unusual type of failure, most orgs try to plan too much, but this one is certainly the other end of the spectrum, from that.
i don’t think he public sector is a a good case study for any framework/tech/anything .. there’s only a handful of things that are done right (mostly moj and gds) .
I disagree, and the BBC have done some good things with agile and CD too. These problems are just as prevalent in the commercial sector, they just get talked about more when public sector orgs messes up.
The UK (insidegovuk.blog.gov.uk/2021/08/05/how-and-why-we-switched-to-continuous-deployment-on-gov-uk/) and US (www.coveros.com/implementing-continuous-delivery-in-the-federal-government-2/) government have done some excellent work in adopting Continuous Delivery and DevOps for example.
BBC = Stalin. Can't disagree with that analogy.
i'm a bit irritated by this framing. MyBBC - as usual - was expensive and had many issues and the typical "not really agile" stuff, but it did not "create no value at all". Switching between devices during a video for example is a feature you find in many other solutions nowadays like Netflix for a good reason. What they didn't do for a long time, was defining benefits for the BBC auditors and how to measure it. The critique was basically: you do not provide enough proof to the board to get more money, you just got more money - the whole report reads like the typical large company BS, where you have to make up S.M.A.R.T. goals so controllers have a reason to exist.
Of course it's not "agile" to make a 2 year plan to implement 9 features (which nobody denied are of value) and of course 2016 the BBC (and the contractor) was not able to do such a big project in a text-book agile way. We all wish that big companies would be able to work agile, but they don't. Especially because many projects require a year of work, before anyone can see or measure any actual "value". Even at Netflix or Spotify there are projects, in which developers work for months in a box and deliver sprint by sprint boring useless backend services, which are not integrated into anything until they are at least 80% feature complete.
That romantic agile approach, where we can measure the success with usage-metrics, view-times etc and adjust, doesn't work for many projects, they have a pretty fixed scope and timeline and the value-discussion is mostly an academic and dogmatic waste of time. Nonetheless there is still value in working in small increments, even if the value is just, that after 3 weeks the application is still running with a new rest interface, which is not called by anybody and would do nothing because a thridparty-system won't provide the necessary data for 4 more month. This will not improve by making up a "fake" goal so i can measure the progress.
It's simple
Good programmers writes readable, extensible code without all the 'agile' thing.
Uncompetitive programmers write bad code.