Absolutely brilliant. Having experienced practically every single dysfunction that Allen describes, I found myself vigorously nodding my head in agreement. Thank you Mr. Holub. Pure genius created in the kiln of experience.

Impressive. The culmination of failures that my organization have been going through, expertly laid out in this video. It's like finally getting a diagnosis on an unexplained disease. I hope to find more material from Allen Holub. Thank you!!!

This is tremendous. I've seen many places that want to do "scrum" but they're not "all in". The business doesn't understand agile just like Allen talks about - they are the Cargo Cults. And they HAVE to understand from the top or it will always be modified waterfall. You can't have an IT BA play the role of Product Owner just because the business doesn't understand (or doesn't want to understand) their role. This is great stuff.

I work for an automotive OEM that is undergoing an "agile transformation". Feels like I have been in a project management twilight zone for the last 9 months. Listening to Allen has been so refreshing as before I was struggling to make the distinction between SAFe, Scrum and the Agile philosophy they keep trying to sell it to us as. What we are essentially using is scrum on steroids. Watching the project leads analyse the burndown chart based on arbitrary story points, using an estimation system that means an 80 point sprint could be anything from 1000 days work to 80 minutes gives me hernias in real time. Amazed that this thoughtful study of the agile process and how its being perverted was 7 years ago! Sometimes it feels like no amount of resistance can stop the new religion of SAFe.

The vision portrayed here is very much aspirational, which I guess is his point. If you want to do Agile as he described it (meaning being actually Agile) then you need a very experienced team (that rules out the vast majority of teams) and, yes, the right company. Saying that 'deadlines don't exist' or 'there is no project manager in Agile' is simply going to have senior execs rolling around on the floor laughing their heads off. Unless you can find a way to do Agile within the context of a company that uses formal project management practices then forget it. Most of us have to work in the real world, not in some sort of software development utopia. One point that cheeses me off is the way Scrum has become a formal process which doesn’t fit in every situation. But a very good presentation nonetheless!

The most damning point to make against scrum(or most agile methods), is that, despite the fact that software engineering is an *applied science* , and we are all therefore supposed to use scientific principals when doing our job, despite this, **there isn't a SHRED of empirical evidence to support so much as a single claim made by scrum(or any agile) proponents** . This relegates scrum to the SAME category as aliens, bigfoot, Q conspiracy, flat earth, etc. That is, a category, for claims that are made, that are devoid of **empirical** evidence to support them. Belief in claims devoid of evidence, is by definition, **irrational** , and is borderline delusional. Being the opposite of rational, it is therefore the opposite of science, and therefore, NOT applied science. The most common excuse you get is, "agile is beyond the abilities of science to study" . Which is of course COMPLETE nonsense. The ONLY things that cannot be scientifically studied, are phenomenon that **do not manifest into reality** . They like to ignore that case studies, are considered the poorest form of evidence in science. They also like to ignore, that the handful of studies done into the matter, **show no advantage** to agile techniques. Fun fact, other things that are "beyond science" are aliens, astral projection, and bigfoot ROTFL. It is also important to note, that agile consulting, is a **multi-billion dollar industry, and it is ONLY growing** . So billions of dollars and hundreds of thousands of people stand to lose a lot if this little factoid about lacking evidence, is paid any attention. Quite the opponent. **One would think, that the biggest selling point to agile, to a bunch of scientifically minded engineers, would be empirical evidence of the claims.* "Here is undeniable proof it works" . "Sold" . Engineers use what works. **However, have you noticed, despite having billions, that industry refuses to provided any proof of the claims, by supporting the studies?? Now why do you think that is hmmmmm ROTFL????** My favorite argument "against" me, is "Well, that is just BAD agile" --> ROTFL ROTFL My favorite response: "For a system that is claimed to be superior, it is certainly inferior to ALL other methods, with respect to its ability to get it right. That is the opposite of superior, especially since none of your other claims about agile are supported by evidence."

I just spent two days in SAFe training -- telling us that the way we were working before wouldn't / doesn't work. We work in an interative way..works for us and our customers, our customers don't want a release every day or even every week. Our management thinks that we'll make more money if we're Agile..which isn't true either. Our biggest problems is no one wants to write or commit to decisions or requirements. Anyway..we're off to see the Wizard of SAFe.

It is even worse for me. I am the hardware guy who was forced into pseudo-Agile and it is nothing more than a burden of overhead. I am a resource to a Scrum team doing the increment/sprint stuff. It is exactly as he said, waterfall with Agile faceplate.

I feel this is right on, from years of experience developing in businesses of a wide variety of sizes and industries. I've seen it done right and I've seen the counterfeit way described. I think the counterfeit Agile that Allen warns about is the thing that gives Agile a bad name to people who are against Agile itself.

I was in datacenter IT for a while and this is so horribly true about corporations... It was so hard to actually get work done while; filling out cap labor forms, figuring out how to properly submit expenses, sitting in on bogus calls, and conforming to the latest corpo policy every 6 months. Madness.

What an amazing speech..!!! This is so close to what I am witnessing every day, in my company.We started agile 5 years ago, and we gave up. Now, we are in a stateless mode, wandering....

I like how he mentions the importance of culture and trust throughout an organization to a successful agile implementation. There's a lot of wisdom here. In fact, these might be prerequisites. In other words, if you want an agile transformation, don't start by forcing people to attend daily status report meetings or do some other aspect of Scrum dogma. Instead, focus on building trust.

The company I work for has implemented agile this year. I am in the middle of the training now. My impression is that instead of making things agile, it will multiply the administration effort for every single thing we do in the company. I might be wrong.

@14:41 For the record, since this is the most replayed segment of this video: that image is a complete lie. Spotify never worked like that, and their attempt to make it work like that was an abject failure. Spotify never successfully scaled Agile at all, and quickly abandoned it. And it wasn't a matter of whether Spotify really wanted to give full autonomy to teams and let them self manage and have a horizontal structure and no middle management etc etc. They genuinely wanted to do all of that. Unfortunately, no matter how good your intentions are, most developers are simply not mature and competent enough to learn and understand how to develop in an agile way. Adhere to the discipline of TDD? Good luck getting a team of hundreds to adhere to the discipline of showing up to work. The closest model of agility at scale is more like Amazon. You give the STO total autonomy over one or maybe two separate two-pizza teams. But the organization is otherwise entirely hierarchical, and the STO implements whatever organizational structure is needed, with heavy Organizational Network Analysis to determine the impact of organizational structure on deliverables.

Great talk. Might better have been titled: "Why you'll probably never see Agile development in the real world"

Quite a lot of agile tools and frameworks are useful for a transition period. Also in the big scheme of things, agile will probably transform come some years down the road. It's born out of a response to a more uncertain market and changing requirements, and as such will have to change as that landscape changes.

This is so true. It's madness nothing else. This guy makes total sense. The day you are able to change the mindset of your workforce, the Agile method will work.

Very nice talk and amazing how this is still relevant in 2022!

This was a great talk. I have 1 issue with your "attack" on JIRA or other tools to replace the whiteboard. Currently (COVID) there's no way to do face-to-face, so no physical whiteboard is going to help you. You HAVE to have a tool that everyone can access to see progress, issues, ect. online. If everyone's not in the office, you can't work 100% the way you describe. I agree, co-located is preferred, but if that's not possible, you can still be Agile. My team's performance in the last year of WFH proves this.

Ugh I’m a Scrum Master and somewhat of a coach and have been doing some “introductory training” on agile for my team. Just found this video and it explains everything I have been saying but in a way more succinct way. I hope the author doesn’t mind, because they’re now on my reference list!

Even the best plans of process and technology, laid out by professional engineers and project managers with decades of experience can be sabotaged by toxic culture of Agile, resulting in substandard quality of software: The very idea of incremental development, where in order to create a car, first you need to make a bicycle and later just add two wheels on, is incompatible by any minimal standard of engineering.

Unfortunately Spotify didn’t implement the ‘Spotify Model’ in full - it was more aspirational. The model also didn’t scale for them. At least that’s what I understand from various Podcasts and Blog posts from people claiming to have been involved. So this talk, while interesting, has it’s own Cargo Cult moment.

Couple of things. Irrespective of what Agile purists say, Project management continues to be required in lots of organisations especially in service organisations as they have to go with the process of the client organization and lots of these organisations are not agile enough. They still define projects, continue to work on triple constraints. In turn these service organisations have to follow the suite. Second, Scrum is not a process. Scrum is a process framework within which you can employ various processes and techniques. Having said that, definitely one doesn't have to follow Scrum to become Agile. As long as one is following Agile values and principles, one is agile

So far I only have experienced Agile once....and it wasn't a good experience. I could've been alot more productive but I kept getting stopped because *"that's not Agile, you have to create a Userstory for that first"* so instead of implementing features I knew we would need, or fixing/tweaking stuff I knew needed to be changed the project often got stalled just so the clients could confirm in the next meeting that "yes, thats indeed stuff that needs to be done" As thats my only experience with it I'm not sure if Agile is bad, or if it was just very poorly implemented, in any case it was anything but *agile* .

The only thing I question in this presentation is the documentation. Now it could be how companies do Agile but when people ask what is that doing and why from a business rule perspective or explaining why we made a decision and not another has been beneficial. The biggest failure I have seen in Agile is it doesn't take into account how the puzzle piece fits into the entire jigsaw puzzle and most people don't care. I had a requirement where they wanted to manage turning off connections to certain locations. They list the one internal challenge as it changes the relationship with a internal system. I raised it impacted an extract to a 3rd party system that the B2C custom used to build those relationships with that group it was like showing a caveman fire. It blows my mind that people stay in the silo but don't have a basic understanding of the larger eco system.

Just came across this after not seeing it for 4 yrs. Still rings true. LOVE the point about the QA department....

I love the point on Friction. Dev manager goes to management with an update and they want more faster and do not care about the ethics of reasonable code. The negotiation sucks so lets fire the Manager and hire a couple 20 year olds who have never written a line of code to get devs to make daily promises on itty bitty tasks in which the backlog excludes any kind of infrastructure work, security, etc. Problem solved ! No Friction and if anything goes wrong we fire a dev or 2. If the a hacker gets you and there is a 10 million dollar law suit, you can go to the next company and continue the cycle.

The best. Most direct. Most concise. Most clear.

it's always refreshing to see when someone speaks the truth.

I think a lot of the problems relate to misleading terminology in the agile movement. Just use scientific terms like research, experiment, empirical evidence, etc. and people will finally understand what the hell we're trying to achieve in software.

some really good points. However we should not confuse process owned by teams and teams of teams vs. frameworks guiding to live according to values and principles

I think why i am always skeptical of joining any new tech company or startup boils down to if there are actually reasonable programmers there that know arbitrary estimations don' t work. agile is really unpleasant to do especially when you're a creative developer with ideas

I wish more agile people would talk about software in embedded. I work in the automotive industry and it's a shit-show. We have hard deadlines because of strict contracts, and most of the time the quotation process is made by a different team than the one who actually develops the project. For some reason the OEMs don't like it when their 2021 model year car is going to be delayed until 2022, because the $100 million dollar quotation was done poorly.

Very good presentation. It is really useful. Thanks for sharing

I agree with every single word exept customer management. Sometime customers could be milion of people you need to manage the interaction in a very structured way.

So many CEOs and MDs need to see this.

Great talk. The point to be noted is this guy is against agile methods but gives thumbs up to companies going agile

I agree with a lot of what you say here, although complex systems that require functional safety certification can't work this way.

Good look without the QA department in big/middle corporations. I find it very amazing how devs think that they are centre of the world, and dont understand other contributions. To be agile at the org level you have to define your domains and give them accountability, exacly as they give it to you as devs. These are the WoWs defined by Smart. The agile manifesto is irrelevant if you don't apply a second layer of lean management to this concept. This is what many devs dont get, it only talks about what you deliver, not how you do it. The how is always a lean process and must be well-defined at the process, role and tool levels. There is only 1 way to push to prod. If you have 300 teams, you cannot allow 300 tools doing the same, this is madness And BTW I hate SAFe, scrum and all this snake oil, but when a dev says that QA/DevOps is not necessary because they take over I can only laugh. You brought this micromanagement onto you, it was not us.

Allen, Well-done and spot on (Lean-Agile Consultant).

bless this man for speaking the truth

This is exactly I am thinking since last 2 years and wanted to write about it. You already have this viedo. Thank you.

Why does this video has only 50k views?! All world should see this!!! Spread it out!

I've been saying this for a couple years now. But Allen explains it 1000 times better than I can. I will say that I oppose the idea that being Agile is somehow binary. I look at the Agile values and principles in the same way a Buddhist looks at the values and principles of Buddhism. Anyone on the path of enlightenment is in their own specific place and time on that journey. As such, they will naturally pick and choose the beliefs and values that support them on their journey at that moment. We in Western civilization tend to favor a more dogmatic approach where you either follow the commandments and are saved or you don't. That's not how this really works in the real world. And as a result, I support teams picking and choosing (if they possess the maturity to do so) from the Agile values and principles so long as they understand the consequences. Just look at what a book seller named Amazon was able to do to the ENTIRE retail industry in a matter of years, and then you will understand the opportunity cost of moving too slowly along the process of evolution. But if you are moving forward, growing and learning, you have a shot. Great talk.

excelent. all my thoughts about agile in one video.

Amazing presentation!

this guy is amazing...absolutely in love !!!

That sounds like a dream. Unfortunately I haven't met companies that work like that

So what you are saying is that the Agile Team itself is rigid. What needs to be actually agile is everything that touches it - the corporation, customers, the product, etc.

I like the idea of three hats, user, designer and developer. As a user, you are on the front lines of necessity, which is the mother of invention, and being on the front lines of application use, you are better suited to a vision of better, and more capability of the tools you require. You know exactly what you need, so you should become a developer. Three hats don't exist in corporate and so, less than half assed products are produced. You can clearly see the lack of vision that was applied. Accounting applications are the same bullshit.

This should be titled: why SCRUM is not AGILE. Really interesting stuff.

I mostly agree with this opinion. Except I wouldn't be so severe concerning Scrum. What is missing in the picture is : what do we know about individual and their interactions ? Almost nothing. We believe a lot, but we know very little. We experience some pattern that work....until they stop working. If we are honest we must admit that often we don't understand why. 120 years of sudies and research in human nature (psychology, sociology of groups, ethnology...) remain discounted by the agile community. Once you put this knowledge in the picture Scrum makes a lot of sense.

We are not alone, there is hope after all!

Brutal. And true... Thank you

Outstanding!!

If all these companies are trying to move towards agile software development, but no one seems to achieve it, does it simply not mean that agile is not practical in real world scenarios and it the end does not work? That is the bottom line to me. It seems that you need some magical Goldilocks conditions for it to work and you need people (culture) with very strong focus on avoiding nonsense and bloat, which never happens in large companies because you get all kinds of people. Example: 34:02. All you need is one or two people to say "Hey, it's not my job to organize groups, I don't get paid for that" to poison the team and it's done. Also business people don't want to sit in with the tech people, that's another thing that works against agile development. Allen already mentioned QA and why that works against it too. Culture is extremely hard to build and very easy to spoil and if you do build it, then it automatically becomes very productive and you can call it agile or whatever terminology you want after that. It feels to me that the terminology comes AFTER the formation and observation rather than creating the work environment by following it. Agile software development starts with small companies because people in charge who are probably owners and developers have to be quick, they move fast and they have the mentality to respond quickly. They have a strong interest to do it. But once that scales and you get all kinds of people that becomes very hard to maintain unless you have an extremely serious screening processes and hire people only with the right attitude. Agile is very fragile.

This is a good talk. It just sounds a bit too similar to Dave Thomas's famous "Agile is Dead" presentation.

Best Agile talk ever

11:24 - I've yet to hear about a major IT product that has their client available on day to day. Either you don't knownyour client until you finish and sell your program or your client is a big corpo that you literally cannot get to have a call with you. At best you have their IT team which knows exactly as much as you cause they are IT, not the end user of the program.

I tend to agree with him, but I have worked in big companies, small companies, a university, etc, and I have never seen a company or organization that fits the description of agile, to me that's just a unicorn. Imagine saying let's all go to 'X' conference without asking anybody outside the team about it

He's regularly referring to one company where agile worked the way he imagines it should have, while in most other places it didn't work. If every 9 out of 10 attempts to work the right way (the way he imagines it should be), fail miserably, the conclusion should be there's something wrong with the approach, not that the people have ruined it. But in a typical theoretical guys' way of thinking, instead of accepting the world as it is and adjusting accordingly, he says the world is wrong. Another thing, he talks how the person that will be using the product should be there with the team most of the time. But the problem is, in most situations, you come to organization/company and pick two different people at random, they will have a different view of how this or that thing should be done. The approach will not work 99% of time, unless you are building software for companies that only have 2-3 people in it. But, I imagine, he'll again blame anybody, but the agile method, that it is not working.

Does anyone know the source for the XP Values / Principles / Processes illustration Holub uses at the 26:11 mark?

21:40 I agree about the Certification Mills.

Agree: Yes, I'm frustrated by "Agile" because nobody seems to understand that agile is an idea that needs constant refactoring and flexibility itself, like the software that should be created by it. Disagree: 2-3 minutes in an editor before retesting my software? That might be enough time to change or fix a parameter (which should not be in the code anyway), but not for doing any atomic implementation change. You might be able to correct a syntax error in 2-3 minutes, but that is nothing that should reach the test lab anyway.

Over simplified. How do you develop a new feature for 2000 Enterprise customers? Put all of them in the room? How do you prevent WIP without Sprints? Are all developer equal in all aspects and you can count all of them to make good decisions? What if people try to make XP without testing every 3 minutes because this is the part they dislike? Why do we sometimes need to encourage people to step out of their comfort zone if we can just trust them to always repeat the same decision? Who makes sure people are committed to evolve their skills?

It sounds like the death of agile isn't the fault of agile, it's the fault of gatekeeping.

the best standup ever :)

Great Presentation

With all seriousness though this works great when your people are all great, but there will be regular Joes that need managers and middlemen processes as well.

this talk is seven years old and painfully relevant today. wtf happened the last seven years ???

12:29 - try telling the client "it will be done when it will be done". That only works in gaming and only for beloved companies.

All that agile comes down to is your colleagues telling you what to do instead of your boss.

TL;DW: If you are in the 0,01% of companies for which there is no responsibility checks for anyone by anyone by some miracle, then Agile is for you.

There is only ONE thing I disagree. No developers cannot fully test the PRODUCT. They are CODE experts.. and a product is not only code. Developers are not the target of your product so no you CANNOT rely in their acceptance of quality. When you do that you end up with what we see in TV and movies like now. .. the team that made the movie think it is the best thing ever.. but every one that see it a theaters wants to throw up. You must have people that are NOT part of the building team evaluating your product.

How do we fix it though? I agree with everything here but I can't move a large ship by myself. Or do we just quit and find another job somewhere else?

This guy's a radical. I like it.

13:44 -what if client demands it as they believe it provides them value? Like most corpo clients?

savage. love this guy.

11:46 -nice to say, worse if the training you need is booked till the next year.

The one downvote is a Scrum master who fears for his job :)

"Agile" seriously needs to be renamed. It's anything but agile

All these agile practices were invented just to drag out processes and pull money from customers as much as possible as well as for some roles/positions to justify their existence, for example, scrum master - the absolutely useless position(sorry, guys, don‘t want to offend anyone but let‘s face it) who has spent 200€ for their scrum certificate and now can just watch how the process is going(as they claim their responsibility) and then in case of a fail to tell the team they are doing Scrum wrong. Regarding a self-organized team: they just don‘t exist, on any team, there is a leader, be it an official one or informal(it‘s in our nature), the only problem is that the top management wouldn’t like to pay for the leadership and invent „self-organization“ where no one is responsible for anything.

27:39 a very important point. upfront requirements doesn't work. but people are just. get the full requirements right and then only start working. till then don't do anything. i don't understand this. agile means flexibility. adapting to changes and as we get the know problem, requirement better. don't code till then. it doesn't make sense...

Why trying to do strum and plan sprints ahead if anything will change anyway? Be lean, eleminate the wasted working hours by trying to do this roadmap planning. Just use a priority list and do kanban instead of scrum.

I followed you on Twitter for years, rarely disagree with anything you have to say... and again, find very little to disagree with in this presentation.

How does anyone get any work done with these constant interruptions advocated by agile teachers?

so...what you are saying is that it is impossible for large organizations to actually be/do the agile thing? The way you that are painting agile principles makes me want to avoid it like the plague.

When we introduced SAFe, I questioned the value. But ......

What happens if you have 3000 customers? Who should sit on an average team's sprint review, or demo?

3:30 There is no project manager on the agile team

Why are there so many titles giving people the impression agile is dead? They are actually going to start making people think that agile is dead.

several misconceptions about the product owner and length of sprint -- Holub has an agenda and his video oversimplifies the complexity of managing multiple teams in more than one time zone and denigrates the value of online tools like Jira.

I agree with a lot of what is said here. But very confused about saying “in agile there are no project managers”. What??? There are certainly project managers in an agile environment. Unless; you’re saying that in an agile environment the team should be doing documentation, creating product, facilitating etc etc. that doesn’t work in the real world my friend

Agile and FP should be done together as you can just change the composition without affecting your functions/sub-solutions Agile modelling/OOP seems stupid... howd DaVinci agile paint the MonaLisa from scratch?

Agile is a skill, not a process

It is great for a team to be agile. But “Agile” is simply toxic to software and team development.

I absolutely hate anything labeled 'agile'. I have NEVER encountered it as anything but a religion, with dogma and priests and inquisitors and gurus and faith healers, all of whom keep claiming that "real" agile is sooooo great... just like another religion. Good software that works well with others is the product of good programmers who work well with others.

Scrum is a process? I think you'll find Scrum is a framework.

I think Allen got it wrong on Scrum and underestimated the power of the process. He went wrong on a few things link Product Owner being the marketing department, you can't change requirements during the sprint, scrum teams working in a bubble, disliking certification process of Certified Scrum Master.

Gold.