I've read many of Allen Holub articles in the beginning of my career almost 20 years ago. This is the first time I see him speaking. Love it. Coincidentally, I already agreed with almost everything in his talk before I watch it.
Holubs comments about corporate culture are, in my experience, very true. Over the years, I've noticed, not just in the software dev field, but others as well, that when organizations try to implement what real inovators, with very good ideas on how to improve things, have come up with, they often run into an already encrusted culture that is terribly resistant to change. I for one can be very resistant to change. I understand why that happens on a personal level. From my experience, it is often the case in groups and organizations.
April 2019, five years after this original talk and Agile seems to be adopted everywhere. I have not experienced a single well done Agile implementation over the past 5 years. People within the process are complaining they feel less productive, spend so much time defending, deflecting, and gaming the system to appease top management. My question, why are companies still adopting Agile - has this all just been a FOMO movement? I am curious.
@@redhotbits sounds to me like a fanatic cult to me. This kind of sects where the Messiah and religion are perfect, but nobody is smart enough to actually do it right. Meanwhile, they are closed in a room about to mass suicide
I've worked at 5 companies. One waterfall, two nothings, one bastardized-agile, and one scrum. The nothings were better than the waterfall, the bastard, and scrum. I've come to realize while the nothings lacked a lot of things that I would've liked added (mostly XP), they were the closest to agile and therefore sucked the least. No deadlines and no reoccurring meetings. If they just added some more XP they'd have been pretty good.
I am appalled at the way that Scrum has so completely taken over that everyone is expected to already be familiar with it and, essentially, take it for granted as the default way to manage projects. My shop is basically doing Scrum because that's what everyone does. They didn't even make any visible decision or announce an initiative to go agile, like you would have seen in the previous decade... they give the impression of almost having fallen into it by accident. The ironic thing is that I actually worked in a more agile way there before they added the Scrumminess. Like, I would start a new project or feature by mocking up a dummy UI, and gradually add working features, with customer (or at least marketing dept) feedback all the way through. Now with sprints and stories and acceptance criteria and all that, it's actually more waterfall than before -- more pre-designed and less responsive to the users.
I've been a developer for a few years now and these talks really confirm my feelings when I first got in. I was like "None of this makes sense." It's really disheartening what corporations and etc have done to agility. The frustration that developers like myself have with Agility within these corporations is that it has been taken as a tool to develop software efficiently and collaboratively and it has been changed into a blunt instrument to beat developers and wring as much code out of them in the shortest time possible.
Chris, that's great that you've coded all of this, but you haven't updated your progress in JIRA once in three days. You may have said something in standup's, but nobody is listening during standup's and you know that! QA is going to flip out that they don't have enough time to get this done by the end of the sprint. The client doesn't even know who you are. We're gonna have to let you go.
Easy to do when you do inhouse development to provide service. Try to sell things, sell software to customers who are willing to pay EUR millions. You can not say it will be done when it will be done. The customer wants dates, that is your deadline. Once I saw a video about Agile contracts. It said the contract must be agile, so the developing company can be agile.
This is spot on. Organizations bastardize agile, and make it inflexible. the business needs to understand agile as well as the programmers. Everything needs to be negociable by the entire team. The PO should not be a dictator. Support too must be fully integrated. Everyone on the team should understand the stories from a high level. If the management does not understand agile, it won't work.
9 years later and this is still just relevant. Honestly I will admit that the whole "non-agile corporations will go the way of the dodo" is a bit naive, as they'll fight tooth and nail to continue existing.
From the very beginning it sounds like the corporate people are looking for a one-size-fits-all production process. The other thing on top of the manifesto is "We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value..." which clearly indicates that there's a learning process there too to make sure that it keeps on adapting to the situation. Fowler said at some point that they chose the word "agile" because ones like "adaptive" had already been taken.
Allen there are no wrong questions. Mocking sincere inquiry on discussion boards is counter agile which is about sincere inquiry and learning. I have noticed so many arrogant, blustery know-it-alls commenting on discussion boards trying to stunt fledgling agilistas by mocking their sincere questions. Just something to consider.
+Linda Fane I agree, but I don't really know what you're talking about. To the best of my knowledge, I have not been "mocking sincere inquiry on discussion boards." Can you point me at something that you find offensive? If you're directing comments to my keynote, I don't see anything that I've said as "mocking," though I'm certainly critical of the many shops that think that they're agile when they're not. If those folks had asked a few "sincere questions," perhaps they would not have gotten into the situation that they're in. While we're on the subject of discussion boards. I regularly contribute to the "Agile and Lean Software Development" group on LinkedIn (www.linkedin.com/groups/37631). It's moderated aggressively, so is one of the few discussion groups that I've found where people who are asking sincere questions can actually get good answers (though they occasionally get off-the-mark answers as well - it is the internet :-) ).
This was informative and enlightening. Thank you. However in all these different presentations I have viewed, it seems Agile and its components as a whole are really for software or directly related activities. I have worked on many teams that try to use Agile for the IT/Software side as well as the entire process and day to day business operation, But often the business/process side gets pushed further out and/or takes a back seat completely. For many projects it also seems to be overblown and plodding. Some projects fail and/or run out of budget because of the initial, underlying requirements just to start, let alone complete a project. It does not seem to be very flexible and not real world for all projects. These projects are often started and run from the IT/software side out and not enough attention is paid to the real, underlying business; in a nut shell, the actual business operations, and process SMEs are too few or sometimes non-existent until the IT/Software is conceived and decided on. Then it's a struggle going forward because there is not enough flexibility to "retool in flight" as it were. So business side (operations, compliance, regulatory, legal, etc) are not happy and a lot of time was or is wasted. Question 1): Is there a modified version yet that is designed to focus more on the Business Process first? Similar to classic Six Sigma vs Lean? Six Sigma was a plodding beast, yet Lean is very business and process side effective because they cut out and slimmed down sections that really only applied to manufacturing, not other businesses. Focus is on what is business primary first.... Question: 1) Do you see a possible value in merging some aspects of these 2 methodologies? 2) Or is Agile and components just not applied properly or sometimes used for the wrong project? 3) In you presentation, you said to eliminate documentation, yet Agile is all about documentation and steps which may not really be needed for all projects; often done just because the method dictates it. Thank you again for your time.
As Alan describes near the start of his talk, the essence of Agile should be agility. If your organisation isn't able to respond to changing situations and requirements, it doesn't have agility or flexibility. In which case the essence of Lean is a good place to start: reducing waste, empowering the workers, and using an iterative approach to improvements (kaizen). The processes of Scrum and Agile are the least important parts of business agility.
I've seen him do this a few times. It all sounds so wonderful...until you have people who don't pull their weight (you always do) and have no documentation to justify the way you deal with them.
I like your talk very much. You demonstrate a deep understanding of developing software with agility and forming agile organizations, using the manifesto as a guide. You even get some things very right about many corporate cultures and some in the Scrum community of trainers, Scrum Masters etc. However, I fear you've been misinformed about some aspects of Scrum. You mention that Scrum is a process when it is a framework. Therefore, your premise about how a 16 page document cannot define a process may be correct, yet it is moot. You can argue that it is wrong in calling itself a framework. I'd think this would be difficult given the flexibility (or, agility) organizations are given in how them implement Scrum. For example, many I know several dev teams that practice the XP methodology within the Scrum framework. This would be a very hard thing to do if Scrum were actually a process, unless it were a proper sub-set of XP processes, which it is not. Likewise, a development team could even practice a very waterfall-like process in a sprint if they wanted to. To be clear, this is a terrible idea, but it could be done (I've seen it). Also, you mention that once a Sprint starts (paraphrasing), the work to be done cannot change and therefore is in opposition to the "Embrace changing requirements, even late in development..." agile principle. As far as the Scrum guide is concerned, this is not true at all. If things change, the PO and Dev team are encouraged to embrace this change by creating new work, chucking irrelevant work, and even canceling a Sprint if the goal of the Sprint has become irrelevant...even if they are only 5 minutes into a Sprint. They go immediately into Sprint planning to choose the next bit of work to develop. Scrum needs refinement, sure. It's evolving. Some Scrum communities do feed the corporate "dodo'ism" that exists out there; however, Scrum as written is very agile and some Scrum communities don't sell ballistic nukes that leave corporations in ruins. I hope you see this even if you don't acknowledge it in your talks.
+Jason Knight, Well, you're absolutely right with respect to those people who are doing Scrum according to the Scrum Guide, and of course I agree with your points. My experience is that most of the shops that call themselves Scrum shops follow a rigid process that they learned in some certification program, however. It's really those folks who I'm talking to in this particular presentation. The Scrum Guide itself is in a strange middle ground with respect to the process/framework thing. It mandates things like the length of the retrospective (3 hours for a one-month Sprint), for example. That's really a process requirement. To me, a pure framework would mandate process assessment and introspection, but leave the details up to the implementation. For a framework, the Guide is awfully prescriptive in places. Your example of a Scrum shop using XP is another case in point. Kent Beck points out that if you're not doing at least 80% of XP, you'll get only 20% of the benefit. Well, XP has only 11 or so (depending on how you count) practices. So, if you drop 2 of the practices, you're not really doing XP any more. XP mandates an on-site customer as part of the "whole team" A PO, however, is typically an employee of the company, whose loyalties are split between being the company and the customer. The PO is rarely an actual customer. XP also calls for continuous integration and constant feedback (and modifications) made as soon as the on-site customer gives his or her feedback. This could happen as often as hourly. Scrum however, doesn't typically present anything until the Sprint Review. (I won't argue that you could change things, but that's the way it's usually done.) So, given that we're now below our 80% threshold, we're not really doing XP any more. Fix things, and we're not really doing Scrum any more. A conundrum! You can argue, however, that Scrum encourages process modifications. The Retrospective section of the Guide for example, in no way limits the changes that a team could make in order to improve it's process. Consequently, a Scrum team could decide to eliminate things that are usually central to Scrum (a PO, for example), and still be within the guide. In fact, the team could evolve it's process into something that didn't look at all like what most people call Scrum. Personally, I think that's a good thing, but you end up at a place where you're doing something that doesn't look at all like Scrum as it's usually understood, but you're still calling it Scrum. Another conundrum :-). So, where I'm really headed is that maybe we're all better off dropping all the labels entirely, going back to first principles---the Manifesto and Principles---and call it good.
+Allen Holub Thank you for the excellent reply! Well, I learned a little something about XP today. I'd somehow missed that the customer was a member of the whole team. I guess I need to do more homework on this point. On the customer/PO conundrum...I wonder what would stop a self-organizing Scrum team from making a customer be a member of the Development Team? Probably nothing, so long as the two organizations were agile enough in their practices. Business analysts, while not typically thought of as dev team members, can be excellent additions to the Dev team. There's a place in Tulsa (where I live/work) that is hiring an analyst into a dev team as we speak. I suppose the dev team could practice XP this way and avoid the conundrum by having the customer and PO co-exist on the same team. This gives me an idea for an improvement that can be made on a Scrum Team I'm SM'ing for at the moment. Certainly, the technical practices you describe do not conflict with Scrum's framework, but rather enhance the result. As for the continuous feedback/review cycle, we probably agree completely on this. Scrum doesn't prohibit XP customer interactions at this frequency, yet it is typically not practiced as such. Furthermore, some myopically interpret the Scrum guide to actually prohibit this kind of customer interaction. This is a result of reader bias and something good coaching can help with. I argue with myself if such coaching statements should be more prevalent in the guide or if this is the role of companion teaching e.g. books, coaching, training, etc. The Scrum guide is funny, in that it contains the essentials of Scrum and a fair amount of specific suggestions. The 3-hr time boxed Retro for example is not as important a figure of time as the 15 minute Daily Scrum's timebox. Development Teams may jettison the 3 questions listed for a Daily Scrum in favor of more productive planning practices, yet they are specifically offered as a procedural practice. Many will hold dogmatically to the wrong parts of the Scrum guide and miss the irreducible essence of the framework. I confess the Scrum guide does not make clear what parts of it are immutable and which are suggestions. This was confusing to me as a beginner until I dug into it and searched out those like Steve Porter over at Scrum.org for clarification. The essence of what Scrum is much more of a framework than the guide may present. Clearer definition of the framework vs suggestion parts on the Scrum guide would be a huge help to many IMHO.
I still wonder how to charge for this kind of job. I know that most (if no all) of the points made in this talk are real, but customers don't know what they need or want, but also they hate to pay for something they don't know they need or want. if that make any sense. So what is it? monthly fee? charge on every requirement, no matter how big it is?
+Marcos Vargas Moran: I think your best bet is to make your contracts match the way you work. That is, the story is your basic unit of value, and charge by the iteration/sprint. (I typically size my stories so that they take an iteration---about two weeks or less---to complete). Sit down with the customer at the beginning of the iteration and help them prioritize the work at hand, pick the highest-value story and contract to build that. At the end of the iteration, you get paid (immediately---long delays violate the basic XP value of "respect." If they can't do that, work against a retainer that your replenish periodically), and you deliver the software. Use your "definition of done" as the acceptance criterion. That approach may or may not work for a big consultancy, that wants to land multi-million-dollar contracts, but it's worked for me as a small contractor. For one thing, it's really in the customer's benefit to work this way because it eliminates the up-front risk (promising a big lump of money to an unknown quantity to produce a not-well-enough-defined product).
+Allen Holub Ok, thanks. I will try to do that from now on, But here in Chile they like to pay when the "whole" thing is done, yes that one they cannot put their finger on for requirements unless their are seeing it, but i'm always trying to push the iterative approach. I'll use your last statement about eliminating risk, maybe that'll work. Salutations.
33:00 I love the idea of the "business people" being actually on the team, but in my experience they're the "business people" BECAUSE they're not developers, and their main job is client interaction, while we're building the tools for the client. So if they're on the team, what are they doing when we're not asking them questions (since they're not developing). They must be doing their "regular" job. What's the third ideal way between "not on the team and are always in meetings for their 'real' job" and "on the team and bored half the time while the rest of the team is writing code"?
Well, the XP way is to get the client in the room and the "business people" messenger owls hit the road. Failing that, then the business people ARE the customer, and they do their job from the team's office.
Big corporations like Boeing or General Electric need to do big projects of high complexity and there is no place for those "bubbles" of teams you just trust to do the job - aviation, industrial equipment or medicine are about solid requirements, which you have to follow or people gonna die. But. In all cases where you can go over the process - you should. And THAT IS to be Agile for big corporations: not 'always', not 'never', but when needed.
Up-front architectural design is very important in safety-critical systems. On air data inertial reference units, there is partitioning in time and memory space. These partitions both produce and consume data used by other partitions. The lists of producers and consumers of data are in xml files. This is done to protect the most important data producers in the system. For example, the sensor monitors like the gyro life monitor is a "nice to have" partition that is used for preemptive maintenance to replace a part before it fails. The inertial reference partition that produces the pitch, roll, and yaw angle of an airplane produces data that is safety critical. By using this partitioning, if the sensor monitor gets stuck in a while loop, it won't prevent the inertial reference partition from producing its data. The air data component that produces altitude and airspeed is on a separate circuit card, with a different processor and different compiler to eliminate any potential common mode failure source. On medical devices I have worked on there are similar architectural decisions that have to be made up front. Usually there is a "front end" GUI and a "back end" embedded component. The back end is safety-critical and tested to a much higher standard and it is understood that since the front end isn't tested to the same standard, the back end validates any messages received from the front end for safety. Up-front architectural decisions like these don't fit nicely into these infantile little sprints and daily scrum meetings.
Unfortunately, managers are starting to inflict agile scrum on products that have the potential to cause plane crashes if not functioning properly. In 2022, I went back to a former employer where I have worked numerous times in the past as a contractor. They build Air Data Inertial Reference Unis for passenger jets. They weren’t doing agile scrum, and life was good. The manager who hired me is someone I had worked for in the past, but retired in early 2023. He was replaced by a younger manager who wanted to make the team be agile. The lead engineers were not happy, and for a good reason. It is not compatible for this product line. They brought in agile coaches to teach them how to be “agile.” When these con artists told them all the things they need to do to be agile, the engineers pointed out that after following their so called process, they didn’t have any of the documents required for FAA certification, like objective evidence of the requirements based test coverage, a traceability matrix, independence of code review and independence of test, etc. There was another meeting with the “agile transformation” on the agenda. Contractors weren’t invited to that meeting. When the meeting was over, saying my coworkers were upset is putting it mildly. According to my coworkers, they pointed out that when they are in the testing phase of product development, problem reports are written, adding to the workload, making it impossible to stick to a “burndown chart.” One of those flimflam artists (an agile coach) actually said, “Just delete them. You don’t need them.” A coworker replied, “We could go to jail for that, and you could go to jail for ordering us to do it.” Keep in mind, this is a product that is regulated by the FAA, because it can cause plane crashes if it isn’t working properly. When a problem report is written, the first step in the process is for systems engineers to do an analysis to determine if it is a safety issue, like something that could cause and inaccurate altitude reading, or a more minor issue, like a linker directive that allocates less memory than a requirement document specifies, but that has been determined to be adequate in the worst case of memory usage. The safety issues are given top priority and cannot be deferred to later releases. From what my coworkers described, it didn’t sound like the agile coach understood the ramifications of deleting problem reports on a regulated safety-critical product. It sounded more like it was a person with no experience in this type of product or maybe even in the engineering field in general, who thought that because they took a two-week agile certification course, they were qualified to advise people with real degrees from accredited universities and years of experience in the industry on how to do their jobs.
The Scrum framework (not process) was a foundation for the Manifesto. Don't blame the tool for the failings of people. Scrum is not perfect, but it's proven when utilized correctly. Remember that corporations are a collective of people....that's why "Agile" fails.
Well, there's Scrum and there's Scrum. The cargo-cult Scrum that you see in most organizations is not Scrum, as presented in the Scrum guide, and Scrum itself, even when done perfectly, is not effective without something like XP that defines how to do day-to-day work (my source for that statement is Sutherland himself). Interestingly, XP by itself is just as effective as XP + Scrum, so I do wonder what the value proposition actually is. I certainly agree that Agile(tm) fails because of people, but that doesn't mean that Scrum is the only or anything like the best framework to be using. My real worry, however is that when people say that "Agile" fails, they aren't doing anything even remotely Agile. Simply doing the things in the Scrum Guide in no way make you Agile, so in that sense, it doesn't work in the way that people imagine.
The presentation is great in regards to cargo cults, organization friction, philosophy versus Agile(tm), etc. Scrum is not perfect, and I agree that it works best with many of the XP practices. But I'm not here to defend the framework; I prefer pure flow. Without the Scrum bashing, it might be worth sharing in some corporate environments due to the previously noted content. Scrum is often the best gateway to introduce the agile philosophy and iterative & incremental execution. There's a lot of ignorance around the concepts of agility from executives to technologists. Ideally we could create change from the basis (manifesto); in reality it often has to start with something more familiar to the conglomerate current operation. I'd be glad to be proven wrong on that point! Thank you for engaging. I always take something useful away from your content on any platform. (Apologies for mistakes. Tired. On a phone. But wanted to reply. Thanks.)
Thanks Alan! I always learn something from everybody's comments, so I welcome them. I'm hoping that the Agility video class I'm putting together (agilitry.com) will help with the on-the-wrong-track situation. I'm just about done with the first (business case for Agile) module, which discusses the core issues without any "Scrum bashing" :-) at all!
@@AllenHolub Perhaps the value proposition is that scrum can apply to domains beyond software development? ... Enjoyed your presentation. Thought it might be interesting to talk about how Spotify started with scrum and moved away from elements of it as they inspected and adapted. The whole individuals and interactions over process and tools thing :-)
Great presentation and good points! Regarding SAFe - I believe the PI increment from SAFe (having teams work together and solve dependencies) is helping teams, collaboration does help teams a lot and changing the organization to support your values will help large organizations (value streams). Most companies that I have been working with is having the problem that you talk about - when management does not support Agile, it is impossible to change things, if the top of the company does not understand and support it, it is impossible to make the changes.
Scrum it's a framework, not a process, in fact it acts a container of process or practices system like XP. Thats is clear said in the Scrum Guide and you can see a successful combination of Scrum and XP in the book "SCRUM AND XP FROM THE TRENCHES". I don't agree with the Allen Holub's analysis because it's not consider that Scrum it's just a framework and not a methodology nor a process. By the way, Scrum artifact don't require any tool an no one it is suggested in the Scrum Guide.
The thing is, it doesn't matter what the intention of the inventor was and what Scrum really is. If people who have not understood that Scrum is not a process or a method use it as such with the same control mechanisms from the past (budget, time, ...) because they have always done it that way, it does not help to deliver value to the customer. We don't achieve agility / flexibility by stubbornly following the things that are written on those 16 pages without questioning them. If it doesn't work we have to change it, and we have to change it right away - not after 14-30 days. Companies that have only worked according to processes and control will not make the leap. They don't understand how their own system needs to be changed, which is what creates the cultural conditions for the successful use of agility in the first place. Companies equate Scrum with Agile because they don't want/can't let go of their old systems that still focus on control and management. Even Schwaber/Sutherland write "management is waste". Scrum is just one among many ways to develop products iteratively and has nothing to do with agile. The agile manifest consists of 50% people thinking, the scrum guide says nothing about this.
Agile is like pop psychology. The most obvious concepts turned into something ugly. "Make our code, test it and adjust for an easier time in the future for changes"
I'm totally following you on this, but we part ways at 27:06 ... ask the customer what they need to do. Let's set the stage here. I am a one-man, self-funded startup operating out of a home office, building a speculative product to satisfy what I think is a need in the market. At this stage, THERE ARE NO CUSTOMERS. There is no one to ask. I've tried for many years to do the Lean Startup thing, and I've just never been able to make that work. The problem for me is you go out, talk to prospective users, and the feedback is very vague. Some people don't want to hurt your feelings and tell you it sounds interesting. Other people tell you how they solve that problem now. Blah blah blah. All of my friends, especially my sales and marketing friends, tell me to do the validated learning thing. Here's the thing though ... not a single one of those people have ever built a successful software startup from scratch. It's very difficult to change the world nowadays. It's very difficult to create a product that is so innovative and disruptive that when you tell people about it before you've ever built it, they start shaking. 30 years ago you could do that, but now, it's just so hard to do. My experience is you just never get anywhere when you try to do early validation. When I work on a particular domain, and I've thought about it a lot, I've thought about what I would want, I've researched what's out there in terms of competition, and yeah, I've talked to a few people too, this may sound conceited, but I will then know way, way, way, way more about that particular thing than anyone I talk to. Any objection they tell me, I've already heard it. Any feature idea they have, I've already thought about it. It's just very difficult to really learn anything. End result is we wind up at an impasse ... I think the world needs this innovative thing I have in mind, and most people I talk to think their current way of doing that thing is good enough. Ok. Now what? Do you build it or not? No one solves this problem for me. Agile, Scrum, Lean Startup. Early Validation. No one solves it. How do you find latent, untapped demand in a saturated, overcrowded world?
Interesting experiences, thanks for sharing! Disclaimer: I have never tried to bring any software related stuff to the market. I have some experience with software innovation, so your experiences feel familiar. From what you write I understand that you tried to bring innovation to the market. And that the end users end up not understanding it. Especially from your last sentences I wonder what makes you think that you know better what someone needs than they do themselves? What I understood from reading The Lean Startup was that asking isn't going to tell you anything. I also remember someone saying that "I like that idea" isn't what you want to hear, it's "I'll pay you $100 for that right now *grabs wallet*". I think the thing is to get a MVP out there, which is (just) enough to make someone make a real consumer decision: will I pay for that?
@@RoelBaardman Thanks for the reply. I like talking about these things. Well for me, I've been working on software development tools for 30 years, having previously started and sold 2 startups in the space. That, plus being a software developer myself, I'd say, yeah, I'm pretty confident that I have a good handle on what's needed out there, and probably know the whole space much better than any one customer that I'm likely to interview. The product I'm developing is a new type of documentation and search tool for software developers. So that's the thing about a documentation tool, it's necessary to manage software complexity, there is demand for it in the market, but no one is going to start doing back flips down the hall when you talk to them about a documentation tool. There's just going to be a certain amount of natural apathy. That doesn't mean it's a bad idea, it just means there's a limit to what you are going to learn by interviewing customers. So what makes me think it's a good idea? First, the relative success of Confluence. I used to work at Atlassian, so I have a pretty good idea of the strengths and weaknesses of Confluence. Second, the success of SourceGraph in code searching. The tool I'm working on is like if Confluence and SourceGraph had a baby.
@@RoelBaardman Quick story. I was talking to a good friend a few years ago about note taking for developers. Do you use Evernote? Do you use OneNote? What do you like/dislike about them? Etc. And he was like "Nope. I don't do note taking. Don't need it. I don't have a hard time remember what I need to remember. I use my IDE. If I need to remember something, I jot down a quick comment in the source code. I don't think I'd ever use a note taking system." At that time he'd worked on the same project for 20 years. Then one day he got put onto a new project, and he was like "OH ... MY ... GOD!!! So much new stuff to learn! I can't keep it all straight. I had to start writing it down so I can look up all these details more quickly. OneNote is my new best friend!!!" Aha. See. Aha. That's the thing. People don't have this problem until they have the problem, then they get it.
See, he even poo poos documentation in this video. Not needed. It's waste. Blah blah blah. I mean it's a little hard to buy this theory. Isn't the entire World Wide Web just one giant hyperlinked electronic document? HTML? XML? XSLT transforms? Typewriters? Word processors? Spreadsheets? For not being needed, we've sure invested a heck of a lot of resources as a society into electronic documentation.
@@kdietz65 Judging from his comment here, I think that he is talking to the companies that just do the rituals. That write documentation that nobody reads. th-cam.com/video/HZyRQ8Uhhmk/w-d-xo.html&lc=UggkShi27U2yI3gCoAEC.89QCWJZPjVC89QZ7V52_TK I've been at several of those companies. I saw someone write a document "because every project needs this document". The document was even supposed to be written up-front, but he wrote it days before the project was finished. Pure waste. I do not doubt that you're seeing a real need, as I think scratching your own itch is a good strategy to build something... you have at least 1 customer. :-) I think however you are betting (that other people will pay money for it), and it is this that Validated Learning aims to eliminate. I can imagine VL doesn't work to well for pushing innovation, especially if you have a hard time finding early adopters (people willing to try something new and change their habits, just because it's new). Then VL will only tell you that you're wrong. A change in habits must take place if you're doing something in a radical new way and not "a better old way". If someone's not willing to make that change, he's probably not your customer at this point. I've always found it interesting that Apple didn't do focus groups either, I think for the same reasons you state.
I took issue with the documentation thing myself. He did specify it's useless if "no one will read it". I think README.md documentation has value, we know that from looking at any open-source library. People read that. Most people won't touch your OSS library if it has a blank readme. How do I install this application on my local, what are the steps to deploy, is there a deployment checklist? You need processes (he said as much) and what good are processes without documenting them?
Like always and your tone on Twitter... blaming and "I know it better then you guys". I'm getting sick to death of your negativism. Keep positive dude!
He first said that Agile is not about processes and then he says that "It's agile not to have a QA department". The Agile manifesto doesn't say that at all! There are cases in which QA is pointless, there are other scenarios in which QA is fundamental. The Agile manifesto says that you have to be flexible depending on what you are trying to implement!
I think you're missing the point. Having a specific department for a specific function is an opportunity for additional friction/communication cost. It may very well be necessary, but it might not. For QAs, why have a seperate sub-organisation when a self-organized team could potentially take care of it on their own, or god forbid, automate the tests.
Don't be fooled by the plaid shirt. There is a lot more ideology here than meets the eye. First of all, the part of the software industry mired in requirements churn is large, but hardly the whole story. Yes, software is eating the world, but no, not _all_ software is eating the world. This later class often has requirements that are either a) surprisingly stable, or b) not customer apparent. One can fiddle with semantics and declare any sufficiently fickle stake-holder who gives a shit as "the" customer, but it might be simpler just to admit that sometimes software is a coherence-centric endeavour, and these cases are best managed as such (so much of this work has now entered the water supply that we tend to forget it exists). By that view, agile is only "the best way" to deliver that software for which agile is best suited. Ta da! Second, "the" customer is a fiction on another level as well. One of my favourite clips ever, in which Bryan Cantrill excoriates Unix "tail" illustrates this. th-cam.com/video/vm1GJMp0QN4/w-d-xo.htmlm31s If you're in the business of attaining deep reliability, you _are_ your own customer, whatever other customers you choose to acknowledge. It's not unlikely that your long-term needs are entirely orthogonal, and impractical to story board. The way Unix tail presently works is the product of distant, dusty guru meditations that either swallowed the blue or red pill. There _is_ no story board for choosing between pills. Again, one can fiddle semantics and declare that whatever feedback dominates the outcome is the "customer" feedback loop. But wouldn't it sometimes be simpler to just admit that there _are_ circumstances where other loops gain preeminence? Third, as someone who struggles with N24 sleep disorder, the ability to show up bright-eyed and bushy-tailed on a consistent basis day after day is something I've requested from Santa going on thirty straight years. Holub basically said I should get myself a different profession. Nuh uh. I finally learned to cope by becoming more personally agile, to whit: _not_ imposing any fixed expectation of myself on any given day. Thankfully, there are still niches out there where ultimate coherence trumps personal vagaries or I'd be so fucked, despite all my many years invested. Fourth, I got a good laugh from the juxtaposition of "simple" (one of the core principles of agile, procured from the "I know it when I see it" department) against the backdrop of "agile won't work unless the entire corporation is perfectly impedance matched around the agile philosophy". Hmmm, nothing spells "simple" like waking up to discover that you've just been tasked with refactoring Big Corp. Here's a tip: cooperation is _never_ simple. When you're happily in the sweet spot, one gets that oh so simple feeling-it's delightful, it's delicious, it's de-lovely. But when you're _not_ in the sweet spot, one can hardly tie two shoelaces together without spitting nails. Finally, concerning Spotify, the IT consulting industry is littered with showy exemplars of one methodology after another, where it turns out that showy exemplar succeeded not so much because of the chosen methodology, but because they were a first-class assembly of talent (who feasibly could have built the system with a methodology based on toothpicks, duct tape, and C++). Even where one can recruit a similar caliber of people-they don't always exist, and supposing they do, you might not be able to afford them-even _with_ these chosen few in hand, it isn't always possible to replicate these happy accidents. Corporate chemistry, it's a thing. Plus, as we all know, often you find yourself going to war with the army you have. Double plus: as any good economist knows, a _lot_ of social conventions work in Sweden that don't work so successfully anywhere else. We could likewise argue that the "cushy" Norwegian prison system is a great model for everywhere else, too. Realists, however, acknowledge that the Norwegian prison system leverages a unique combination of economic and social capital. And many other countries don't even _want_ those progressive outcomes to begin with. America is not Sweden. (If Spotify is forced to move to New York, they might discover that America is _better_ than Sweden, or they might discover their fabled "agile" corporate sauce failed to navigate the voyage over.) Apart from Holub's consistent discourse posture of playing fast and loose with nuance, this is actually a pretty good talk. I came away understanding Agile way better than I did before. Just don't be fooled by the plaid shirt.
It sounds like agile just isn't suited for all software projects. Going without a QA department is pretty much impossible in the video game industry in particular because most gameplay mechanics are so inherently complex and interact with *every other mechanic in the game* in so many different ways that it's practically impossible to completely test a video game at the developer level, even with automation, even with very smart developers who understand the entire product well enough to imagine every possible case that they would need to test. There's just too much emergent complexity in a video game and devs can't possibly hold all of it in their heads, ever. And then there's that designers build the game around the software as it is when they're working on a particular piece of it... Some readers may recall that StarCraft: Remastered couldn't fix pathfinding bugs from when the game shipped because they had become part of the game balance! And then having the customer in the room is also pretty much impossible in gamedev, because "the customer" isn't any one person or group, it's millions of consumers, many of whom are likely to be actively hostile to you personally. Going without deadlines is also impossible; ship dates are important for coordinating with marketing plans and delaying a game release once it's announced is *nearly impossible* (it can be done, but it pisses literally everyone off and loses the company customers). Not having a process or accountability when engineers are the minority of people who are actually building the product would mean that there would be even more delay and waste in these things than there already is. "Trust" is pretty much impossible when your team is hundreds of people and *needs* to be, because your actual product is decades of person-years in size and most of your team is not devs. And self-organizing teams has also been shown to be a recipe for toxicity and company paralysis (see: Valve Software). Small agile teams cannot overthrow the big industry players because success correlates to a) marketing b) targeting an experience that indies cannot compete with, so Darwin/Marx cannot "set things right" here. At least, by way of agile development. What am I supposed to tell the scrum enthusiasts in the game industry, I wonder... Based on this talk, it surely can't be "do actual agile", because that won't work for us...
I thought agile was BS, then I watched this video and now I know for certain it's BS. Most of these points not only don't happen in real life, they shouldn't happen. Best example, no deadlines, that means your software is not important.
It sounds to me that you already decided what you wanted to hear from this talk. What he said was, if you have a deadline, and your projections don't match up, either adjust the scope, or adjust the number of people. But don't work your developers to death (or burnout), get a sustainable pace.
I've tried this on big programs with many agile purists, and it's a complete failure. It's a cult mentality. Rituals and philosophies do not directly move you to success. It might work on small simple apps, but that's because any method will work in small simple apps.
Agile at its core is so vague and obscure that it is irrelevant. It gets only meaningful when it ironically starts following the process. It might be SCRUM or any other version, AGILE are set of principles which in itself means nothing. I'm sick and tired of this AGILE tm where people talk about AGILE as it is an actual thing. It is a similar case with QA. This confused me as heck. What do you mean you do your own testing? Every programmer writes a bit of code and then tests it. This is how programming done on the basic level by anyone who had worked on professional level or is at least competent programmer. Isolate process, test it rigorously and then implement code changes. Update code version, make documented changes, update code history on GitHub. Yet, in any serious project there will be tons of little things which is impractical for programmer to detect. It is how code behaves on fringe cases with an outliers. It is how system is programmed to work if user does something unexpected. These things are a job for QA and without QA, you can't produce high quality product period. Programmers have better things to do than to run their own application a hundred times over and they will simply declare project as finished without looking deeper into it. It is quite typical of programmers too to be perfectly honest.In the end it is clear to me that you are just preaching and trying to sell me your stuff. Your examples and reasoning later on gets simply ridiculous and extremely flawed. It is great that we never apply anything too seriously as otherwise our entire industry would collapse on its head.
Re "Agile is..irrelevant." Tell that to Spotify, Microsoft, SalesForce, NASA, Medtronic, ANZ bank, and many other companies that do it successfully. Technical-Agile practices like TDD are well documented in their efficacy. My guess is that your only experience with Agile are with Dark/Faux/Fake Agile companies of the sort I talk about in the presentation.
I had a chance to see Agile and how it is used in Microsoft. Quality of their releases went way down and operating system is in perpetual beta. It is never stable, it is never fixed, it is never finished. Part of it is that they do not care about the quality of their product anymore, but Agile is inherently incapable of maintaining high quality. As a software developer, it is common for me to do a program and then customer mentions that new things X,Y,Z are critical. So I need to work on that too. This ruins ability to plan ahead and to follow strict schedules. Then I need to add software into my support list and provide technical support when it is needed. Then there are some changes and additions needed to be done. We do follow weekly task list, but it is just that. Tasks which we are planning to do on weekly and our annual goals to complete.
@@REgamesplayer you are on the money with that response, I've heard the exact same from MS employees I've worked with. Agile like the original poster said is so vague, let alone to tell humans that timelines don't matter. Using Spotify or any organization who have supposedly figured out how to have a good work culture to produce software and then claim they are Agile and this is the reason why, would be like taking a Org that does Kanban, XP, Lean.. whatever that is successful and claim success because they "fall under the agile umbrella" The only issue with any process, framework or methodology is the human factor.
This guy is a snake oil salesman, he could not develop anything useful and make money so he became a agile consultant, agile is BS, saps creativity, does not account for different learning curves, obviously not developing software as a monolith and doing incremental development makes common sense and does not need a salesman like this guy.
![BOWKYLION - วิงวอน (ex-change) [Official MV]](http://i.ytimg.com/vi/cLdnZWDaO-w/mqdefault.jpg)
This talk is more relevant today than it was 10 years ago!
Thank you very much, it was an amazing talk. As a senior developer I loved every minute of it...
Thank you very much for this talk. I work with some large organizations and I see so many of the dysfunctions that you have described.
I've read many of Allen Holub articles in the beginning of my career almost 20 years ago. This is the first time I see him speaking. Love it. Coincidentally, I already agreed with almost everything in his talk before I watch it.
What an amazing talk! Explains what I've been experiencing so very well
I have watched this video many times over the years and have yet to hear a debunk by a Scrum apologist.
LOVE ... THIS ... TALK.
Today i discovered this talk.... It was like love at first sight... As soon as I saw the title n image 😂
Like this talk very much. It has the right arguments to my feelings about scrum.
I watched this assuming it was fairly recent but it turns out it's 9 years old. I notice nothing much has changed and if anything it's gotten worse.
It has definitely gotten worse.
Holubs comments about corporate culture are, in my experience, very true.
Over the years, I've noticed, not just in the software dev field, but others as well, that when organizations try to implement what real inovators, with very good ideas on how to improve things, have come up with, they often run into an already encrusted culture that is terribly resistant to change.
I for one can be very resistant to change. I understand why that happens on a personal level. From my experience, it is often the case in groups and organizations.
Insightful thoughts ... Thank you
Thank you for a great video. I would like to see what a manager says about this video
April 2019, five years after this original talk and Agile seems to be adopted everywhere. I have not experienced a single well done Agile implementation over the past 5 years. People within the process are complaining they feel less productive, spend so much time defending, deflecting, and gaming the system to appease top management. My question, why are companies still adopting Agile - has this all just been a FOMO movement? I am curious.
Richard Soares there is no such thing as “well done agile implementation”
@@redhotbits sounds to me like a fanatic cult to me. This kind of sects where the Messiah and religion are perfect, but nobody is smart enough to actually do it right. Meanwhile, they are closed in a room about to mass suicide
I've worked at 5 companies. One waterfall, two nothings, one bastardized-agile, and one scrum. The nothings were better than the waterfall, the bastard, and scrum. I've come to realize while the nothings lacked a lot of things that I would've liked added (mostly XP), they were the closest to agile and therefore sucked the least. No deadlines and no reoccurring meetings. If they just added some more XP they'd have been pretty good.
2023 and we are still struggling
I am appalled at the way that Scrum has so completely taken over that everyone is expected to already be familiar with it and, essentially, take it for granted as the default way to manage projects. My shop is basically doing Scrum because that's what everyone does. They didn't even make any visible decision or announce an initiative to go agile, like you would have seen in the previous decade... they give the impression of almost having fallen into it by accident.
The ironic thing is that I actually worked in a more agile way there before they added the Scrumminess. Like, I would start a new project or feature by mocking up a dummy UI, and gradually add working features, with customer (or at least marketing dept) feedback all the way through. Now with sprints and stories and acceptance criteria and all that, it's actually more waterfall than before -- more pre-designed and less responsive to the users.
I hear you! Sprints are a waste of time.
I've been a developer for a few years now and these talks really confirm my feelings when I first got in. I was like "None of this makes sense." It's really disheartening what corporations and etc have done to agility.
The frustration that developers like myself have with Agility within these corporations is that it has been taken as a tool to develop software efficiently and collaboratively and it has been changed into a blunt instrument to beat developers and wring as much code out of them in the shortest time possible.
Chris, that's great that you've coded all of this, but you haven't updated your progress in JIRA once in three days. You may have said something in standup's, but nobody is listening during standup's and you know that! QA is going to flip out that they don't have enough time to get this done by the end of the sprint. The client doesn't even know who you are. We're gonna have to let you go.
@@nickpapagiorgio1600 and then they wonder why they're IT department is in such bad shape
@@chrisfrmatl They don't wonder, they know it's because "nobody wants to work anymore!"
@@nickpapagiorgio1600 Developers are lazy. They said this abou a team of overworking developers, working 12+ hours per day to meet a deadline.
Easy to do when you do inhouse development to provide service. Try to sell things, sell software to customers who are willing to pay EUR millions. You can not say it will be done when it will be done. The customer wants dates, that is your deadline.
Once I saw a video about Agile contracts. It said the contract must be agile, so the developing company can be agile.
This is spot on. Organizations bastardize agile, and make it inflexible. the business needs to understand agile as well as the programmers. Everything needs to be negociable by the entire team. The PO should not be a dictator. Support too must be fully integrated. Everyone on the team should understand the stories from a high level. If the management does not understand agile, it won't work.
I wish I had watched this talk at least five years earlier
This is just Brilliant! Thank you!
9 years later and this is still just relevant. Honestly I will admit that the whole "non-agile corporations will go the way of the dodo" is a bit naive, as they'll fight tooth and nail to continue existing.
From the very beginning it sounds like the corporate people are looking for a one-size-fits-all production process. The other thing on top of the manifesto is "We are uncovering better ways of developing
software by doing it and helping others do it. Through this work we have come to value..." which clearly indicates that there's a learning process there too to make sure that it keeps on adapting to the situation. Fowler said at some point that they chose the word "agile" because ones like "adaptive" had already been taken.
LOL, any documentation not only software! Definitely a must
!
ok to have changing requirements; however, the team has to accept the impact of the change, rather than forcing the change to fit into the timebox.
Allen there are no wrong questions. Mocking sincere inquiry on discussion boards is counter agile which is about sincere inquiry and learning. I have noticed so many arrogant, blustery know-it-alls commenting on discussion boards trying to stunt fledgling agilistas by mocking their sincere questions. Just something to consider.
+Linda Fane I agree, but I don't really know what you're talking about. To the best of my knowledge, I have not been "mocking sincere inquiry on discussion boards." Can you point me at something that you find offensive? If you're directing comments to my keynote, I don't see anything that I've said as "mocking," though I'm certainly critical of the many shops that think that they're agile when they're not. If those folks had asked a few "sincere questions," perhaps they would not have gotten into the situation that they're in.
While we're on the subject of discussion boards. I regularly contribute to the "Agile and Lean Software Development" group on LinkedIn (www.linkedin.com/groups/37631). It's moderated aggressively, so is one of the few discussion groups that I've found where people who are asking sincere questions can actually get good answers (though they occasionally get off-the-mark answers as well - it is the internet :-) ).
THAT. IS. AWESOME.
This was informative and enlightening. Thank you. However in all these different presentations I have viewed, it seems Agile and its components as a whole are really for software or directly related activities. I have worked on many teams that try to use Agile for the IT/Software side as well as the entire process and day to day business operation, But often the business/process side gets pushed further out and/or takes a back seat completely. For many projects it also seems to be overblown and plodding. Some projects fail and/or run out of budget because of the initial, underlying requirements just to start, let alone complete a project. It does not seem to be very flexible and not real world for all projects. These projects are often started and run from the IT/software side out and not enough attention is paid to the real, underlying business; in a nut shell, the actual business operations, and process SMEs are too few or sometimes non-existent until the IT/Software is conceived and decided on. Then it's a struggle going forward because there is not enough flexibility to "retool in flight" as it were. So business side (operations, compliance, regulatory, legal, etc) are not happy and a lot of time was or is wasted. Question 1): Is there a modified
version yet that is designed to focus more on the Business Process first? Similar to classic Six Sigma vs Lean? Six Sigma was a plodding beast, yet Lean is very business and process side effective because they cut out and slimmed down sections that really only applied to manufacturing, not other businesses. Focus is on what is business primary first.... Question: 1) Do you see a possible value in merging some aspects of these 2 methodologies? 2) Or is Agile and components just not applied properly or sometimes used for the wrong project? 3) In you presentation, you said to eliminate documentation, yet Agile is all about documentation and steps which may not really be needed for all projects; often done just because the method dictates it. Thank you again for your time.
As Alan describes near the start of his talk, the essence of Agile should be agility. If your organisation isn't able to respond to changing situations and requirements, it doesn't have agility or flexibility. In which case the essence of Lean is a good place to start: reducing waste, empowering the workers, and using an iterative approach to improvements (kaizen). The processes of Scrum and Agile are the least important parts of business agility.
I've seen him do this a few times. It all sounds so wonderful...until you have people who don't pull their weight (you always do) and have no documentation to justify the way you deal with them.
This does not at all negate the points though. Those people should be shown the door and welcome those that will pull their weight. Most people will.
Love this talk and #noestimates
I like your talk very much. You demonstrate a deep understanding of developing software with agility and forming agile organizations, using the manifesto as a guide. You even get some things very right about many corporate cultures and some in the Scrum community of trainers, Scrum Masters etc.
However, I fear you've been misinformed about some aspects of Scrum. You mention that Scrum is a process when it is a framework. Therefore, your premise about how a 16 page document cannot define a process may be correct, yet it is moot. You can argue that it is wrong in calling itself a framework. I'd think this would be difficult given the flexibility (or, agility) organizations are given in how them implement Scrum. For example, many I know several dev teams that practice the XP methodology within the Scrum framework. This would be a very hard thing to do if Scrum were actually a process, unless it were a proper sub-set of XP processes, which it is not. Likewise, a development team could even practice a very waterfall-like process in a sprint if they wanted to. To be clear, this is a terrible idea, but it could be done (I've seen it).
Also, you mention that once a Sprint starts (paraphrasing), the work to be done cannot change and therefore is in opposition to the "Embrace changing requirements, even late in development..." agile principle. As far as the Scrum guide is concerned, this is not true at all. If things change, the PO and Dev team are encouraged to embrace this change by creating new work, chucking irrelevant work, and even canceling a Sprint if the goal of the Sprint has become irrelevant...even if they are only 5 minutes into a Sprint. They go immediately into Sprint planning to choose the next bit of work to develop.
Scrum needs refinement, sure. It's evolving. Some Scrum communities do feed the corporate "dodo'ism" that exists out there; however, Scrum as written is very agile and some Scrum communities don't sell ballistic nukes that leave corporations in ruins. I hope you see this even if you don't acknowledge it in your talks.
+Jason Knight, Well, you're absolutely right with respect to those people who are doing Scrum according to the Scrum Guide, and of course I agree with your points. My experience is that most of the shops that call themselves Scrum shops follow a rigid process that they learned in some certification program, however. It's really those folks who I'm talking to in this particular presentation.
The Scrum Guide itself is in a strange middle ground with respect to the process/framework thing. It mandates things like the length of the retrospective (3 hours for a one-month Sprint), for example. That's really a process requirement. To me, a pure framework would mandate process assessment and introspection, but leave the details up to the implementation. For a framework, the Guide is awfully prescriptive in places.
Your example of a Scrum shop using XP is another case in point. Kent Beck points out that if you're not doing at least 80% of XP, you'll get only 20% of the benefit. Well, XP has only 11 or so (depending on how you count) practices. So, if you drop 2 of the practices, you're not really doing XP any more. XP mandates an on-site customer as part of the "whole team" A PO, however, is typically an employee of the company, whose loyalties are split between being the company and the customer. The PO is rarely an actual customer. XP also calls for continuous integration and constant feedback (and modifications) made as soon as the on-site customer gives his or her feedback. This could happen as often as hourly. Scrum however, doesn't typically present anything until the Sprint Review. (I won't argue that you could change things, but that's the way it's usually done.) So, given that we're now below our 80% threshold, we're not really doing XP any more. Fix things, and we're not really doing Scrum any more. A conundrum!
You can argue, however, that Scrum encourages process modifications. The Retrospective section of the Guide for example, in no way limits the changes that a team could make in order to improve it's process. Consequently, a Scrum team could decide to eliminate things that are usually central to Scrum (a PO, for example), and still be within the guide. In fact, the team could evolve it's process into something that didn't look at all like what most people call Scrum. Personally, I think that's a good thing, but you end up at a place where you're doing something that doesn't look at all like Scrum as it's usually understood, but you're still calling it Scrum. Another conundrum :-).
So, where I'm really headed is that maybe we're all better off dropping all the labels entirely, going back to first principles---the Manifesto and Principles---and call it good.
+Allen Holub Thank you for the excellent reply!
Well, I learned a little something about XP today. I'd somehow missed that the customer was a member of the whole team. I guess I need to do more homework on this point.
On the customer/PO conundrum...I wonder what would stop a self-organizing Scrum team from making a customer be a member of the Development Team? Probably nothing, so long as the two organizations were agile enough in their practices. Business analysts, while not typically thought of as dev team members, can be excellent additions to the Dev team. There's a place in Tulsa (where I live/work) that is hiring an analyst into a dev team as we speak. I suppose the dev team could practice XP this way and avoid the conundrum by having the customer and PO co-exist on the same team. This gives me an idea for an improvement that can be made on a Scrum Team I'm SM'ing for at the moment. Certainly, the technical practices you describe do not conflict with Scrum's framework, but rather enhance the result.
As for the continuous feedback/review cycle, we probably agree completely on this. Scrum doesn't prohibit XP customer interactions at this frequency, yet it is typically not practiced as such. Furthermore, some myopically interpret the Scrum guide to actually prohibit this kind of customer interaction. This is a result of reader bias and something good coaching can help with. I argue with myself if such coaching statements should be more prevalent in the guide or if this is the role of companion teaching e.g. books, coaching, training, etc.
The Scrum guide is funny, in that it contains the essentials of Scrum and a fair amount of specific suggestions. The 3-hr time boxed Retro for example is not as important a figure of time as the 15 minute Daily Scrum's timebox. Development Teams may jettison the 3 questions listed for a Daily Scrum in favor of more productive planning practices, yet they are specifically offered as a procedural practice. Many will hold dogmatically to the wrong parts of the Scrum guide and miss the irreducible essence of the framework.
I confess the Scrum guide does not make clear what parts of it are immutable and which are suggestions. This was confusing to me as a beginner until I dug into it and searched out those like Steve Porter over at Scrum.org for clarification. The essence of what Scrum is much more of a framework than the guide may present. Clearer definition of the framework vs suggestion parts on the Scrum guide would be a huge help to many IMHO.
I still wonder how to charge for this kind of job.
I know that most (if no all) of the points made in this talk are real, but customers don't know what they need or want, but also they hate to pay for something they don't know they need or want.
if that make any sense.
So what is it? monthly fee? charge on every requirement, no matter how big it is?
+Marcos Vargas Moran: I think your best bet is to make your contracts match the way you work. That is, the story is your basic unit of value, and charge by the iteration/sprint. (I typically size my stories so that they take an iteration---about two weeks or less---to complete). Sit down with the customer at the beginning of the iteration and help them prioritize the work at hand, pick the highest-value story and contract to build that. At the end of the iteration, you get paid (immediately---long delays violate the basic XP value of "respect." If they can't do that, work against a retainer that your replenish periodically), and you deliver the software. Use your "definition of done" as the acceptance criterion. That approach may or may not work for a big consultancy, that wants to land multi-million-dollar contracts, but it's worked for me as a small contractor. For one thing, it's really in the customer's benefit to work this way because it eliminates the up-front risk (promising a big lump of money to an unknown quantity to produce a not-well-enough-defined product).
+Allen Holub Ok, thanks. I will try to do that from now on, But here in Chile they like to pay when the "whole" thing is done, yes that one they cannot put their finger on for requirements unless their are seeing it, but i'm always trying to push the iterative approach.
I'll use your last statement about eliminating risk, maybe that'll work.
Salutations.
@@mvargasmoran how it's going?
This is gold! why we suck at anything we do
33:00 I love the idea of the "business people" being actually on the team, but in my experience they're the "business people" BECAUSE they're not developers, and their main job is client interaction, while we're building the tools for the client. So if they're on the team, what are they doing when we're not asking them questions (since they're not developing). They must be doing their "regular" job. What's the third ideal way between "not on the team and are always in meetings for their 'real' job" and "on the team and bored half the time while the rest of the team is writing code"?
Well, the XP way is to get the client in the room and the "business people" messenger owls hit the road. Failing that, then the business people ARE the customer, and they do their job from the team's office.
Big corporations like Boeing or General Electric need to do big projects of high complexity and there is no place for those "bubbles" of teams you just trust to do the job - aviation, industrial equipment or medicine are about solid requirements, which you have to follow or people gonna die.
But. In all cases where you can go over the process - you should.
And THAT IS to be Agile for big corporations: not 'always', not 'never', but when needed.
Up-front architectural design is very important in safety-critical systems. On air data inertial reference units, there is partitioning in time and memory space. These partitions both produce and consume data used by other partitions. The lists of producers and consumers of data are in xml files. This is done to protect the most important data producers in the system.
For example, the sensor monitors like the gyro life monitor is a "nice to have" partition that is used for preemptive maintenance to replace a part before it fails. The inertial reference partition that produces the pitch, roll, and yaw angle of an airplane produces data that is safety critical. By using this partitioning, if the sensor monitor gets stuck in a while loop, it won't prevent the inertial reference partition from producing its data.
The air data component that produces altitude and airspeed is on a separate circuit card, with a different processor and different compiler to eliminate any potential common mode failure source.
On medical devices I have worked on there are similar architectural decisions that have to be made up front. Usually there is a "front end" GUI and a "back end" embedded component. The back end is safety-critical and tested to a much higher standard and it is understood that since the front end isn't tested to the same standard, the back end validates any messages received from the front end for safety.
Up-front architectural decisions like these don't fit nicely into these infantile little sprints and daily scrum meetings.
Unfortunately, managers are starting to inflict agile scrum on products that have the potential to cause plane crashes if not functioning properly. In 2022, I went back to a former employer where I have worked numerous times in the past as a contractor. They build Air Data Inertial Reference Unis for passenger jets. They weren’t doing agile scrum, and life was good. The manager who hired me is someone I had worked for in the past, but retired in early 2023. He was replaced by a younger manager who wanted to make the team be agile. The lead engineers were not happy, and for a good reason. It is not compatible for this product line. They brought in agile coaches to teach them how to be “agile.” When these con artists told them all the things they need to do to be agile, the engineers pointed out that after following their so called process, they didn’t have any of the documents required for FAA certification, like objective evidence of the requirements based test coverage, a traceability matrix, independence of code review and independence of test, etc.
There was another meeting with the “agile transformation” on the agenda. Contractors weren’t invited to that meeting. When the meeting was over, saying my coworkers were upset is putting it mildly. According to my coworkers, they pointed out that when they are in the testing phase of product development, problem reports are written, adding to the workload, making it impossible to stick to a “burndown chart.” One of those flimflam artists (an agile coach) actually said, “Just delete them. You don’t need them.” A coworker replied, “We could go to jail for that, and you could go to jail for ordering us to do it.” Keep in mind, this is a product that is regulated by the FAA, because it can cause plane crashes if it isn’t working properly.
When a problem report is written, the first step in the process is for systems engineers to do an analysis to determine if it is a safety issue, like something that could cause and inaccurate altitude reading, or a more minor issue, like a linker directive that allocates less memory than a requirement document specifies, but that has been determined to be adequate in the worst case of memory usage. The safety issues are given top priority and cannot be deferred to later releases.
From what my coworkers described, it didn’t sound like the agile coach understood the ramifications of deleting problem reports on a regulated safety-critical product. It sounded more like it was a person with no experience in this type of product or maybe even in the engineering field in general, who thought that because they took a two-week agile certification course, they were qualified to advise people with real degrees from accredited universities and years of experience in the industry on how to do their jobs.
PREACH!
The Scrum framework (not process) was a foundation for the Manifesto. Don't blame the tool for the failings of people. Scrum is not perfect, but it's proven when utilized correctly. Remember that corporations are a collective of people....that's why "Agile" fails.
Well, there's Scrum and there's Scrum. The cargo-cult Scrum that you see in most organizations is not Scrum, as presented in the Scrum guide, and Scrum itself, even when done perfectly, is not effective without something like XP that defines how to do day-to-day work (my source for that statement is Sutherland himself). Interestingly, XP by itself is just as effective as XP + Scrum, so I do wonder what the value proposition actually is. I certainly agree that Agile(tm) fails because of people, but that doesn't mean that Scrum is the only or anything like the best framework to be using. My real worry, however is that when people say that "Agile" fails, they aren't doing anything even remotely Agile. Simply doing the things in the Scrum Guide in no way make you Agile, so in that sense, it doesn't work in the way that people imagine.
The presentation is great in regards to cargo cults, organization friction, philosophy versus Agile(tm), etc. Scrum is not perfect, and I agree that it works best with many of the XP practices. But I'm not here to defend the framework; I prefer pure flow.
Without the Scrum bashing, it might be worth sharing in some corporate environments due to the previously noted content. Scrum is often the best gateway to introduce the agile philosophy and iterative & incremental execution.
There's a lot of ignorance around the concepts of agility from executives to technologists. Ideally we could create change from the basis (manifesto); in reality it often has to start with something more familiar to the conglomerate current operation. I'd be glad to be proven wrong on that point!
Thank you for engaging. I always take something useful away from your content on any platform.
(Apologies for mistakes. Tired. On a phone. But wanted to reply. Thanks.)
Thanks Alan! I always learn something from everybody's comments, so I welcome them. I'm hoping that the Agility video class I'm putting together (agilitry.com) will help with the on-the-wrong-track situation. I'm just about done with the first (business case for Agile) module, which discusses the core issues without any "Scrum bashing" :-) at all!
Allen Holub LOL, I understand the frustrations. Looking forward to it!
@@AllenHolub Perhaps the value proposition is that scrum can apply to domains beyond software development? ... Enjoyed your presentation. Thought it might be interesting to talk about how Spotify started with scrum and moved away from elements of it as they inspected and adapted. The whole individuals and interactions over process and tools thing :-)
Great presentation and good points!
Regarding SAFe - I believe the PI increment from SAFe (having teams work together and solve dependencies) is helping teams, collaboration does help teams a lot and changing the organization to support your values will help large organizations (value streams).
Most companies that I have been working with is having the problem that you talk about - when management does not support Agile, it is impossible to change things, if the top of the company does not understand and support it, it is impossible to make the changes.
Scrum it's a framework, not a process, in fact it acts a container of process or practices system like XP. Thats is clear said in the Scrum Guide and you can see a successful combination of Scrum and XP in the book "SCRUM AND XP FROM THE TRENCHES". I don't agree with the Allen Holub's analysis because it's not consider that Scrum it's just a framework and not a methodology nor a process. By the way, Scrum artifact don't require any tool an no one it is suggested in the Scrum Guide.
The thing is, it doesn't matter what the intention of the inventor was and what Scrum really is. If people who have not understood that Scrum is not a process or a method use it as such with the same control mechanisms from the past (budget, time, ...) because they have always done it that way, it does not help to deliver value to the customer. We don't achieve agility / flexibility by stubbornly following the things that are written on those 16 pages without questioning them. If it doesn't work we have to change it, and we have to change it right away - not after 14-30 days.
Companies that have only worked according to processes and control will not make the leap. They don't understand how their own system needs to be changed, which is what creates the cultural conditions for the successful use of agility in the first place. Companies equate Scrum with Agile because they don't want/can't let go of their old systems that still focus on control and management. Even Schwaber/Sutherland write "management is waste". Scrum is just one among many ways to develop products iteratively and has nothing to do with agile.
The agile manifest consists of 50% people thinking, the scrum guide says nothing about this.
Agile is like pop psychology. The most obvious concepts turned into something ugly.
"Make our code, test it and adjust for an easier time in the future for changes"
I'm totally following you on this, but we part ways at 27:06 ... ask the customer what they need to do. Let's set the stage here. I am a one-man, self-funded startup operating out of a home office, building a speculative product to satisfy what I think is a need in the market. At this stage, THERE ARE NO CUSTOMERS. There is no one to ask. I've tried for many years to do the Lean Startup thing, and I've just never been able to make that work. The problem for me is you go out, talk to prospective users, and the feedback is very vague. Some people don't want to hurt your feelings and tell you it sounds interesting. Other people tell you how they solve that problem now. Blah blah blah. All of my friends, especially my sales and marketing friends, tell me to do the validated learning thing. Here's the thing though ... not a single one of those people have ever built a successful software startup from scratch. It's very difficult to change the world nowadays. It's very difficult to create a product that is so innovative and disruptive that when you tell people about it before you've ever built it, they start shaking. 30 years ago you could do that, but now, it's just so hard to do. My experience is you just never get anywhere when you try to do early validation. When I work on a particular domain, and I've thought about it a lot, I've thought about what I would want, I've researched what's out there in terms of competition, and yeah, I've talked to a few people too, this may sound conceited, but I will then know way, way, way, way more about that particular thing than anyone I talk to. Any objection they tell me, I've already heard it. Any feature idea they have, I've already thought about it. It's just very difficult to really learn anything. End result is we wind up at an impasse ... I think the world needs this innovative thing I have in mind, and most people I talk to think their current way of doing that thing is good enough. Ok. Now what? Do you build it or not? No one solves this problem for me. Agile, Scrum, Lean Startup. Early Validation. No one solves it. How do you find latent, untapped demand in a saturated, overcrowded world?
Interesting experiences, thanks for sharing!
Disclaimer: I have never tried to bring any software related stuff to the market. I have some experience with software innovation, so your experiences feel familiar.
From what you write I understand that you tried to bring innovation to the market. And that the end users end up not understanding it. Especially from your last sentences I wonder what makes you think that you know better what someone needs than they do themselves?
What I understood from reading The Lean Startup was that asking isn't going to tell you anything. I also remember someone saying that "I like that idea" isn't what you want to hear, it's "I'll pay you $100 for that right now *grabs wallet*". I think the thing is to get a MVP out there, which is (just) enough to make someone make a real consumer decision: will I pay for that?
@@RoelBaardman Thanks for the reply. I like talking about these things. Well for me, I've been working on software development tools for 30 years, having previously started and sold 2 startups in the space. That, plus being a software developer myself, I'd say, yeah, I'm pretty confident that I have a good handle on what's needed out there, and probably know the whole space much better than any one customer that I'm likely to interview. The product I'm developing is a new type of documentation and search tool for software developers. So that's the thing about a documentation tool, it's necessary to manage software complexity, there is demand for it in the market, but no one is going to start doing back flips down the hall when you talk to them about a documentation tool. There's just going to be a certain amount of natural apathy. That doesn't mean it's a bad idea, it just means there's a limit to what you are going to learn by interviewing customers. So what makes me think it's a good idea? First, the relative success of Confluence. I used to work at Atlassian, so I have a pretty good idea of the strengths and weaknesses of Confluence. Second, the success of SourceGraph in code searching. The tool I'm working on is like if Confluence and SourceGraph had a baby.
@@RoelBaardman Quick story. I was talking to a good friend a few years ago about note taking for developers. Do you use Evernote? Do you use OneNote? What do you like/dislike about them? Etc. And he was like "Nope. I don't do note taking. Don't need it. I don't have a hard time remember what I need to remember. I use my IDE. If I need to remember something, I jot down a quick comment in the source code. I don't think I'd ever use a note taking system." At that time he'd worked on the same project for 20 years. Then one day he got put onto a new project, and he was like "OH ... MY ... GOD!!! So much new stuff to learn! I can't keep it all straight. I had to start writing it down so I can look up all these details more quickly. OneNote is my new best friend!!!" Aha. See. Aha. That's the thing. People don't have this problem until they have the problem, then they get it.
See, he even poo poos documentation in this video. Not needed. It's waste. Blah blah blah. I mean it's a little hard to buy this theory. Isn't the entire World Wide Web just one giant hyperlinked electronic document? HTML? XML? XSLT transforms? Typewriters? Word processors? Spreadsheets? For not being needed, we've sure invested a heck of a lot of resources as a society into electronic documentation.
@@kdietz65 Judging from his comment here, I think that he is talking to the companies that just do the rituals. That write documentation that nobody reads.
th-cam.com/video/HZyRQ8Uhhmk/w-d-xo.html&lc=UggkShi27U2yI3gCoAEC.89QCWJZPjVC89QZ7V52_TK
I've been at several of those companies. I saw someone write a document "because every project needs this document". The document was even supposed to be written up-front, but he wrote it days before the project was finished. Pure waste.
I do not doubt that you're seeing a real need, as I think scratching your own itch is a good strategy to build something... you have at least 1 customer. :-)
I think however you are betting (that other people will pay money for it), and it is this that Validated Learning aims to eliminate.
I can imagine VL doesn't work to well for pushing innovation, especially if you have a hard time finding early adopters (people willing to try something new and change their habits, just because it's new). Then VL will only tell you that you're wrong. A change in habits must take place if you're doing something in a radical new way and not "a better old way". If someone's not willing to make that change, he's probably not your customer at this point.
I've always found it interesting that Apple didn't do focus groups either, I think for the same reasons you state.
Agile is anarchism hiding in capitalism.
This is so wrong if you think documentation is not necessary, nobody reads it and can be substituted in some way. DEAD WRONG!
I took issue with the documentation thing myself. He did specify it's useless if "no one will read it". I think README.md documentation has value, we know that from looking at any open-source library. People read that. Most people won't touch your OSS library if it has a blank readme. How do I install this application on my local, what are the steps to deploy, is there a deployment checklist? You need processes (he said as much) and what good are processes without documenting them?
the fundamental lie of agile is that the changeability of software depends on attitude. it depends on your compiler.
Amen
Like always and your tone on Twitter... blaming and "I know it better then you guys". I'm getting sick to death of your negativism.
Keep positive dude!
Yes, I'm indeed negative about fake/faux/dark Agile. It does a lot of damage. Are you supporting that?
He first said that Agile is not about processes and then he says that "It's agile not to have a QA department". The Agile manifesto doesn't say that at all! There are cases in which QA is pointless, there are other scenarios in which QA is fundamental. The Agile manifesto says that you have to be flexible depending on what you are trying to implement!
I think you're missing the point. Having a specific department for a specific function is an opportunity for additional friction/communication cost. It may very well be necessary, but it might not. For QAs, why have a seperate sub-organisation when a self-organized team could potentially take care of it on their own, or god forbid, automate the tests.
Don't be fooled by the plaid shirt. There is a lot more ideology here than meets the eye.
First of all, the part of the software industry mired in requirements churn is large, but hardly the whole story. Yes, software is eating the world, but no, not _all_ software is eating the world. This later class often has requirements that are either a) surprisingly stable, or b) not customer apparent. One can fiddle with semantics and declare any sufficiently fickle stake-holder who gives a shit as "the" customer, but it might be simpler just to admit that sometimes software is a coherence-centric endeavour, and these cases are best managed as such (so much of this work has now entered the water supply that we tend to forget it exists). By that view, agile is only "the best way" to deliver that software for which agile is best suited. Ta da!
Second, "the" customer is a fiction on another level as well.
One of my favourite clips ever, in which Bryan Cantrill excoriates Unix "tail" illustrates this.
th-cam.com/video/vm1GJMp0QN4/w-d-xo.htmlm31s
If you're in the business of attaining deep reliability, you _are_ your own customer, whatever other customers you choose to acknowledge. It's not unlikely that your long-term needs are entirely orthogonal, and impractical to story board. The way Unix tail presently works is the product of distant, dusty guru meditations that either swallowed the blue or red pill. There _is_ no story board for choosing between pills. Again, one can fiddle semantics and declare that whatever feedback dominates the outcome is the "customer" feedback loop. But wouldn't it sometimes be simpler to just admit that there _are_ circumstances where other loops gain preeminence?
Third, as someone who struggles with N24 sleep disorder, the ability to show up bright-eyed and bushy-tailed on a consistent basis day after day is something I've requested from Santa going on thirty straight years. Holub basically said I should get myself a different profession. Nuh uh. I finally learned to cope by becoming more personally agile, to whit: _not_ imposing any fixed expectation of myself on any given day. Thankfully, there are still niches out there where ultimate coherence trumps personal vagaries or I'd be so fucked, despite all my many years invested.
Fourth, I got a good laugh from the juxtaposition of "simple" (one of the core principles of agile, procured from the "I know it when I see it" department) against the backdrop of "agile won't work unless the entire corporation is perfectly impedance matched around the agile philosophy". Hmmm, nothing spells "simple" like waking up to discover that you've just been tasked with refactoring Big Corp. Here's a tip: cooperation is _never_ simple. When you're happily in the sweet spot, one gets that oh so simple feeling-it's delightful, it's delicious, it's de-lovely. But when you're _not_ in the sweet spot, one can hardly tie two shoelaces together without spitting nails.
Finally, concerning Spotify, the IT consulting industry is littered with showy exemplars of one methodology after another, where it turns out that showy exemplar succeeded not so much because of the chosen methodology, but because they were a first-class assembly of talent (who feasibly could have built the system with a methodology based on toothpicks, duct tape, and C++). Even where one can recruit a similar caliber of people-they don't always exist, and supposing they do, you might not be able to afford them-even _with_ these chosen few in hand, it isn't always possible to replicate these happy accidents. Corporate chemistry, it's a thing. Plus, as we all know, often you find yourself going to war with the army you have. Double plus: as any good economist knows, a _lot_ of social conventions work in Sweden that don't work so successfully anywhere else. We could likewise argue that the "cushy" Norwegian prison system is a great model for everywhere else, too. Realists, however, acknowledge that the Norwegian prison system leverages a unique combination of economic and social capital. And many other countries don't even _want_ those progressive outcomes to begin with. America is not Sweden. (If Spotify is forced to move to New York, they might discover that America is _better_ than Sweden, or they might discover their fabled "agile" corporate sauce failed to navigate the voyage over.)
Apart from Holub's consistent discourse posture of playing fast and loose with nuance, this is actually a pretty good talk. I came away understanding Agile way better than I did before. Just don't be fooled by the plaid shirt.
It sounds like agile just isn't suited for all software projects. Going without a QA department is pretty much impossible in the video game industry in particular because most gameplay mechanics are so inherently complex and interact with *every other mechanic in the game* in so many different ways that it's practically impossible to completely test a video game at the developer level, even with automation, even with very smart developers who understand the entire product well enough to imagine every possible case that they would need to test. There's just too much emergent complexity in a video game and devs can't possibly hold all of it in their heads, ever. And then there's that designers build the game around the software as it is when they're working on a particular piece of it... Some readers may recall that StarCraft: Remastered couldn't fix pathfinding bugs from when the game shipped because they had become part of the game balance!
And then having the customer in the room is also pretty much impossible in gamedev, because "the customer" isn't any one person or group, it's millions of consumers, many of whom are likely to be actively hostile to you personally. Going without deadlines is also impossible; ship dates are important for coordinating with marketing plans and delaying a game release once it's announced is *nearly impossible* (it can be done, but it pisses literally everyone off and loses the company customers). Not having a process or accountability when engineers are the minority of people who are actually building the product would mean that there would be even more delay and waste in these things than there already is. "Trust" is pretty much impossible when your team is hundreds of people and *needs* to be, because your actual product is decades of person-years in size and most of your team is not devs. And self-organizing teams has also been shown to be a recipe for toxicity and company paralysis (see: Valve Software). Small agile teams cannot overthrow the big industry players because success correlates to a) marketing b) targeting an experience that indies cannot compete with, so Darwin/Marx cannot "set things right" here. At least, by way of agile development.
What am I supposed to tell the scrum enthusiasts in the game industry, I wonder... Based on this talk, it surely can't be "do actual agile", because that won't work for us...
This guy is delivering the 'red pill' for Agile.
I thought agile was BS, then I watched this video and now I know for certain it's BS. Most of these points not only don't happen in real life, they shouldn't happen. Best example, no deadlines, that means your software is not important.
It sounds to me that you already decided what you wanted to hear from this talk. What he said was, if you have a deadline, and your projections don't match up, either adjust the scope, or adjust the number of people. But don't work your developers to death (or burnout), get a sustainable pace.
Watch again
I've tried this on big programs with many agile purists, and it's a complete failure. It's a cult mentality. Rituals and philosophies do not directly move you to success. It might work on small simple apps, but that's because any method will work in small simple apps.
@@thierrydussuet718 "Adding people to a late project makes it later"
That's one angry developer.
Agile at its core is so vague and obscure that it is irrelevant. It gets only meaningful when it ironically starts following the process. It might be SCRUM or any other version, AGILE are set of principles which in itself means nothing. I'm sick and tired of this AGILE tm where people talk about AGILE as it is an actual thing.
It is a similar case with QA. This confused me as heck. What do you mean you do your own testing? Every programmer writes a bit of code and then tests it. This is how programming done on the basic level by anyone who had worked on professional level or is at least competent programmer. Isolate process, test it rigorously and then implement code changes. Update code version, make documented changes, update code history on GitHub. Yet, in any serious project there will be tons of little things which is impractical for programmer to detect. It is how code behaves on fringe cases with an outliers. It is how system is programmed to work if user does something unexpected. These things are a job for QA and without QA, you can't produce high quality product period. Programmers have better things to do than to run their own application a hundred times over and they will simply declare project as finished without looking deeper into it. It is quite typical of programmers too to be perfectly honest.In the end it is clear to me that you are just preaching and trying to sell me your stuff.
Your examples and reasoning later on gets simply ridiculous and extremely flawed. It is great that we never apply anything too seriously as otherwise our entire industry would collapse on its head.
Re "Agile is..irrelevant." Tell that to Spotify, Microsoft, SalesForce, NASA, Medtronic, ANZ bank, and many other companies that do it successfully. Technical-Agile practices like TDD are well documented in their efficacy. My guess is that your only experience with Agile are with Dark/Faux/Fake Agile companies of the sort I talk about in the presentation.
if "It is how code behaves on fringe cases with an outliers", then your aforementioned tests are insufficient
I had a chance to see Agile and how it is used in Microsoft. Quality of their releases went way down and operating system is in perpetual beta. It is never stable, it is never fixed, it is never finished. Part of it is that they do not care about the quality of their product anymore, but Agile is inherently incapable of maintaining high quality.
As a software developer, it is common for me to do a program and then customer mentions that new things X,Y,Z are critical. So I need to work on that too. This ruins ability to plan ahead and to follow strict schedules. Then I need to add software into my support list and provide technical support when it is needed. Then there are some changes and additions needed to be done. We do follow weekly task list, but it is just that. Tasks which we are planning to do on weekly and our annual goals to complete.
@@REgamesplayer you are on the money with that response, I've heard the exact same from MS employees I've worked with.
Agile like the original poster said is so vague, let alone to tell humans that timelines don't matter.
Using Spotify or any organization who have supposedly figured out how to have a good work culture to produce software and then claim they are Agile and this is the reason why, would be like taking a Org that does Kanban, XP, Lean.. whatever that is successful and claim success because they "fall under the agile umbrella"
The only issue with any process, framework or methodology is the human factor.
The first guy who should lose his job is the speaker
This guy is a snake oil salesman, he could not develop anything useful and make money so he became a agile consultant, agile is BS, saps creativity, does not account for different learning curves, obviously not developing software as a
monolith and doing incremental development makes common sense and does not need a salesman like this guy.
I was watching to this video and tears of joy were falling down on my newly received SCRUM certificate 🥲