"In any sentence that you sentence where you see the word agile, if you can replace that word with the word Flexible, then you have a proper sentence" - I'm taking that quote, thank you very much. Still VERY relevant 9 years later.
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.
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.
Yes, and this presentation is already 8 years old, and nothing changes. Companies are becoming more, and more dysfunctional, but management seems to be happy since, they can have nice charts and spreadsheets, they think they understand. It is all very simple - non tech people are running tech people, and this won't end very well no matter what kind of manifests, or framework would be used. It is not the scrum or agile - it is simply a communication dysonanse, it is like talking about quantum physics to 5 year old - 5 year old would understand something, but in relation to toys, playgrounds, sweets etc. Same for scrum masters, product owners, project managers - they would understand something they could put in spreadsheet. It has been told for centuries, it is very plain, and simple and yet nothing changes. This is really amazing, how much people work is wasted, just because of that simple factor, that could be easily eliminated with proper communication training.
I'm a non-technical Scrum Master and I love this video and the ideas behind it. My job also would never end and I'm not fearing it. There is enough to work on with the business and teams that is not "facilitating the daily scrum" which good teams don't need a SM for anyway...
@@melov7629 100% agree and what made me sick to my stomach is that you can be a 10 year master dev who has some of the most difficult certification on the planet and devoted countless hours on nights and weekends to stay up to speed on the 1 Billion changes in the coding world every day. Then you look on Zip Recruiter and see that someone that took a 2 day class and passed a 40 question open book test on a 10 page document has the exact same pay scale.
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!!!
It's almost 9 years old and this talk is still depressingly relevant. I don't see any of the companies that are "agile" going out of business any time soon though.
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.
You're getting roped into specific processes, which is evidence to the point about principles. It's true that Spotify didn't implement the process shown within this video, but they did iterate on their process when it wasn't working until it did. The fast adaptation is the core component of the argument. Getting overly fixated on one workflow vs the other is missing the forest through the trees. Process isn't the most imperative issue, being able to modify it quickly is.
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.
At 6:40 Mr Holub makes a devastating observation: the whole organization has to be "Agile", not just the software developers. Coming from an Enterprise ISV that "forced marched" from "waterfall", classical development was painful, but Engineering did this within one year. What we discovered was that customers were not Agile. Their IT organizations could not deploy s/w developed in 90 day cycles. The back office end users rebelled against changes in the systems: their performance metrics degraded 15-20%. When one of your customers has 24,000 end users of your system, this is a problem. Their CEO calls your CEO. Lawyers get hired. The Business division owns the contract. The IT Division "owns" the operational success, but not the budget for it. Agile s/w delivery is seen as a solution to delivering CAPEX scope system changes within an OPEX budget. Customers wanted to pick and choose select feature changes as "system patches", not as full releases. Lastly, any Enterprise s/w system has to integrate with legacy and in-house s/e systems, hence the Corporate Customer's IT Division has to be Agile too.
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.
Maybe at this point you have fully converted your tools, process and most importantly your skeptical attitude of SAFe. Real meaningful change not only takes effort but time. I am sure the response I hear back will be nothing but 100% praise for what you were put through.
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
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.
Hope? How? I like the video but it is fantasy to suppose that the world will be taken over by agile for the same reason that the old ideal project teams didn't work - Most people simply don't wont and can't work that way and it's not a matter of training. Most of us will NEVER work for a company that is truly agile.
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!
Ok, then DROP the agile buzzword and stop wastign time pretending to be adopting somethign that will nto be adopted. These companies saying they are going agile are like someone that says will get into shape but does not want to stop eating sugar and keep finding excuses for it.. face it.. you are NOT goign to get into shape.. you do not WANT IT! THe same with agile.
@@Leo-qi5yp Nonsense. There's no evidence to support this assertion. In fact, that this video is 7 years old, and these problems still exist, would suggest that non-agile companies are not dying, and surviving just fine to the great displeasure of the agile zealots.
@@Leo-qi5yp The OP stated the point in the very first sentence. He then went on to explain why it was a pure utopian idea. Very nice ideas but essentially not possible in 99% of organizations. On a side note, the idea that there isn't any project mgmt in an agile process is ridiculous. Just as ridiculous as the idea that their isn't any sw design going on. The isn't any project manager role (i.e. no specific person doing that work) but that is another thing entirely.
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.
Time sheets and billing codes may not improve production but are necessary for billing the customer and accounting for costs. Billing, taxes, and tracking actual profits are important to keeping the company alive. Any company that does not track those things eventually goes out of business. However, the company can use time clock programs with the appropriate functions to expedite the time tracking.
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.
Very spot-on talk, I agree with the certification mills, agility of training and the dysfunctional tools points. The level of frustration in the voice tone most likely reflects actual experiences. ;)
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?
Fully agree it is oversimplified. I can continue. If development team has budget that can be used for its development purposes (as speaker describes) based on what this budget is set? If people need to design system how they now what is target if they are supposed to design iteratively? Who sets a goal and how? How to deal with common situation that customers many times *does not know* what they need? Are we not making automatic assumption, not valid in practice for more cases then less, that customer assigns and allocates relevant, knowledgeable, experienced peers to project? It is also interesting how such presentations making hidden assumptions. For example, there is "agile team" and "others" (Customer) so some kind of interfacing is required to cross two worlds. Taking agile ideas as law and not as principles applied to the context is really what is killing agile principles of software development.
I would also challenge statement that "agile is the most effective way to build software". The *majority* of the most successful and valued software is not build in such a way. Dogmatism needs to get out of the way - we have still not found THE way to build software or any creative act of work; it all DEPENDS.
All of your questions show that you don't trust people. Don't hire people you don't trust. Fire people that don't live up to your expectations. If you build a highly Skilled pool of talented people and provide them an environment they enjoy working in and empowers them to work freely, all your questions become non questions imo.
@@khatdubell So in other words, just wish any and all human resource problems out of existence. The problem with these type of business philosophies is that it assumes no other limitations exist in the system: no budgetary restraints exist, the workforce is skilled, talented, and motivated. This sort of reasoning sets these systems up for failure, and provides an ready list of excuses for why the failure happened. Simply having budgetary constraints means that the upper management didn't have enough faith is the system.
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 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.
@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.
This video is from 2014. The model whitepaper was published I believe in 2012. So I'd imagine no one had actually written how the model failed yet. That came years later. It was a failure, and this video has outdated information. No need to blast it "as a complete lie". It's not a lie. It was based on CORRECT information at the time, but was only later proven to be faulty.
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* .
There is no thing that is "Agile". Agile is a set of principles and values..... that is mostly lost in this corporate idea of "Agile". What you describe is the opposite of agile as originally intended. There is a principle around communication which would mean if you need to do things then other people who need to know about that are . informed. Adherence to process is not "Agile" as per the first part of the manifesto "Individuals and interactions over processes and tools"
@@codenoob9325 You might be right, now that I think about it scrum fits what happened there better than agile. Despite everyone calling it agile (it was a project at university, so I kinda assumed the people knew what they were talking about without questioning it much). Either way it was documentation hell that slowed the implementation to a grind. I'm just glad my workplace gives me the requirements all at once and just wants the finished product no matter how I go about doing that.
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!
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 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 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.
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...
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.
Nothing for a QA dept to do… oh sweet summer child. Actually a QA dept which can support dev teams whilst also maintaining system testing which tests the SYSTEM according to the system specifications or use cases known to be what the customer needs has obvious value. Even if you measure every grain, unless you’re taking a look at the actual system, you’ll probably end up with a heap and not a sandcastle. Unless your system is so small it fits into one small team where everyone knows everything…
The QAs should be in the teams doing the testing frequently. No need of a separate QA department that sits outside the teams delivering the features. I think that's the point. Not eliminating QAs doing System testing.
The US Air Force went through a similar thing with the Total Quality movement starting in the early nineties. The US Chief of Staff had heard that the Total Quality movement could work wonders in industry, and decided that he would apply it in the Air Force. It soon became clear that he only intended to use the terminology, while rejecting just about every substantive reform that TQ required. The whole effort was abandoned after he retired. There is now no indication in the Air Force that TQ was even attempted.
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.
This is about software engineering, not physical goods. With software, it is much easier to prospect, iterate and try out ideas, as the cost of early failure is not that big.
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.
So the people NOT part of the building team evaluating your product are the CUSTOMERS. I believe the discussion about not having QA because the developer constantly tests the code is for code correctness and technical bugs, not suitability for purpose. Only the customers can answer that one, which is why there is the emphasis on the short iterative loop of develop, get customer feedback, adjust, repeat.
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.
Time traveling from 2024: At last an "Agile sux" video that makes sense. Agile doesnt suck, bad Scrum sucks. Allen pinpoints the problem - We need a culture of Agility. And Orgs are looking for a quick fix. And they love their extant culture. So change does not happen. What's most alarming is that this is 8 years old and still relevant.
And nobody ever mentions the significance of the first line of the agile manifesto: "We are uncovering better ways of developing software by doing it and helping others do it." This should be the main concern of the agile coaches. Uncovering better ways -> by listening to the teams, sprint the impediments and conducting experiments. And you have to be doing it, not floating about with PowerPoints and stakeholders. You need to be in the gemba.
This is all organisational management, hierarchical vs flat vs cells. His description is of flat and dynamic cells structure with LOs, but wrapped up in a cultish jargon that can be packaged and sold to companies.
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.
I share that perspective of automotive. The supplier-customer relationship seems to be a sort of ranked battleground of the medieval period, with armour and pikemen. Not good for cooperation. Sometimes we connect the tech guy with the tech guy and good things get built, but not often enough.
Release small increments, let customers have access and use it and measure their engagement and get feedback. Incorporate your findings in the next small increment and repeat.
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.
Yes. Iterate towards a working sw development system by asking the experts and fixing the impediments. This checks off the culture aspect immediately. And you also do this on a small loop.
So what do finance processes look like in an agile company? One of the things the finance team does is validate theres budget and validate where the money is going to (lots of scams exist to confuse people to send money to the wrong place).
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
Kent Becks first book from 1999 "Extreme Programming Explained", I got this book in 99 and started with XP. Modern day "Agile" I keep a distance from, I think it's missed the point.
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.
I think what he is refering to is automated testing. E.g. nCrunch is doing this for you continiously while writing code. So you always know very fast if you broke something
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
"we do not have a hierarchy" a notion that is anathema to many business entities, not just mega corps. I once worked for a company that had maybe 40 employees. we in the technical staff were at the bottom of the org chart, and management (aka, the owners) wanted it that way. people with power will do anything to hold on to that power, and empowering their perceived underlings to take control of a major part of a business process is a threat to their power. the upper levels of the hierarchy will fight that tooth and nail. that's not some business school lesson, that's basic human nature.
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.
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.
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.
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.
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.
I watch these videos to dream of what could be. Every company I've worked for is "Agile" (capital A) rather than "agile". There is no team empowerment, no flexibility. Just a million "ceremonies" and processes and top-down control and bleh. "SAFe" is literally just "waterfall, but we'll call it a different name so upper management feels like they're doing something innovation and noble".
Holub on Patterns is one of the most difficult programming I ever *tried* to read. Which begs the question, whatever happened to design patterns? Not as popular as it used to be, just like Agile.
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.
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.
Uh no, sounds like you got scrummed. He talks in generalities and principles because that's what agile is, a set of guiding principles. Every situation that you've experienced has been different than the last, same for me as well. The principles are the guiding lights. If you follow process, then everything you just said is accurate. But that's not what Allen spoke about. Might give it another listen.
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.
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
Why does this video has only 50k views?! All world should see this!!! Spread it out!
Yesssss
"In any sentence that you sentence where you see the word agile, if you can replace that word with the word Flexible, then you have a proper sentence" - I'm taking that quote, thank you very much. Still VERY relevant 9 years later.
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.
I can't agree more. Also nodding my head in agreement and thinking: and this is from 2014? What have we been doing??
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.
Yes, and this presentation is already 8 years old, and nothing changes. Companies are becoming more, and more dysfunctional, but management seems to be happy since, they can have nice charts and spreadsheets, they think they understand. It is all very simple - non tech people are running tech people, and this won't end very well no matter what kind of manifests, or framework would be used. It is not the scrum or agile - it is simply a communication dysonanse, it is like talking about quantum physics to 5 year old - 5 year old would understand something, but in relation to toys, playgrounds, sweets etc. Same for scrum masters, product owners, project managers - they would understand something they could put in spreadsheet. It has been told for centuries, it is very plain, and simple and yet nothing changes. This is really amazing, how much people work is wasted, just because of that simple factor, that could be easily eliminated with proper communication training.
TMNA
The one downvote is a Scrum master who fears for his job :)
More precisely a non-technical Scrum master, that his jobs ends after 9:30 AM and has nothing on the project after finished the daily meeting :D
I'm a non-technical Scrum Master and I love this video and the ideas behind it. My job also would never end and I'm not fearing it. There is enough to work on with the business and teams that is not "facilitating the daily scrum" which good teams don't need a SM for anyway...
@@melov7629 , why are you continue with this job ? Actually I ask this to many that continue this Agile madness.
@@melov7629 100% agree and what made me sick to my stomach is that you can be a 10 year master dev who has some of the most difficult certification on the planet and devoted countless hours on nights and weekends to stay up to speed on the 1 Billion changes in the coding world every day. Then you look on Zip Recruiter and see that someone that took a 2 day class and passed a 40 question open book test on a 10 page document has the exact same pay scale.
Great talk. Might better have been titled: "Why you'll probably never see Agile development in the real world"
Yeah, I love the speech, but I hate the title
You see in tiny startups where everyone working on the company is part owner of the company. ...but only there.
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!!!
It's almost 9 years old and this talk is still depressingly relevant. I don't see any of the companies that are "agile" going out of business any time soon though.
Sad
I see a lot of crappy software from all sorts of large companies
@@HOWYOUDOIN884 Buggers don't even test their sht anymore - just ship it to customers
The best. Most direct. Most concise. Most clear.
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.
Sad
You're getting roped into specific processes, which is evidence to the point about principles. It's true that Spotify didn't implement the process shown within this video, but they did iterate on their process when it wasn't working until it did. The fast adaptation is the core component of the argument. Getting overly fixated on one workflow vs the other is missing the forest through the trees. Process isn't the most imperative issue, being able to modify it quickly is.
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.
you're not wrong. Were you wrong?
At 6:40 Mr Holub makes a devastating observation: the whole organization has to be "Agile", not just the software developers. Coming from an Enterprise ISV that "forced marched" from "waterfall", classical development was painful, but Engineering did this within one year. What we discovered was that customers were not Agile. Their IT organizations could not deploy s/w developed in 90 day cycles. The back office end users rebelled against changes in the systems: their performance metrics degraded 15-20%. When one of your customers has 24,000 end users of your system, this is a problem. Their CEO calls your CEO. Lawyers get hired. The Business division owns the contract. The IT Division "owns" the operational success, but not the budget for it. Agile s/w delivery is seen as a solution to delivering CAPEX scope system changes within an OPEX budget. Customers wanted to pick and choose select feature changes as "system patches", not as full releases. Lastly, any Enterprise s/w system has to integrate with legacy and in-house s/e systems, hence the Corporate Customer's IT Division has to be Agile too.
Very nice talk and amazing how this is still relevant in 2022!
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.
Hahaha wizard of SAFe 😅😅😅
Sounds like you are already agile.
how did it go? :)
Maybe at this point you have fully converted your tools, process and most importantly your skeptical attitude of SAFe. Real meaningful change not only takes effort but time. I am sure the response I hear back will be nothing but 100% praise for what you were put through.
Check out Waltzing with Bears and the part on Specification Breakdown
Just came across this after not seeing it for 4 yrs. Still rings true. LOVE the point about the QA department....
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
this talk is seven years old and painfully relevant today. wtf happened the last seven years ???
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.
We are not alone, there is hope after all!
Hope? How? I like the video but it is fantasy to suppose that the world will be taken over by agile for the same reason that the old ideal project teams didn't work - Most people simply don't wont and can't work that way and it's not a matter of training. Most of us will NEVER work for a company that is truly agile.
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!
Ok, then DROP the agile buzzword and stop wastign time pretending to be adopting somethign that will nto be adopted. These companies saying they are going agile are like someone that says will get into shape but does not want to stop eating sugar and keep finding excuses for it.. face it.. you are NOT goign to get into shape.. you do not WANT IT! THe same with agile.
I'm grateful for living that "utopia" more than once
@@Leo-qi5yp Nonsense. There's no evidence to support this assertion.
In fact, that this video is 7 years old, and these problems still exist, would suggest that non-agile companies are not dying, and surviving just fine to the great displeasure of the agile zealots.
@@Leo-qi5yp The OP stated the point in the very first sentence. He then went on to explain why it was a pure utopian idea. Very nice ideas but essentially not possible in 99% of organizations. On a side note, the idea that there isn't any project mgmt in an agile process is ridiculous. Just as ridiculous as the idea that their isn't any sw design going on. The isn't any project manager role (i.e. no specific person doing that work) but that is another thing entirely.
And why do you assume the “senior execs” opinions on software development are to be respected?
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.
Can't get incentive bonuses for launching X feature this quarter if it isn't delivered.
Time sheets and billing codes may not improve production but are necessary for billing the customer and accounting for costs. Billing, taxes, and tracking actual profits are important to keeping the company alive. Any company that does not track those things eventually goes out of business. However, the company can use time clock programs with the appropriate functions to expedite the time tracking.
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.
Very spot-on talk, I agree with the certification mills, agility of training and the dysfunctional tools points. The level of frustration in the voice tone most likely reflects actual experiences. ;)
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?
Fully agree it is oversimplified. I can continue. If development team has budget that can be used for its development purposes (as speaker describes) based on what this budget is set? If people need to design system how they now what is target if they are supposed to design iteratively? Who sets a goal and how? How to deal with common situation that customers many times *does not know* what they need? Are we not making automatic assumption, not valid in practice for more cases then less, that customer assigns and allocates relevant, knowledgeable, experienced peers to project?
It is also interesting how such presentations making hidden assumptions. For example, there is "agile team" and "others" (Customer) so some kind of interfacing is required to cross two worlds.
Taking agile ideas as law and not as principles applied to the context is really what is killing agile principles of software development.
I would also challenge statement that "agile is the most effective way to build software". The *majority* of the most successful and valued software is not build in such a way. Dogmatism needs to get out of the way - we have still not found THE way to build software or any creative act of work; it all DEPENDS.
All of your questions show that you don't trust people.
Don't hire people you don't trust.
Fire people that don't live up to your expectations.
If you build a highly Skilled pool of talented people and provide them an environment they enjoy working in and empowers them to work freely, all your questions become non questions imo.
@@khatdubell So in other words, just wish any and all human resource problems out of existence. The problem with these type of business philosophies is that it assumes no other limitations exist in the system: no budgetary restraints exist, the workforce is skilled, talented, and motivated. This sort of reasoning sets these systems up for failure, and provides an ready list of excuses for why the failure happened. Simply having budgetary constraints means that the upper management didn't have enough faith is the system.
@@blkgardner It is the ultimate "Assume a frictionless surface,..." of Human Resource management
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....
"now we are in stateless mode.......wandering" buhaahahahaha
I agree with a lot of what you say here, although complex systems that require functional safety certification can't work this way.
this guy is amazing...absolutely in love !!!
excelent. all my thoughts about agile in one video.
This is exactly I am thinking since last 2 years and wanted to write about it. You already have this viedo. Thank you.
3:30 There is no project manager on the agile team
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.
@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.
This video is from 2014. The model whitepaper was published I believe in 2012. So I'd imagine no one had actually written how the model failed yet. That came years later. It was a failure, and this video has outdated information. No need to blast it "as a complete lie". It's not a lie. It was based on CORRECT information at the time, but was only later proven to be faulty.
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* .
There is no thing that is "Agile". Agile is a set of principles and values..... that is mostly lost in this corporate idea of "Agile". What you describe is the opposite of agile as originally intended. There is a principle around communication which would mean if you need to do things then other people who need to know about that are .
informed. Adherence to process is not "Agile" as per the first part of the manifesto "Individuals and interactions over processes and tools"
No you're talking about scrum. Not agility.
@@codenoob9325 You might be right, now that I think about it scrum fits what happened there better than agile. Despite everyone calling it agile (it was a project at university, so I kinda assumed the people knew what they were talking about without questioning it much).
Either way it was documentation hell that slowed the implementation to a grind.
I'm just glad my workplace gives me the requirements all at once and just wants the finished product no matter how I go about doing that.
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!
I can't believe this is 9 f*cking years ago
and we still sit with the same issues today.
@@mannetjie3704 yep. religion comes in many forms..
Best thing I've seen on Agile and scrum ever. Thanks. I wish I can join or create such a company.
So many CEOs and MDs need to see this.
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.
Lean ftw
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 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.
This is a good talk. It just sounds a bit too similar to Dave Thomas's famous "Agile is Dead" presentation.
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...
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.
Anyone watching this in 2024 when the state of the Agile Industrial complex is even worse ?
it's getting bad now, really bad 😅
Allen, Well-done and spot on (Lean-Agile Consultant).
Nothing for a QA dept to do… oh sweet summer child. Actually a QA dept which can support dev teams whilst also maintaining system testing which tests the SYSTEM according to the system specifications or use cases known to be what the customer needs has obvious value. Even if you measure every grain, unless you’re taking a look at the actual system, you’ll probably end up with a heap and not a sandcastle. Unless your system is so small it fits into one small team where everyone knows everything…
The QAs should be in the teams doing the testing frequently. No need of a separate QA department that sits outside the teams delivering the features. I think that's the point. Not eliminating QAs doing System testing.
Very good presentation. It is really useful. Thanks for sharing
The US Air Force went through a similar thing with the Total Quality movement starting in the early nineties. The US Chief of Staff had heard that the Total Quality movement could work wonders in industry, and decided that he would apply it in the Air Force. It soon became clear that he only intended to use the terminology, while rejecting just about every substantive reform that TQ required. The whole effort was abandoned after he retired. There is now no indication in the Air Force that TQ was even attempted.
How does anyone get any work done with these constant interruptions advocated by agile teachers?
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.
This is about software engineering, not physical goods. With software, it is much easier to prospect, iterate and try out ideas, as the cost of early failure is not that big.
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.
So the people NOT part of the building team evaluating your product are the CUSTOMERS. I believe the discussion about not having QA because the developer constantly tests the code is for code correctness and technical bugs, not suitability for purpose. Only the customers can answer that one, which is why there is the emphasis on the short iterative loop of develop, get customer feedback, adjust, repeat.
I think you missed the point
This should be titled: why SCRUM is not AGILE.
Really interesting stuff.
it's always refreshing to see when someone speaks the truth.
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.
Totally aggree
Time traveling from 2024: At last an "Agile sux" video that makes sense. Agile doesnt suck, bad Scrum sucks. Allen pinpoints the problem - We need a culture of Agility. And Orgs are looking for a quick fix. And they love their extant culture. So change does not happen. What's most alarming is that this is 8 years old and still relevant.
Incorrect graphic for needle at 3:48 with respect to camel fitting through eye of a needle. It was a narrow doorway, not a sewing tool.
Nope - that’s a myth.
That sounds like a dream. Unfortunately I haven't met companies that work like that
21:40 I agree about the Certification Mills.
And nobody ever mentions the significance of the first line of the agile manifesto: "We are uncovering better ways of developing software by doing it and helping others do it."
This should be the main concern of the agile coaches. Uncovering better ways -> by listening to the teams, sprint the impediments and conducting experiments. And you have to be doing it, not floating about with PowerPoints and stakeholders. You need to be in the gemba.
Great talk. The point to be noted is this guy is against agile methods but gives thumbs up to companies going agile
Back when I did the CSM, you could get absolutely every question wrong and still be issued a certificate... because you paid for it
"There's no hierarchy, no bosses" - So when did Spotify become a worker coop? Tribes/Guids/Squads, gross corporate-speech.
This is all organisational management, hierarchical vs flat vs cells. His description is of flat and dynamic cells structure with LOs, but wrapped up in a cultish jargon that can be packaged and sold to companies.
Great Presentation
This guy's a radical. I like it.
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.
At least some electric car company in the USA know how to apply agility to manufacturing 🤭
I share that perspective of automotive. The supplier-customer relationship seems to be a sort of ranked battleground of the medieval period, with armour and pikemen. Not good for cooperation. Sometimes we connect the tech guy with the tech guy and good things get built, but not often enough.
bless this man for speaking the truth
What happens if you have 3000 customers? Who should sit on an average team's sprint review, or demo?
That depends. Are your 3000 customers homogenous? Or are there 3000 distinct kinds of customers?
@@airman122469 well there might be similar users, but let's say few hundred companies and they are very different.
Release small increments, let customers have access and use it and measure their engagement and get feedback. Incorporate your findings in the next small increment and repeat.
Outstanding!!
savage. love this guy.
Very good! Thanks!
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.
Yes. Iterate towards a working sw development system by asking the experts and fixing the impediments. This checks off the culture aspect immediately. And you also do this on a small loop.
So what do finance processes look like in an agile company? One of the things the finance team does is validate theres budget and validate where the money is going to (lots of scams exist to confuse people to send money to the wrong place).
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
Does anyone know the source for the XP Values / Principles / Processes illustration Holub uses at the 26:11 mark?
Kent Becks first book from 1999 "Extreme Programming Explained", I got this book in 99 and started with XP. Modern day "Agile" I keep a distance from, I think it's missed the point.
the moment you realise this guy is the director of QA
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?
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.
I think what he is refering to is automated testing. E.g. nCrunch is doing this for you continiously while writing code. So you always know very fast if you broke something
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
"we do not have a hierarchy"
a notion that is anathema to many business entities, not just mega corps. I once worked for a company that had maybe 40 employees. we in the technical staff were at the bottom of the org chart, and management (aka, the owners) wanted it that way.
people with power will do anything to hold on to that power, and empowering their perceived underlings to take control of a major part of a business process is a threat to their power. the upper levels of the hierarchy will fight that tooth and nail. that's not some business school lesson, that's basic human nature.
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.
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.
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.
Amazing presentation!
the best standup ever :)
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.
I want to shout out to my colleagues who will celebrate this video after it was posted today ;) I think we can all relate ;)
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.
Absolutely true, 2024 and it's still the biggest problem
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.
I watch these videos to dream of what could be. Every company I've worked for is "Agile" (capital A) rather than "agile". There is no team empowerment, no flexibility. Just a million "ceremonies" and processes and top-down control and bleh. "SAFe" is literally just "waterfall, but we'll call it a different name so upper management feels like they're doing something innovation and noble".
Holub on Patterns is one of the most difficult programming I ever *tried* to read. Which begs the question, whatever happened to design patterns? Not as popular as it used to be, just like Agile.
Best Agile talk ever
Everyone is equal but some is more equal than others
Where have you been my whole life?
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.
Brutal. And true... Thank you
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.
Uh no, sounds like you got scrummed. He talks in generalities and principles because that's what agile is, a set of guiding principles. Every situation that you've experienced has been different than the last, same for me as well. The principles are the guiding lights. If you follow process, then everything you just said is accurate. But that's not what Allen spoke about. Might give it another listen.
"he'll blame anybody but the agile method" -- Agile is not a method.
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.
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