*Timecodes* 03:00 UML 06:20 Creation of The -Agile Manifesto 10:45 _Agile_ is not a noun 18:00 On testing 21:10 Stop Thinking & Get Certified Today 23:00 It is time to reclaim Agility 24:50 The PID Algorithm 35:00 Agile is not what you do. Agility is how you do it. 37:55 Questions
I would like to buy this guy a beer. In every organization where anyone questioned why we were using Agile, it always came down to, "Give it a chance." Almost everyone in the room had already given it lots of chances, and few of us had ever seen any payoff from all those meetings. Agile was mostly a career stepping stone for people with little or no technical experience to work their way toward IT management.
In some cases management will think it's the team members problem and will add more consultants to help the team, instead of listening to the team that it just doesn't work for them
I am going to tell what is really wrong with Agile : it is not being used to help make better software or make the users happier. It is being used as a worker management tool, and as an avenue for promotion for non-technical people. "I am the Scrum Master, I am Agile Certified". It is an instrument of government bureaucracy which is helping only those who are administering it, training in it, and for the self-promotional types of people who just want to be paid to show up in pointy shoes and demand a leadership role..
The true measure of humor is the amount of truth it contains. The Dave Thomas analysis of Agile had me in fits. Finally he who dares to seek the truth, wins.
I honestly reference this talk every job I've gone to. And has been a key voice in shaping my own approach to software. Love the humour and the pragmatism
Such an amazing talk. I totally agree with this. So many people buy into Agile Inc. I never understood why... It makes much more sense to have autonomous thinking developers who are willing to investigate, experiment and 'move' in a way in which they can progress in an iterative matter. The current state of how Agile Inc is integrated into businesses, causes more harm than good, in my opinion.
One of the things I liked about the last place I worked at was that it was a blended process, yeah we had cards to be done (tasks.) Two week releease windows, etc.. But the process was simple, we'd look at the list at the beginning of the period, pick what we each wanted to work on and guess how long it would take. Each day we just said how we where progressing, no pushback, etc, just say the truth. If you finished and it was tested and published you moved onto another card of your choice in the list. You repeated this until as many features/bug fixes as possible where ready for the next release. The best part was you had no-one screaming down you neck, you wrote it how you wanted to, there where design standards to follow but the important implementation side was your creativity. That company was MSX International.
"The values have been lost behind the implementation." Culture, values and principles inform our decisions and drive our actions. If you want a movement to succeed, the leaders must be relentless guardians of the culture.
I loved the reference to "Are we doing it right" 16:11. I heard this in a standup a while back and knew immediately that the team had lost it's way. The answer to that question should be, "Are you getting the result you want?". If not then all the "Doing it right" will not result in any value being delivered. The team was doing a lot right, and getting very little done.
@OldPossum IMHO they can easily help someone get a job, or to specialize in some platform. Like a mongo-university dev certification, or an oracle dba one. Certs shoun't be compared to a full university degree. But using them to have a background of some sort for a couple of years until experience is gained, is perfectly valid
@OldPossum This is one of the silliest things I've heard, they all have their value. Sure, a single certification is nothing compared to a single degree... but one takes a month or two to get, and the other takes 4 years. They are very practical for 1) telling others you have skills in a certain tool, or specific area 2) gently push your career in a direction you're trying to move in. I just earned my masters in computer engineering last summer, and I'm keeping up with certs to still appeal to recruiters. About your WinNT 4 sysadmin cert comment.... Anyone here who graduated in 1996, their specific degree is just as useless today as is that cert. You get a degree to get a job, and over time your experience at your job(s) replaces and exceeds the value your degree ever had. The same thing for any certification. It's a small jump to get you where you need to go, it's not going to carry you for the rest of your life.
This is a fantastic video! As systems theorist, I very much appreciate the reminder that we ought to understand the underlying principles and purposes and build a practice from there rather than approaching it the other way around. Thank you for this!
Superbe conférence sur la _méthodologie agile_ par un des auteurs du manifeste du même nom. Retour aux fondamentaux: 1. Déterminer où l'on en est 2. Avancer d'une étape 3. Tirer les enseignements de 2 4. Recommencer. Face à deux options amenant au même résultat, privilégier celle qui offre le plus d'ouvertures.
Great talk. Agility is the spirituality and Scrum, Kanban, etc are the religions promising to bring spirituality to the masses. Just like any religion, it didn't work out since only rituals remains and the spirit is lost.
The methodolgy industry has been on the go for years. Either an experienced guy formalises what worked well for them or a bunch of academics dream up a very fine set of names and diagram formats to differentiate common concepts and techniques. Each one is seen as the silver bullet so at last we can offer our bosses, Quick,Good and Cheap instead of pick any two from these three. Training courses are done cv's massaged and it's all trashed the following year by the new shiny thing.... As always the best advice is the shortest. small steps and don't paint yourself into a corner. I'd also add; hire and develop good people.
Mustapha, yes. But keep in mind: You change the context, and with that context comes new problems based upon that context. Similarly, you change the methodology, and you end up back where you started. We are no more productive today with agile/scrum/xp than before. We're just finding new ways of expressing the same old thing. And perhaps there never was any problem to solve in the first place.
Hes sayng that the whole idea was misunderstood from the begining and hes actualy giving a new definition, simplifiying it to the fact that being Agile means to adapt to changes, like the two wheel robot that maintains equilibrium constantly reacting to the forces that afects it on every moment.
christian galicia, sure ok, but "adapting to changes" didn't suddenly show up with agile. It's not as if the lone wolf way of programming in the 80's had no way of adapting. Being able to adapt is simply a function of hiring the right people, just as it's always been. Seriously, every few years coming up with "hey this way of thinking is new" is not new. All the same development problems from the dawn of time are there, they're just given new names. And by the way, "extreme programming" is a perfect example of this.
I understand your point, however don't completely agree with you. I dont think that is 'simply a function of hiring the right people'. Adapting its more than that, its a matter of doing what needs to be done in every moment. Adapting its about constantly monitoring the state of a project. You cant reduce that to Hiring the right people. On any case i would ask you, what does that right people the you hire do to adapt? What arouse with Agile, was the realization that it was not a matter of having fixed plans, but a matter of being flexible enough to change the plans on the way in order to adapt to every moment until the project is properly landed at the right moment with the right specs. Yes All the same development problems from the dawn of time are there, however the solution to those problems have evolved in new methodologies.
I read the comments and I come to the conclusion that most of you don't really know what Agile is. You don't "use" Agile, you are Agile or not. It's not what you do, it's how you do it. 99% of the companies who put themselves the Agile label are not Agile. Usually the ones complaining about Agile are those who don't understand it (and it's quite simple, really, just read the manifesto) or those who despise collaboration and change. If you believe in hierarchical delivery teams, you like giving orders, long term detailed plans and having software engineers not questioning things, please do us a favor and don't even try to become Agile because you'll either fail or lie about how you're doing things.
I have confidently turned around projects using Agile and Scrum. I ask a few questions to myself: 1: Can everyone in my team articulate an overall picture of the new business dynamics?-A well fantasized and elaborate mental image of how the new business will be done by different roles and that too in diverse situations? Does my team know it, think about it, creatively embrace it, passionately define it and only then put it in the sprints? Do we plan only these types of stories and sprints? Agile is NOT a magic tool, it is how we use it. (Not to just develop a feature- NOT to merely improve a process - NOT to demo a cool functionality). 2: Do we have a well developed test scenario for every story ? (not automated but a test that captures comprehensive business dynamics & IT management. e.g. just a "Sign On" feature means different thing for a VP logging in from the airport VS. a docking supervisor in bitter cold of morning shift or a sales employee "logging in" from a client site. For IT dev team - a DBA thinks of "Sign On" differently than a Security or a mobile app developer or API programmer or a Cloud performance guy. A comprehensive tribal knowledge about each other's contributions can be achieved only thru daily cross teaching called stand ups. NOT any rambling about what I didn't do. There are several such energetic impulses we need to bring in the team- That's Agile for me. Connect with me to turn around your Agile teams instead of complaining. tonydesai10@gmail.com
19:50 - With respect, he's missing the second important function of tests: it enables subsequent refactoring and evolution. There's no such thing as code that's so well-designed that it can't be broken by a subsequent change. Unless you're a loner who writes perfect code on the first try, you need to be writing tests. 24:30 - Code with no tests is harder to change.
My philosophy is that every part of your software's surface area exposed to users will be tested. The only choice we have is whether we test it as developers, or leave it to our customers to test. I can promise you that the latter is the worst case scenario in about 18 different ways.
Absolutely agree. Even if you don't care about refactoring and are OK with poorly designed code, you need to keep track of upstreams *at least* because of all the CVEs coming out every day, and you can't upgrade safely without good test coverage.
It's also all the other underlying stuff (OSes, frameworks, etc.) thats constantly changing, i.e. even if your code doesn't evolve the support structures are evolving all the time with updates/security fixes/and so on
@@EvgeniyDolzhenko languages deprecate functions, so what ran in one version, might not work in a future version of the same language. Libraries change, database software changes, and backwards compatibility may not be a priority. I work with some websites that had a perfectly fine working form processor, but some of the functions they used in php 5, are deprecated in php 7, and just no longer there in php 8.
One corruption I've seen in the real world is that when multiple options are available, real world teams tend to choose the path that requires the least amount of effort instead of the path that makes things easier to change in the future.
Makes sense in a speculative business environment where the code base will be thrown away anyway. Bad quality, no long-term vision, a lot of focus on badly implemented features
Best practice... we're all looking for the cheat codes to making implementation of complex systems easier. The real secret sauce is practice implementing complex systems. Try explaining that to the business analysts during your multi-sprint planning sessions.
I tried to convince my managers and co-workers for the past 2 years that Agile will destroy our system at work but no one listens. I'm just the "crazy" analyst.
In my last project I tried make it work for everybody. Tried include them all in my code and I lost the deadline and my health. I never felt so depressed doing the fuck same thing I always did with glory before. Be yourself and don't let the rulers kill their self bring you together. Always do what is real better for you if you know what is the best. Don't waste your time arguing with them
@@JoeGilson1 this was the weirdest part of working on many "agile" teams over the past 10 years... just about any stupid trivial thing that could obviously be done in 15min or less, would become "2 sprints of work" involving 5 people... but of course at a software consulting company, that's a feature not a bug lol
@@PplsChampion thats why Im very keen on distributing certain tasks, code review oke, but he can work on a and she can work on b. We (team/stakeholders) all know a and b are the most important, lets just do it. Not to much time breaking things down to far to be able (or pretending) to predict when and when it will be delivered. Own your shit, find a way of working that the team likes, but make sure you keep delivering to your stakeholders. Simple as that.
I hate Agile, the people who turned it into a brand and religion, the people who sell it, the people who assume it's the secret to efficiency, and the people who keep saying "we're dedicated to being Agile" as though the incantation wards off the bugs. Every company I've ever been at had really good programmers who used to be very productive, were forced into the religion, and whose happiness and productivity plummeted at the same time as dead weight found a new purpose in the organization, until it all collapsed.
Hey, I see that some one disagree with this talk. I remember my university time when I were thinking how does people know about that. And that impression that everyone is on the same page except You. I remember UML courses and still not a big fan... thanks for clarifying one of my hypothesis, I can sleep a little better tonight. Then once again :D there's no rest for the wicked :D This talk is exactly what I want to hear like candy for may ears and soul and back there somewhere inside hidden a nasty thought that this could be a trap... I'll not continue, maybe just a bit of paranoia. I can agree with one thing 100% that this software development, it doesn't mater how we call it, should be creative and experimental.
As an Architect, some of the worse solutions and I have seen were done Agile. Works for small projects and helps reduce risk of consultancies (get paid and run away!) I like Agile but very disappointed on the success rate.
Agile does some things well, and other things abysmally. What it fails at is *design* and *user* satisfaction. What it succeeds in is creating a whole-team development culture. Its chief sins are (a) the substitution of "use cases" for a formal design [and this one is fatal over the long term], (b) the permission to write development "speed bumps" off as "technical debt" [that sometimes never gets resolved], and (c) continuous integration. _"Now wait,"_ you ask, _"how can CI be bad?"_ It's bad because, if there are multiple versions available, all of those multiple versions will be run by the user population, and troubleshooting those will be difficult. Of course, the advice is "upgrade to the most current", but that's kind of like a help desk that says "reboot Windows" whenever you have a problem -- not satisfactory in a large number of cases. Managers and investors love Agile: the product goes out the door generally on time and under budget. But *what's going out the door?* Quality? Something you'd be proud to have wear your brand? I think generally not. The adoption of Agile cannot be a 100% policy; it fails badly for large projects. Sadly, small projects do not represent a majority of the software available in the market today. The Agile Manifesto has to be the most violated set of guidelines on the planet. What I'm seeing in the commercial arena is that micromanagement is being mixed with "digital transformation" in the name of Agile, yielding a brand new, unheard of, and in many cases unexplainable way of reporting on your work status, and yes, even "enhancing" the toolset a developer uses to give management "dashboards" on where they think any project is. *This is not the way developers work, nor the way they want to work.* Agree with you, @musmanakram -- Agile is not beneficial. I'm sorry, software isn't cheap unless you write it yourself ... and even then, it still takes time, cash, knowledge, and effort.
@@8a41jt Great points. As I've watched the firm I work for transition (painfully) from waterfall to Agile over the past several years I've noticed that there probably isn't a single person in the firm that truly understands what it is and entails, and probably not any two people in the firm that could give you the same definition for it. It's vastly misunderstood among groups of people that hear the term and know it's something that management wants them to do, but they don't really have any idea on how to do it. It's a complete and utter mess when you have an organization full of people that hear buzzwords if only to repeat them whilst never researching the actual meanings of any new terms (Agile is old of course, but still), and there is no proper training given to GET people all on the same page and understanding what it means (nor any Agile coaches or experienced scrum masters brought in from the outside). Absolute chaos. Aside from all of that, even if everyone at the firm DID truly get it and were all on the same page, it would still suffer from the fallacies you mentioned. It reminds me of something one of my teachers said before about communism. "It looks great on paper but doesn't actually work that well in real life." I feel the exact same way about Agile. Some people can sell the sizzle of it, sure, but I have yet to see ANY team where I work utilize it effectively to achieve a desired result - not once. I think much like communism (or any methodology really), humans are the problem. A group of people will get together and jack something up real good much more often than they will cooperate efficiently to get the goal accomplished. Now for the worst part...I've seen where people use the general confusion around Agile to basically shirk out of doing their jobs. For an Agile team to work, EVERYONE needs to be on point and cooperating fully. I was on a team where the business guy refused to give any details regarding User Stories. The stories would basically be one liners with no Acceptance Criteria. The team kept asking him for more details because literally, the ask was never clear. He kept harping on about how Agile means "the team" needs to get together and come up with the AC's. That's great, but "the team" still needs enough details to even get off the ground at all. He basically just didn't want to do his job and he fought voraciously to not have to write Acceptance Criteria. Then on the same team we had a tester that would sandbag all sprint leaving tons of work undone on the last day and then call in sick on that day. THIS guy said the word "team" more than anyone, when in fact, HE was the one not being a team player. If you couple all of that mess with the fact that to truly deliver with the rapidity that Agile has made management think deployments should happen, automated testing must be top notch - and it never is. Projects are started for existing applications for which there is little to no automated testing yet in place, dev runs as fast as they can to deliver by the right dates, testing falls by the wayside, and when the project is "done", it goes out the door with HORRID quality. The pace is just too fast for most groups of humans to keep up with when it comes to updating legacy applications or creating new apps altogether. That project I was on with the lame testers and business dude....the entire thing failed, was scrapped, and $12M went down the drain. Why? Because Agile isn't that great to begin with, and humans turned it into an absolute circus.
The reason is that PMs are running "Agile" now. It was originally created by technical guys. Now it is project management. Thats why the Software Craftsmenship Guys came into existance. If you actually do the XP practises very well than the "project management" parts of the agile world (like scrum) can help you get more done. But if you don't do the basics right, you just produce "double the shit in half the time".
It's used on Microsoft windows teams, which isn't a small project. Again as the presentation also said, you have to make the process fit for your particular situation. Next to that, you have to deal with the competencies of your staff (which is your particular situation again) that needs to execute. These statements are all too easy without actually looking at the details
Let me save your precious time: the whole 40 minutes is just "determine where you are, take small steps, evaluate, repeat." .....That is all! . . Even better, if you are a control engineer, agile/agility or whatever it's called is a feedback loop. That is all.
The complexity lies in your own implementation. The devil is in the detail. Each team is different and trying to follow a set of rules laid out by a book is dangerous.
FableBlaze There is no so call "*standard* textbook rules" of Agile. If there were, this talk wouldn't have been necessary, and wouldn't have happened in the first place.
More isn't necessarily more complex, in this case more subtle - many people understand feedback loops in one compartment of their minds, and then fail to apply them to control problems they understand on a lower plane in another compartment in their mind. This point can take a few years to pound into someone's head, I've been trying for years and I still constantly stumble =)
In 2009 I said that they make agile into new waterfall. So I started to avoid jobs which had mandatory PM with all agile tools under his belt. I wasn't disappointed with my decision in the long run.
Agile kills creativity in developer.Most of the managers think using JIRA is true implementation of agile and ninety percent of managers do not consider estimating the efforts for development.
Love this , This is 2023 and it is still true to this day I think this needs to be spread for everyone I guess Agile is definitely dead Agility and is not and should not
"It's time to reclaim agility". He's still fully behind the (4) values as expressed in the manifesto for agile software development. Through our ever-evolving practices we can live up to these values. He even says that the ideas of Scrum are quite powerful. However, he resents the idea of going to a 2-day Scrum course and then considering yourself a certified Scrum master. So not: "stop thinking and get certified". 'Agile' has turned into a cargo cult. Rather keep thinking for yourself, being inspired by others' experiences and always being aware of the unique context of you and your team. So, no excuse to not trying to "uncover[ing] better ways of developing software by doing it and helping others do it".
If you read the books out now, reading stories is the way to learn application. Jeff Mckenna is an amazing teacher and his ability to tell stories and give us real time simulation exercises was effective. I agree. 2 day course, take test and you are certified, makes it feel like what PADI certification is to scuba divers. The key is to self educate and apply any story that seems to resonate with your team dynamic. I always use the analogy that SCRUM is like a style of martial arts; not martial arts as a whole. In other words, it has its limitations like any other art form. They teach that too. Scrum does not work in every case or all companies. It focuses on the smaller local teams. However, some writers have been working on scaling it up.
How many developers have been saying this for years? I've been marched out of a handful of job interviews for saying it, and I'm sure I'm not the only one.
You thought a job interview was the perfect time to argue semantics on Agile/SCRUM/Waterfall methodology, enough to the point that you were marched out of a handful of them? That makes no sense.
I like this speech. In the current IT world, people use the word too much without understanding the real meaning of the word. Lots of things are twisted in IT industry. We need people like Dave to clarify it.
IMO there are three books worth reading about development -- The Mythical Man-Month, PeopleWare, and The Dilbert Management Book. The rest are guides to controlling developers with their own manufactured consent.
Agile is the future of work. Human and organizational development models are clear about what works and where we are headed. Reducing levels of management and empowering the people doing the work is much more productive and profitable.
That's all I got out of this. Jesus... being a collection of letters doesn't kill anything. This is just a narrow minded person being pedantic about the meaning attached to an existing word. We do this all the time. There's nothing fluffy or vapor about anything "cloud" but that doesn't make it dead; and it's not alive because it's a noun.
Nope, it's not, but "agile programming" is a noun phrase. Now, whether *anything* that is signified by a noun phrase can have the property of life or death is another question entirely. I am with you though... I hate this linguistic tongue-fuckery.
This is one of the very best lecturers that I've ever heard on the subject of IT. I may do a response video or write to the speaker to thank him. It's outstanding. I would offer one small criticism, however. Now, this is a personal opinion but I happen to think that the phrase 'Agile' is basically a toxic phrase. By the way, I agree with every word the speaker said about how it has been commercialised, turned into a noun etc. If you accept my proposition that the phrase 'Agile' is now toxic then having people clinging to the phrase (perhaps in a subtle and considered way) isn't really going to help. There are several videos on RUclips with people talking about how Agile is dead/finished/rubbish/whatever and ALL of them come with the caviat (along the lines of) "we need to back to the REAL Agile... the good stuff". I think that's a mistake. I think we should declare failure with the whole thing and go the totally opposite direction. I'd like to see the Agile movement go up in smoke. However, in order to do that, I don't think that we can afford to play with semantics. Regardless of how well intentioned, brilliant and well thought out the manifesto was - we should be dropping the phrase completely. I have SO MUCH MORE to say about this but I think I should really make a video. It's a huge topic. Anyway, thank you. Great video. Really great. I loved it!
I agree. I remember a discussion on "good money" that got co-opted by Ron Paul. The claim of the article was that money should be named after its underlying metal weight; this would avoid people forgetting that the money is (or was) tied to metal. I responded at the time and pointed out the British "pound". It doesn't matter what name you use for something, eventually it will become a thing of its own; completely divorced from its original word usage. (I'm sure there is some lesson from the old field of "semantics" in there)
This talk is insightful today. More corporate has adopted Biz-Word like "New Normal", "Leapfrog" and they are actually proper nouns. They want to see this, but they do not know how to leapfrog. Suddenly "Agile" becomes the method to adopt "New Normal" and "Leapfrog". If your company cannot Agile, your company cannot Leapfrog and cannot adopt New Normal. The threat becomes existential this month. So the question is not whether Agile can be Scaled. Instead, it becomes "You must scale up the Agile". Edit: There is still no Agility in 2020.
I absolutely love this guy :) We can discuss if there is such a thing as Agile ( since the use of a word dictate language) but the kind of fluff we have to live with in order to satisfy our employers are ridiculous.
Regarding what he says at 19:54 "The benefit of tests comes from the design aspects. The fact that it helps me understand the design of my code. It helps me understand the design of my code, and the interfaces of my code. It helps me decouple my code. And I've been doing it for so long that now I think about that as I'm coding, and the test doesn't have to exist" All the reasons mentioned for not writing tests are benefits to himself. All that he says assumes that he is the only one doing the coding. But usually, software development is not a solo-sport. It's a team sport. You're not building for yourself. You're building for customers. And even if you're the only one writing code, you won't remember what and why you wrote when you look at your code 5 years later. If you're working on a hobby project, that's fine. But if you're building software that you want others to be able to contribute to, or people to pay for it- Please write tests. - A software developer ( who also doesn't usually write tests but not very proud of it )
Amazing. I have been realizing for a while that the "you go do that!" books / lectures / etc were out of context and delusional. Best Project Management lecture I ever watched.
Thanks Dave. I saw the title of the video by accident and couldn't resist not watching as it confirmed my thoughts on the subject. As a developer and tester I am fed up with all these 'hybrid' agile projects. I wasn't familiar with the SAFE diagram - they don't teach me anything and every organisation has it's own agile flavour. I didn't know I had to laugh or cry. So we started with 4 general principles + 12 easy rules and we end up with a complete BS industry(yeah, scrum master in a day) including organisational algorithms. Where I actually learned to be(have) agile in teams: army and squatting. Such self-managing teams rock: This is your target, these are your means, solve it as a team. Go!
+cannotwest you gave me the best laughter of the year. Anyhow, I love the presentation especially the bit about telling others how to live is not cool.
Ha ha - yes - as soon as I noticed it I thought it looked kind of metaphoric - I like what he is saying though - AND - is walking around in his socks - which is cool
But does.that mean that the golden rule requires to to know everything about the situation before acting? And what about masochists? In a way, the golden rule is a kind of imperialism, saying that what I need iws what you need... Just debating here :) @@traviswatson6527
Probably an unpopular opinion here, but I believe Agile methods in their most basic concepts (ie. small steps, go for flexibility) make sense, but Scrum is little more than marketing BS to me. Why 2 weeks? Why lack the flexibility to break a task into multiple sprints? Why anything? All of these BS rules were pulled out of a hat and there's little rhyme or reason to any of it other than "Google does it" - it's comical. I'm involved with complex video algorithms for device drivers - sometimes shit takes longer than a sprint. Sometimes we find HW bugs and it takes a month to resolve! Sometimes I have a 1 week task and everything else in the backlog is 2 weeks+? It's a joke. Agile isn't agile enough to account for ANY of this. It's not agile enough to handle something crossing a sprint boundary - it's not agile at all....AT ALL....
MrSlowestD16 But the whole point of Agile is to *not* be a slave to your process. If someone is telling you that work cannot cross sprint boundaries, they have a fundamental misunderstanding of the point of -- and the motivation for -- Agile.
Google actually doesn't do it (doesn't enforce it). Teams have flexibility on which agile (or otherwise) methodology they adopt. (according to a dev friend at G).
I always said that most software projects are large and complex. They take as much time as they take, like running a marathon. And you can't run a marathon in a series of short sprints!
Great speech! I completely agree with the philosophy here. Many people are religious about stuff and just want to be cool not even questioning what they are doing and how different methodologies applies to different domains
Analogy on the short message of the Agile Manifesto: Don't take the Jeep to arrive from A to unknown B. The safest way is to tiptoe on foot with maximum effort on reassuring your goal every step. I say this is backwards thinking. You should go with predetermined well throden roads with the jeep. Then step out and swim if you hit the lake.
It's now dark and all you know is that there may be roads and there may be lakes. The jeep=like thing you have has a candle. Better tiptoe or drive real slow. If water, go back a bit.
The problem is that in most projects everyone is blind and unknown B can be thousands of kilometers away. Trying to find it can lead you to China, when you were actually meant to go to Europe.
@@carlosjosejimenezbermudez9255 The analogy was already questionable and you've taken it to the next level. Back to the original problem, agility is best when the 'mission' itself is defined in other terms than simply a well-defined product that needs to be made. This is where all these 'make the thing and no fuss' people go wrong. If your mission is to create as much value as possible for your company, then there is no 'you meant to' in the sense you're trying to push.
Good talk by one of the creators of the Manifesto of Agile Software Development. I like that he gives a history lesson of what development was like under Waterfall and the reason the Manifest was created. I like the fact that he boils 'Agile' down to its basic core. Scrum, Kanban, XP, etc are all forms of writing software with agility, but it's not a one size fit all concept. Change is the constant in software, it's why it's software and not hardware, and adapting to change is the whole point. Changing your process to adapt to situations is good too.
"Agile" has never worked for designers or anyone that likes to know what are they building. Designing in small steps is like driving in a pitch dark. No vision, no architecture, agile is good for very small teams, not sure what product they are doing. The industry created around agile is really disgusting too, and i always despised those agile experts that come with the confidence they know better whats good or bad for our team and product, just because they are certified or "they have been doing it for years". They do not even bother spending time learning about the particular problems we are solving or know the people in the team... they just come and start trying to fit the team in to The Methodology! Setup repeating meeting, waste everyones's time, arrive with useless velocity graphs that tells nothing about the amount or quality of the work done, kill features that will "take too long" to fit in one release.. There must be a better way to build products, and agility is only part of the answer, not the whole story.
Agreed and even for relatively prosaic tools which are not about a grand vision. Recently I've been working on a backoffice tool for someone at our company who has to curate the semantic connections between tags for our profile matching engine. The existing tool and internals turned out to be frustrating and buggy enough that he has turned to a frustrating but at least stable massive spreadsheet. The agile way would suggest that I should drip out all the smaller improvements and bug fixes I've been making and get his feedback on each iteration. But this would be the wrong thing to do. It's not a matter of taste to prefer not having critical bugs and purposeless functionality restrictions. Until it gets past a certain threshold we have already agreed it won't be an MVP because it's not viable otherwise. If there were no alternative it would be but currently there's still a spreadsheet to beat (one that I can't import until a lot of this work is done anyway). One might object "ok but after MVP is when you do small iterations" but I'd argue that the product doesn't just reach that magic stage early on and never return. Many significant features and modules will need to reach an MVP standard and that this might be most of the dev time. Hopefully it will, in fact, because the rest of the time will mostly be for bugs and chores - both things you don't want much of. There's no point losing the trust of users by repeatedly delivering way less than what they asked for and hoping they suddenly change their mind. This job has involved the near rewriting of 4 interconnected microservices and has taken a good few weeks while attending to other work. It's not agile and it's not visionary design. It's just a big bit of work that needs to be done.
"agile experts that come with the confidence they know better whats good or bad for our team and product, just because they are certified or "they have been doing it for years". They do not even bother spending time learning about the particular problems we are solving or know the people in the team... they just come and start trying to fit the team in to The Methodology! Setup repeating meeting, waste everyones's time, arrive with useless velocity graphs that tells nothing about the amount or quality of the work done" TOTALLY AGREE
Totally agree... Its funny that the experts always justify it by telling the story of how it was a invented by a Toyota manufacturing plant... But they don't have the perspective to realize that production line teams couldn't be more different than development teams, both in what they do and how best to go about doing it.
"Agile" has never worked for designers or anyone that likes to know what are they building." LOL so true :P There was a time when we had well defined requirements for what we were building because there was an analysis phase in which people actually had to think what they wanted BEFOREHAND. Ahh those were the times. And i also strongly despise the industry of snake oil sellers (and buyers!) that has grown around it.
Great Talk, thank you. Some aspects apply to so many things, nowadays, not only "Agile". There are so many terms misused for marketing and sellout purposes...
THIS! I was about to post the same thing. Yeah Agile was dead the day it was pitched to jackasses as the solution to everything. And then they got guys like this guy "I don't test" - yep I wanna hire him. And I want my effing 39:00 minutes back.
I find it interesting, that both in the PID algorithm and in "life", is that he basically describing the calculus, presently the best formal presentation of that process. Korzybski would be proud. :)
I had no idea Bones died in '99. God he was amazing in Star Trek. And he also really didn't look as old as he apparently was. Shocked me to find out he was born in 1920. Dee was great. Bless his soul. Also, Have you seen William Shatner? He still looks fairly young considering his age. He still looks like he could captain a starship no issue.
Best practice is related to putting the sharp end into the dirt (not into your foot). Here's a certification proving that all wielders of this shovel are unlikely to put it into their own foot. (Note that the sellers of the shovel are indemnified from any damage, loss of limb, property, or any other incidents related to misuse of this shovel)
Agree with most except: design to make changes easier. Design to make it simple and understandable. For the sake of changeability, people tend to put abstractions, interfaces everywhere which kills readability.
Took training at a large health care company on "agile", this is the diagram of team of teams, train of trains, etc (@22:52) which the trainers preached. It was such a culture of language and verbiage play that I did not find it at all useful. Now, I use agile and its thinking everyday and find that to be very useful...but not the convoluted training that I have been experiencing at companies. I generally advise teams on "agilesque" ideas which fit a particular circumstance. I like the ideas of daily scrum, sprints, show and tell feedback loops. I am not sure where I stand on testing though. Anyway, thanks for the talk...I feel vindicated :)
*Timecodes*
03:00 UML
06:20 Creation of The -Agile Manifesto
10:45 _Agile_ is not a noun
18:00 On testing
21:10 Stop Thinking & Get Certified Today
23:00 It is time to reclaim Agility
24:50 The PID Algorithm
35:00 Agile is not what you do. Agility is how you do it.
37:55 Questions
It is not time codes it is timestamp
But anyway thanks
I would like to buy this guy a beer. In every organization where anyone questioned why we were using Agile, it always came down to, "Give it a chance." Almost everyone in the room had already given it lots of chances, and few of us had ever seen any payoff from all those meetings. Agile was mostly a career stepping stone for people with little or no technical experience to work their way toward IT management.
Well said!
I agree
For real. They like to take the credit from the work done by devs without actually helping in any sense
weird. every agile team I worked with has been a great experience and a success for the product. Whats your real problem?
In some cases management will think it's the team members problem and will add more consultants to help the team, instead of listening to the team that it just doesn't work for them
Finally someone has the courage to stand up and say that results matter, methodology does not.
He doesn't need courage. He is one THE pragmatic programmers. When he talks, people hear.
It's a cult
I am going to tell what is really wrong with Agile : it is not being used to help make better software or make the users happier. It is being used as a worker management tool, and as an avenue for promotion for non-technical people. "I am the Scrum Master, I am Agile Certified". It is an instrument of government bureaucracy which is helping only those who are administering it, training in it, and for the self-promotional types of people who just want to be paid to show up in pointy shoes and demand a leadership role..
Today on LinkedIn I saw a post "Is Agile dead?", which reminded me of this video. 8 years later the question still stands. Agile, unfortunatelly, too.
Agile IS Dead... Agility still stands and continues
The true measure of humor is the amount of truth it contains. The Dave Thomas analysis of Agile had me in fits. Finally he who dares to seek the truth, wins.
I honestly reference this talk every job I've gone to. And has been a key voice in shaping my own approach to software. Love the humour and the pragmatism
"When faced with two of more alternatives that deliver roughly the same value, take the path that makes future change easier."
Such an amazing talk. I totally agree with this. So many people buy into Agile Inc. I never understood why... It makes much more sense to have autonomous thinking developers who are willing to investigate, experiment and 'move' in a way in which they can progress in an iterative matter. The current state of how Agile Inc is integrated into businesses, causes more harm than good, in my opinion.
One of the things I liked about the last place I worked at was that it was a blended process, yeah we had cards to be done (tasks.) Two week releease windows, etc.. But the process was simple, we'd look at the list at the beginning of the period, pick what we each wanted to work on and guess how long it would take. Each day we just said how we where progressing, no pushback, etc, just say the truth. If you finished and it was tested and published you moved onto another card of your choice in the list. You repeated this until as many features/bug fixes as possible where ready for the next release. The best part was you had no-one screaming down you neck, you wrote it how you wanted to, there where design standards to follow but the important implementation side was your creativity. That company was MSX International.
Everything summed up perfectly starting at 33:52
Exactly. Good point 👍
Well done that man!
Thank you.
"The values have been lost behind the implementation." Culture, values and principles inform our decisions and drive our actions. If you want a movement to succeed, the leaders must be relentless guardians of the culture.
I loved the reference to "Are we doing it right" 16:11. I heard this in a standup a while back and knew immediately that the team had lost it's way. The answer to that question should be, "Are you getting the result you want?". If not then all the "Doing it right" will not result in any value being delivered. The team was doing a lot right, and getting very little done.
"Stop thinking and get certified today!", that gets me everytime LOL
@OldPossum IMHO they can easily help someone get a job, or to specialize in some platform. Like a mongo-university dev certification, or an oracle dba one.
Certs shoun't be compared to a full university degree. But using them to have a background of some sort for a couple of years until experience is gained, is perfectly valid
@OldPossum This is one of the silliest things I've heard, they all have their value. Sure, a single certification is nothing compared to a single degree... but one takes a month or two to get, and the other takes 4 years. They are very practical for 1) telling others you have skills in a certain tool, or specific area 2) gently push your career in a direction you're trying to move in. I just earned my masters in computer engineering last summer, and I'm keeping up with certs to still appeal to recruiters.
About your WinNT 4 sysadmin cert comment.... Anyone here who graduated in 1996, their specific degree is just as useless today as is that cert. You get a degree to get a job, and over time your experience at your job(s) replaces and exceeds the value your degree ever had. The same thing for any certification. It's a small jump to get you where you need to go, it's not going to carry you for the rest of your life.
This is a fantastic video! As systems theorist, I very much appreciate the reminder that we ought to understand the underlying principles and purposes and build a practice from there rather than approaching it the other way around. Thank you for this!
Superbe conférence sur la _méthodologie agile_ par un des auteurs du manifeste du même nom.
Retour aux fondamentaux:
1. Déterminer où l'on en est
2. Avancer d'une étape
3. Tirer les enseignements de 2
4. Recommencer.
Face à deux options amenant au même résultat, privilégier celle qui offre le plus d'ouvertures.
Great talk. Agility is the spirituality and Scrum, Kanban, etc are the religions promising to bring spirituality to the masses. Just like any religion, it didn't work out since only rituals remains and the spirit is lost.
Wow, very edgy
The methodolgy industry has been on the go for years. Either an experienced guy formalises what worked well for them or a bunch of academics dream up a very fine set of names and diagram formats to differentiate common concepts and techniques. Each one is seen as the silver bullet so at last we can offer our bosses, Quick,Good and Cheap instead of pick any two from these three. Training courses are done cv's massaged and it's all trashed the following year by the new shiny thing....
As always the best advice is the shortest. small steps and don't paint yourself into a corner. I'd also add; hire and develop good people.
@@TheHolym4n no, that sounds expensive
Great talk!
What I understand is is that whatever the methodology used, it must be adapted to our context and not the opposite.
that's the point
Mustapha, yes. But keep in mind: You change the context, and with that context comes new problems based upon that context. Similarly, you change the methodology, and you end up back where you started. We are no more productive today with agile/scrum/xp than before. We're just finding new ways of expressing the same old thing. And perhaps there never was any problem to solve in the first place.
Hes sayng that the whole idea was misunderstood from the begining and hes actualy giving a new definition, simplifiying it to the fact that being Agile means to adapt to changes, like the two wheel robot that maintains equilibrium constantly reacting to the forces that afects it on every moment.
christian galicia, sure ok, but "adapting to changes" didn't suddenly show up with agile. It's not as if the lone wolf way of programming in the 80's had no way of adapting. Being able to adapt is simply a function of hiring the right people, just as it's always been. Seriously, every few years coming up with "hey this way of thinking is new" is not new. All the same development problems from the dawn of time are there, they're just given new names. And by the way, "extreme programming" is a perfect example of this.
I understand your point, however don't completely agree with you. I dont think that is 'simply a function of hiring the right people'. Adapting its more than that, its a matter of doing what needs to be done in every moment. Adapting its about constantly monitoring the state of a project.
You cant reduce that to Hiring the right people.
On any case i would ask you, what does that right people the you hire do to adapt?
What arouse with Agile, was the realization that it was not a matter of having fixed plans, but a matter of being flexible enough to change the plans on the way in order to adapt to every moment until the project is properly landed at the right moment with the right specs.
Yes All the same development problems from the dawn of time are there, however the solution to those problems have evolved in new methodologies.
I read the comments and I come to the conclusion that most of you don't really know what Agile is.
You don't "use" Agile, you are Agile or not. It's not what you do, it's how you do it.
99% of the companies who put themselves the Agile label are not Agile. Usually the ones complaining about Agile are those who don't understand it (and it's quite simple, really, just read the manifesto) or those who despise collaboration and change.
If you believe in hierarchical delivery teams, you like giving orders, long term detailed plans and having software engineers not questioning things, please do us a favor and don't even try to become Agile because you'll either fail or lie about how you're doing things.
I have confidently turned around projects using Agile and Scrum.
I ask a few questions to myself:
1: Can everyone in my team articulate an overall picture of the new business dynamics?-A well fantasized and elaborate mental image of how the new business will be done by different roles and that too in diverse situations?
Does my team know it, think about it, creatively embrace it, passionately define it and only then put it in the sprints? Do we plan only these types of stories and sprints? Agile is NOT a magic tool, it is how we use it.
(Not to just develop a feature- NOT to merely improve a process - NOT to demo a cool functionality).
2: Do we have a well developed test scenario for every story ?
(not automated but a test that captures comprehensive business dynamics & IT management.
e.g. just a "Sign On" feature means different thing for a VP logging in from the airport VS. a docking supervisor in bitter cold of morning shift or a sales employee "logging in" from a client site.
For IT dev team - a DBA thinks of "Sign On" differently than a Security or a mobile app developer or API programmer or a Cloud performance guy. A comprehensive tribal knowledge about each other's contributions can be achieved only thru daily cross teaching called stand ups. NOT any rambling about what I didn't do.
There are several such energetic impulses we need to bring in the team- That's Agile for me.
Connect with me to turn around your Agile teams instead of complaining.
tonydesai10@gmail.com
sorry but it's just a bunch of bullshit buzzwords that mean nothing.
19:50 - With respect, he's missing the second important function of tests: it enables subsequent refactoring and evolution. There's no such thing as code that's so well-designed that it can't be broken by a subsequent change. Unless you're a loner who writes perfect code on the first try, you need to be writing tests.
24:30 - Code with no tests is harder to change.
My philosophy is that every part of your software's surface area exposed to users will be tested. The only choice we have is whether we test it as developers, or leave it to our customers to test. I can promise you that the latter is the worst case scenario in about 18 different ways.
Absolutely agree. Even if you don't care about refactoring and are OK with poorly designed code, you need to keep track of upstreams *at least* because of all the CVEs coming out every day, and you can't upgrade safely without good test coverage.
It's also all the other underlying stuff (OSes, frameworks, etc.) thats constantly changing, i.e. even if your code doesn't evolve the support structures are evolving all the time with updates/security fixes/and so on
@@EvgeniyDolzhenko languages deprecate functions, so what ran in one version, might not work in a future version of the same language. Libraries change, database software changes, and backwards compatibility may not be a priority. I work with some websites that had a perfectly fine working form processor, but some of the functions they used in php 5, are deprecated in php 7, and just no longer there in php 8.
@@javabeanz8549 that's called maintenance costs. You don't expect you plumbing for example working forever after being installed.
One corruption I've seen in the real world is that when multiple options are available, real world teams tend to choose the path that requires the least amount of effort instead of the path that makes things easier to change in the future.
Some times that is the rational choice AGILE prioritises SPEED over things like that.
Makes sense in a speculative business environment where the code base will be thrown away anyway. Bad quality, no long-term vision, a lot of focus on badly implemented features
It's because the time pressure is very common and code quality usually sacrificed in favor of deadlines.
"Courage is the most important of all the virtues, because without courage you can't practice any other virtue consistently." -Maya Angelou
Software development culture all too often turns new and shiny paradigms into sacred scripture. Good to see someone countering this tendency.
Best practice... we're all looking for the cheat codes to making implementation of complex systems easier. The real secret sauce is practice implementing complex systems. Try explaining that to the business analysts during your multi-sprint planning sessions.
Amazing talk! But this was 2015 and I'm typing this in 2021. Working in this industry I wonder: did people not listen, or were they not brave enough?
this is a question that assumes that the whole industry have watched this conference since
It's 2022 and I ask you what are you doing to stop this madness
2015: "Agile is dead"
2019: Agile still everywhere
It's difficult to clean up that much shit.
@Inareth I found little point of Agile so far. Sure I get tickets with bugs to fix, but where's the novelty in that?
@Inareth Why are you assuming nobody else watched the video?
I tried to convince my managers and co-workers for the past 2 years that Agile will destroy our system at work but no one listens. I'm just the "crazy" analyst.
@Inareth You're getting something out of my comment that I never put into it.
In my last project I tried make it work for everybody. Tried include them all in my code and I lost the deadline and my health.
I never felt so depressed doing the fuck same thing I always did with glory before. Be yourself and don't let the rulers kill their self bring you together. Always do what is real better for you if you know what is the best. Don't waste your time arguing with them
"We're Agile" is what business stakeholders claim for not thinking about what they want and when.
I like his philosophy and the entire talk. Very engaging presenter with a gift for telling stories
Dave Thomas is a treasure.
Agile is so project managers look like they're doing something.
@@JoeGilson1 this was the weirdest part of working on many "agile" teams over the past 10 years... just about any stupid trivial thing that could obviously be done in 15min or less, would become "2 sprints of work" involving 5 people... but of course at a software consulting company, that's a feature not a bug lol
uhm... agile excludes project managers altogether
@@miks8 not in the real world
Peppermint They just changed the name to be scrum master, same kind of thing
@@PplsChampion thats why Im very keen on distributing certain tasks, code review oke, but he can work on a and she can work on b. We (team/stakeholders) all know a and b are the most important, lets just do it. Not to much time breaking things down to far to be able (or pretending) to predict when and when it will be delivered. Own your shit, find a way of working that the team likes, but make sure you keep delivering to your stakeholders. Simple as that.
What an absolutely amazing talk!
I hate Agile, the people who turned it into a brand and religion, the people who sell it, the people who assume it's the secret to efficiency, and the people who keep saying "we're dedicated to being Agile" as though the incantation wards off the bugs. Every company I've ever been at had really good programmers who used to be very productive, were forced into the religion, and whose happiness and productivity plummeted at the same time as dead weight found a new purpose in the organization, until it all collapsed.
Take my virtual hug, my brother. I wish that you heal from your (deep) wounds quickly and fully.
First ad: "can learning Agile help you ...?"
Nice one, Udemy.
Agile is an adjective... 11:30 and the author hates it when people use it as a noun...
The the title of the talk "Agile is dead". Good job.
@@Fool1929 Isn't dead an adjective?
This basic definition and method of achieving agility is true of every aspect of life. This is not just programming knowledge; this is a life lesson.
If you don't have the time to watch the entire presentation, here's the essence: starting at 33:45.
Thanks for posting this conference. It was a real pleasure to listen to Dave Thomas.
Except from being a very interesting talk about agile programming, you can learn a lot about how to make a great presentation!
Agree, but I still think Uncle Bob is in a different league
Hey, I see that some one disagree with this talk. I remember my university time when I were thinking how does people know about that. And that impression that everyone is on the same page except You. I remember UML courses and still not a big fan... thanks for clarifying one of my hypothesis, I can sleep a little better tonight. Then once again :D there's no rest for the wicked :D This talk is exactly what I want to hear like candy for may ears and soul and back there somewhere inside hidden a nasty thought that this could be a trap... I'll not continue, maybe just a bit of paranoia. I can agree with one thing 100% that this software development, it doesn't mater how we call it, should be creative and experimental.
I got an ad for Agile programming courses after the video finished and laughed so damn hard.
As an Architect, some of the worse solutions and I have seen were done Agile. Works for small projects and helps reduce risk of consultancies (get paid and run away!)
I like Agile but very disappointed on the success rate.
Agile does some things well, and other things abysmally. What it fails at is *design* and *user* satisfaction. What it succeeds in is creating a whole-team development culture. Its chief sins are (a) the substitution of "use cases" for a formal design [and this one is fatal over the long term], (b) the permission to write development "speed bumps" off as "technical debt" [that sometimes never gets resolved], and (c) continuous integration. _"Now wait,"_ you ask, _"how can CI be bad?"_ It's bad because, if there are multiple versions available, all of those multiple versions will be run by the user population, and troubleshooting those will be difficult. Of course, the advice is "upgrade to the most current", but that's kind of like a help desk that says "reboot Windows" whenever you have a problem -- not satisfactory in a large number of cases.
Managers and investors love Agile: the product goes out the door generally on time and under budget. But *what's going out the door?* Quality? Something you'd be proud to have wear your brand? I think generally not. The adoption of Agile cannot be a 100% policy; it fails badly for large projects. Sadly, small projects do not represent a majority of the software available in the market today.
The Agile Manifesto has to be the most violated set of guidelines on the planet. What I'm seeing in the commercial arena is that micromanagement is being mixed with "digital transformation" in the name of Agile, yielding a brand new, unheard of, and in many cases unexplainable way of reporting on your work status, and yes, even "enhancing" the toolset a developer uses to give management "dashboards" on where they think any project is. *This is not the way developers work, nor the way they want to work.*
Agree with you, @musmanakram -- Agile is not beneficial. I'm sorry, software isn't cheap unless you write it yourself ... and even then, it still takes time, cash, knowledge, and effort.
@@8a41jt Great points. As I've watched the firm I work for transition (painfully) from waterfall to Agile over the past several years I've noticed that there probably isn't a single person in the firm that truly understands what it is and entails, and probably not any two people in the firm that could give you the same definition for it. It's vastly misunderstood among groups of people that hear the term and know it's something that management wants them to do, but they don't really have any idea on how to do it.
It's a complete and utter mess when you have an organization full of people that hear buzzwords if only to repeat them whilst never researching the actual meanings of any new terms (Agile is old of course, but still), and there is no proper training given to GET people all on the same page and understanding what it means (nor any Agile coaches or experienced scrum masters brought in from the outside). Absolute chaos.
Aside from all of that, even if everyone at the firm DID truly get it and were all on the same page, it would still suffer from the fallacies you mentioned. It reminds me of something one of my teachers said before about communism. "It looks great on paper but doesn't actually work that well in real life." I feel the exact same way about Agile. Some people can sell the sizzle of it, sure, but I have yet to see ANY team where I work utilize it effectively to achieve a desired result - not once. I think much like communism (or any methodology really), humans are the problem. A group of people will get together and jack something up real good much more often than they will cooperate efficiently to get the goal accomplished.
Now for the worst part...I've seen where people use the general confusion around Agile to basically shirk out of doing their jobs. For an Agile team to work, EVERYONE needs to be on point and cooperating fully. I was on a team where the business guy refused to give any details regarding User Stories. The stories would basically be one liners with no Acceptance Criteria. The team kept asking him for more details because literally, the ask was never clear. He kept harping on about how Agile means "the team" needs to get together and come up with the AC's. That's great, but "the team" still needs enough details to even get off the ground at all. He basically just didn't want to do his job and he fought voraciously to not have to write Acceptance Criteria.
Then on the same team we had a tester that would sandbag all sprint leaving tons of work undone on the last day and then call in sick on that day. THIS guy said the word "team" more than anyone, when in fact, HE was the one not being a team player.
If you couple all of that mess with the fact that to truly deliver with the rapidity that Agile has made management think deployments should happen, automated testing must be top notch - and it never is. Projects are started for existing applications for which there is little to no automated testing yet in place, dev runs as fast as they can to deliver by the right dates, testing falls by the wayside, and when the project is "done", it goes out the door with HORRID quality. The pace is just too fast for most groups of humans to keep up with when it comes to updating legacy applications or creating new apps altogether. That project I was on with the lame testers and business dude....the entire thing failed, was scrapped, and $12M went down the drain. Why? Because Agile isn't that great to begin with, and humans turned it into an absolute circus.
Talk too much that is why need agile
The reason is that PMs are running "Agile" now. It was originally created by technical guys. Now it is project management. Thats why the Software Craftsmenship Guys came into existance. If you actually do the XP practises very well than the "project management" parts of the agile world (like scrum) can help you get more done. But if you don't do the basics right, you just produce "double the shit in half the time".
It's used on Microsoft windows teams, which isn't a small project. Again as the presentation also said, you have to make the process fit for your particular situation. Next to that, you have to deal with the competencies of your staff (which is your particular situation again) that needs to execute. These statements are all too easy without actually looking at the details
Let me save your precious time: the whole 40 minutes is just "determine where you are, take small steps, evaluate, repeat." .....That is all!
.
.
Even better, if you are a control engineer, agile/agility or whatever it's called is a feedback loop. That is all.
No, I'm afraid it's a lot more than that.
Hexagonaal To him it is. He's voiced so strongly against over complicating agile. That's the gist anyway of his talk.
The complexity lies in your own implementation. The devil is in the detail. Each team is different and trying to follow a set of rules laid out by a book is dangerous.
FableBlaze There is no so call "*standard* textbook rules" of Agile. If there were, this talk wouldn't have been necessary, and wouldn't have happened in the first place.
More isn't necessarily more complex, in this case more subtle - many people understand feedback loops in one compartment of their minds, and then fail to apply them to control problems they understand on a lower plane in another compartment in their mind. This point can take a few years to pound into someone's head, I've been trying for years and I still constantly stumble =)
In 2009 I said that they make agile into new waterfall. So I started to avoid jobs which had mandatory PM with all agile tools under his belt. I wasn't disappointed with my decision in the long run.
Agile kills creativity in developer.Most of the managers think using JIRA is true implementation of agile and ninety percent of managers do not consider estimating the efforts for development.
I swear we spend more time estimating projects than we do actually implementing them; that coupled with an open office design minimizes productivity
That's not agile killing creativity, that's management killing creativity. Which I think is probably in their employment contracts.
Love this ,
This is 2023 and it is still true to this day
I think this needs to be spread for everyone
I guess Agile is definitely dead
Agility and is not and should not
"It's time to reclaim agility". He's still fully behind the (4) values as expressed in the manifesto for agile software development. Through our ever-evolving practices we can live up to these values. He even says that the ideas of Scrum are quite powerful. However, he resents the idea of going to a 2-day Scrum course and then considering yourself a certified Scrum master. So not: "stop thinking and get certified". 'Agile' has turned into a cargo cult. Rather keep thinking for yourself, being inspired by others' experiences and always being aware of the unique context of you and your team.
So, no excuse to not trying to "uncover[ing] better ways of developing software by doing it and helping others do it".
If you read the books out now, reading stories is the way to learn application. Jeff Mckenna is an amazing teacher and his ability to tell stories and give us real time simulation exercises was effective. I agree. 2 day course, take test and you are certified, makes it feel like what PADI certification is to scuba divers. The key is to self educate and apply any story that seems to resonate with your team dynamic. I always use the analogy that SCRUM is like a style of martial arts; not martial arts as a whole. In other words, it has its limitations like any other art form. They teach that too. Scrum does not work in every case or all companies. It focuses on the smaller local teams. However, some writers have been working on scaling it up.
How many developers have been saying this for years? I've been marched out of a handful of job interviews for saying it, and I'm sure I'm not the only one.
You thought a job interview was the perfect time to argue semantics on Agile/SCRUM/Waterfall methodology, enough to the point that you were marched out of a handful of them? That makes no sense.
Same here. I was told that I will not be a cultural fit
Happy to see there are still people that have a functional brain.
I was beginning to think I was the only one.
We're many
Structured Programming is still the best.
Amazing talk. Thank you Dave 😊
This helped me in more than just programming. Thanks
I like this speech. In the current IT world, people use the word too much without understanding the real meaning of the word. Lots of things are twisted in IT industry. We need people like Dave to clarify it.
This guy is my new hero.
BG J
This man demonstrate that young doesn't mean new and that "agile" doesn't mean innovation. Keep up the good work, Sir.
IMO there are three books worth reading about development -- The Mythical Man-Month, PeopleWare, and The Dilbert Management Book. The rest are guides to controlling developers with their own manufactured consent.
There is one absolute rule that is totally immutable - Be excellent to each other
Party on, dude
"You wouldn't sell green, that would make no sense..."
umm...
Said in a Conference held in Amsterdam.
@@charalamboskyriakou840 kakakaka i though exactly this
you're thinking about a noun again
Agile is the future of work. Human and organizational development models are clear about what works and where we are headed. Reducing levels of management and empowering the people doing the work is much more productive and profitable.
Yes, and the communism will save the human race.
It's an irony, in the case you don't catch it.
Agile is micromanaging. It is massive management over head
"Agile is dead".
...."Agile... is not a noun!"
lol well played
That's all I got out of this. Jesus... being a collection of letters doesn't kill anything. This is just a narrow minded person being pedantic about the meaning attached to an existing word. We do this all the time. There's nothing fluffy or vapor about anything "cloud" but that doesn't make it dead; and it's not alive because it's a noun.
Nope, it's not, but "agile programming" is a noun phrase. Now, whether *anything* that is signified by a noun phrase can have the property of life or death is another question entirely.
I am with you though... I hate this linguistic tongue-fuckery.
Better: Agile or not agile.But again not all animals are created agile and doesn't necessarily need to be
Breathtaking talk
Some people talk , others deliver.
This is a really mindful philosophy to have - not just for programming, but for most or all of life.
"All rules are contextual!" Couldn't have said it better.
It's Fantastic!
This is one of the very best lecturers that I've ever heard on the subject of IT. I may do a response video or write to the speaker to thank him. It's outstanding. I would offer one small criticism, however. Now, this is a personal opinion but I happen to think that the phrase 'Agile' is basically a toxic phrase. By the way, I agree with every word the speaker said about how it has been commercialised, turned into a noun etc.
If you accept my proposition that the phrase 'Agile' is now toxic then having people clinging to the phrase (perhaps in a subtle and considered way) isn't really going to help. There are several videos on RUclips with people talking about how Agile is dead/finished/rubbish/whatever and ALL of them come with the caviat (along the lines of) "we need to back to the REAL Agile... the good stuff".
I think that's a mistake. I think we should declare failure with the whole thing and go the totally opposite direction. I'd like to see the Agile movement go up in smoke. However, in order to do that, I don't think that we can afford to play with semantics. Regardless of how well intentioned, brilliant and well thought out the manifesto was - we should be dropping the phrase completely.
I have SO MUCH MORE to say about this but I think I should really make a video. It's a huge topic. Anyway, thank you. Great video. Really great. I loved it!
machivellisucs excellent reference, thank you!
Any news on the video? :-)
David Connelly: my thoughts exactly - check out the following for a similar humorous take on the situation: bit.ly/tisodeft
Would "flexible" be acceptable? How about "adaptive"? The word is not the problem...the people are.
I agree. I remember a discussion on "good money" that got co-opted by Ron Paul. The claim of the article was that money should be named after its underlying metal weight; this would avoid people forgetting that the money is (or was) tied to metal.
I responded at the time and pointed out the British "pound".
It doesn't matter what name you use for something, eventually it will become a thing of its own; completely divorced from its original word usage.
(I'm sure there is some lesson from the old field of "semantics" in there)
This is what they do not talk about, thank you!, the values pre existed before methodologies, let s make code with courage
25/5/2017
update: Agile is still dead.
Was it ever really alive?
LOL. No, it never was. Please see my comment at the top.
Agile was not agile enough, so it got killed by a more agile & extreme attacker.
Can we get a memo on that to the clueless project and hiring managers I need to go through to get a job in the software industry?
In my company we are working with scrum. What do you mean agile is dead. OK agile was after waterfall. What is after agile?
This talk is insightful today. More corporate has adopted Biz-Word like "New Normal", "Leapfrog" and they are actually proper nouns. They want to see this, but they do not know how to leapfrog. Suddenly "Agile" becomes the method to adopt "New Normal" and "Leapfrog". If your company cannot Agile, your company cannot Leapfrog and cannot adopt New Normal. The threat becomes existential this month. So the question is not whether Agile can be Scaled. Instead, it becomes "You must scale up the Agile".
Edit: There is still no Agility in 2020.
You can read the 5 minute version from the speaker's own website. He wrote about this topic over a year ago.
I absolutely love this guy :) We can discuss if there is such a thing as Agile ( since the use of a word dictate language) but the kind of fluff we have to live with in order to satisfy our employers are ridiculous.
Take a shot everytime his mic cord gets caught by that green thing.
Regarding what he says at 19:54
"The benefit of tests comes from the design aspects. The fact that it helps me understand the design of my code. It helps me understand the design of my code, and the interfaces of my code. It helps me decouple my code. And I've been doing it for so long that now I think about that as I'm coding, and the test doesn't have to exist"
All the reasons mentioned for not writing tests are benefits to himself. All that he says assumes that he is the only one doing the coding. But usually, software development is not a solo-sport. It's a team sport. You're not building for yourself. You're building for customers. And even if you're the only one writing code, you won't remember what and why you wrote when you look at your code 5 years later.
If you're working on a hobby project, that's fine. But if you're building software that you want others to be able to contribute to, or people to pay for it- Please write tests.
- A software developer ( who also doesn't usually write tests but not very proud of it )
Amazing. I have been realizing for a while that the "you go do that!" books / lectures / etc were out of context and delusional. Best Project Management lecture I ever watched.
Thanks Dave. I saw the title of the video by accident and couldn't resist not watching as it confirmed my thoughts on the subject. As a developer and tester I am fed up with all these 'hybrid' agile projects. I wasn't familiar with the SAFE diagram - they don't teach me anything and every organisation has it's own agile flavour. I didn't know I had to laugh or cry. So we started with 4 general principles + 12 easy rules and we end up with a complete BS industry(yeah, scrum master in a day) including organisational algorithms. Where I actually learned to be(have) agile in teams: army and squatting. Such self-managing teams rock: This is your target, these are your means, solve it as a team. Go!
That cactus is alive and wants to get him.
at 36:20!
and 36:45 again, it just never quits.
+cannotwest you gave me the best laughter of the year. Anyhow, I love the presentation especially the bit about telling others how to live is not cool.
Agile is Dead but Cactus is Alive!
Ha ha - yes - as soon as I noticed it I thought it looked kind of metaphoric - I like what he is saying though - AND - is walking around in his socks - which is cool
My example of a universal rule is the Golden rule: treat others how you wish to be treated. I can’t think of any situation where this is an exception.
Maybe you signed a DNR, and the patient in the next bed didn't...
@@davethomas9317 still applies, since the treatment is respecting wishes of DNR.
But does.that mean that the golden rule requires to to know everything about the situation before acting? And what about masochists? In a way, the golden rule is a kind of imperialism, saying that what I need iws what you need...
Just debating here :)
@@traviswatson6527
Probably an unpopular opinion here, but I believe Agile methods in their most basic concepts (ie. small steps, go for flexibility) make sense, but Scrum is little more than marketing BS to me. Why 2 weeks? Why lack the flexibility to break a task into multiple sprints? Why anything?
All of these BS rules were pulled out of a hat and there's little rhyme or reason to any of it other than "Google does it" - it's comical. I'm involved with complex video algorithms for device drivers - sometimes shit takes longer than a sprint. Sometimes we find HW bugs and it takes a month to resolve! Sometimes I have a 1 week task and everything else in the backlog is 2 weeks+? It's a joke. Agile isn't agile enough to account for ANY of this. It's not agile enough to handle something crossing a sprint boundary - it's not agile at all....AT ALL....
MrSlowestD16 But the whole point of Agile is to *not* be a slave to your process. If someone is telling you that work cannot cross sprint boundaries, they have a fundamental misunderstanding of the point of -- and the motivation for -- Agile.
did you watch the talk?
Google actually doesn't do it (doesn't enforce it). Teams have flexibility on which agile (or otherwise) methodology they adopt. (according to a dev friend at G).
I always said that most software projects are large and complex. They take as much time as they take, like running a marathon. And you can't run a marathon in a series of short sprints!
scrum is dumb, stick with Kanban. It actually reveals YOUR teams development process issues without "requiring" any of the other BS
Great speech! I completely agree with the philosophy here.
Many people are religious about stuff and just want to be cool not even questioning what they are doing and how different methodologies applies to different domains
Analogy on the short message of the Agile Manifesto:
Don't take the Jeep to arrive from A to unknown B. The safest way is to tiptoe on foot with maximum effort on reassuring your goal every step.
I say this is backwards thinking. You should go with predetermined well throden roads with the jeep. Then step out and swim if you hit the lake.
It's now dark and all you know is that there may be roads and there may be lakes. The jeep=like thing you have has a candle. Better tiptoe or drive real slow. If water, go back a bit.
The problem is that in most projects everyone is blind and unknown B can be thousands of kilometers away. Trying to find it can lead you to China, when you were actually meant to go to Europe.
@@carlosjosejimenezbermudez9255 The analogy was already questionable and you've taken it to the next level. Back to the original problem, agility is best when the 'mission' itself is defined in other terms than simply a well-defined product that needs to be made. This is where all these 'make the thing and no fuss' people go wrong. If your mission is to create as much value as possible for your company, then there is no 'you meant to' in the sense you're trying to push.
Good talk by one of the creators of the Manifesto of Agile Software Development. I like that he gives a history lesson of what development was like under Waterfall and the reason the Manifest was created. I like the fact that he boils 'Agile' down to its basic core. Scrum, Kanban, XP, etc are all forms of writing software with agility, but it's not a one size fit all concept. Change is the constant in software, it's why it's software and not hardware, and adapting to change is the whole point. Changing your process to adapt to situations is good too.
"Agile" has never worked for designers or anyone that likes to know what are they building. Designing in small steps is like driving in a pitch dark. No vision, no architecture, agile is good for very small teams, not sure what product they are doing. The industry created around agile is really disgusting too, and i always despised those agile experts that come with the confidence they know better whats good or bad for our team and product, just because they are certified or "they have been doing it for years". They do not even bother spending time learning about the particular problems we are solving or know the people in the team... they just come and start trying to fit the team in to The Methodology! Setup repeating meeting, waste everyones's time, arrive with useless velocity graphs that tells nothing about the amount or quality of the work done, kill features that will "take too long" to fit in one release..
There must be a better way to build products, and agility is only part of the answer, not the whole story.
Agreed and even for relatively prosaic tools which are not about a grand vision. Recently I've been working on a backoffice tool for someone at our company who has to curate the semantic connections between tags for our profile matching engine. The existing tool and internals turned out to be frustrating and buggy enough that he has turned to a frustrating but at least stable massive spreadsheet. The agile way would suggest that I should drip out all the smaller improvements and bug fixes I've been making and get his feedback on each iteration.
But this would be the wrong thing to do. It's not a matter of taste to prefer not having critical bugs and purposeless functionality restrictions. Until it gets past a certain threshold we have already agreed it won't be an MVP because it's not viable otherwise. If there were no alternative it would be but currently there's still a spreadsheet to beat (one that I can't import until a lot of this work is done anyway). One might object "ok but after MVP is when you do small iterations" but I'd argue that the product doesn't just reach that magic stage early on and never return. Many significant features and modules will need to reach an MVP standard and that this might be most of the dev time. Hopefully it will, in fact, because the rest of the time will mostly be for bugs and chores - both things you don't want much of.
There's no point losing the trust of users by repeatedly delivering way less than what they asked for and hoping they suddenly change their mind. This job has involved the near rewriting of 4 interconnected microservices and has taken a good few weeks while attending to other work. It's not agile and it's not visionary design. It's just a big bit of work that needs to be done.
"agile experts that come with the confidence they know better whats good or bad for our team and product, just because they are certified or "they have been doing it for years". They do not even bother spending time learning about the particular problems we are solving or know the people in the team... they just come and start trying to fit the team in to The Methodology! Setup repeating meeting, waste everyones's time, arrive with useless velocity graphs that tells nothing about the amount or quality of the work done" TOTALLY AGREE
brilliant - spot on
Totally agree... Its funny that the experts always justify it by telling the story of how it was a invented by a Toyota manufacturing plant... But they don't have the perspective to realize that production line teams couldn't be more different than development teams, both in what they do and how best to go about doing it.
"Agile" has never worked for designers or anyone that likes to know what are they building."
LOL so true :P There was a time when we had well defined requirements for what we were building because there was an analysis phase in which people actually had to think what they wanted BEFOREHAND. Ahh those were the times. And i also strongly despise the industry of snake oil sellers (and buyers!) that has grown around it.
Great Talk, thank you. Some aspects apply to so many things, nowadays, not only "Agile". There are so many terms misused for marketing and sellout purposes...
Lol, just started this video "Agile is Dead" and I got an ad for agile online training 😜
Very well done.
If using Agile as a noun--especially a proper one--makes him so angry, wait till he sees what they titled this video.
"Don't Piss in the wind, unless your trying to nail a friend around the corner."
people please listen carefully to this talk, this is how you make a 1 minute talk into a 40 minutes talk
THIS! I was about to post the same thing. Yeah Agile was dead the day it was pitched to jackasses as the solution to everything. And then they got guys like this guy "I don't test" - yep I wanna hire him. And I want my effing 39:00 minutes back.
I find it interesting, that both in the PID algorithm and in "life", is that he basically describing the calculus, presently the best formal presentation of that process. Korzybski would be proud. :)
Today I learned that the Star Trek TNG episode with that one alien race that communicates entirely through memes is real, except it's Chinese Chengyu
I had no idea Bones died in '99. God he was amazing in Star Trek. And he also really didn't look as old as he apparently was. Shocked me to find out he was born in 1920. Dee was great. Bless his soul.
Also, Have you seen William Shatner? He still looks fairly young considering his age. He still looks like he could captain a starship no issue.
Agile is yet another shovel to sell to those digging for gold.
Best practice is related to putting the sharp end into the dirt (not into your foot). Here's a certification proving that all wielders of this shovel are unlikely to put it into their own foot. (Note that the sellers of the shovel are indemnified from any damage, loss of limb, property, or any other incidents related to misuse of this shovel)
Agree with most except: design to make changes easier. Design to make it simple and understandable. For the sake of changeability, people tend to put abstractions, interfaces everywhere which kills readability.
Finally, the cameraman isn't asleep... Awesome talk by *****!
Awesome speaker!!!
"No rules are universal"
There is one universal rule.
Is that 2 rules? How many more?
Thank you for the presentation and you folks who posted comments. I can relate. I thought something was wrong with me not adapting to agile.
I wish it were dead. Go get a job somewhere and you'll find out it is very much alive.
Paul Mcgee Tell them ooo.
Got a "Learn Agile" course advert watching this.
Took training at a large health care company on "agile", this is the diagram of team of teams, train of trains, etc (@22:52) which the trainers preached. It was such a culture of language and verbiage play that I did not find it at all useful. Now, I use agile and its thinking everyday and find that to be very useful...but not the convoluted training that I have been experiencing at companies. I generally advise teams on "agilesque" ideas which fit a particular circumstance. I like the ideas of daily scrum, sprints, show and tell feedback loops. I am not sure where I stand on testing though. Anyway, thanks for the talk...I feel vindicated :)