"I Hate Agile!" | Allen Holub On Why He Thinks Agile And Scrum Are Broken
ฝัง
- เผยแพร่เมื่อ 6 ส.ค. 2022
- Allen Holub gives strong opinions on agile and scrum and how their adoption can cause problems within software engineering teams.
This is a clip taken from the full podcast interview, which you can watch HERE ➡️ • Agile & Scrum Don't Wo...
-------------------------------------------------------------------------------------
Also from Dave:
🎓 CD TRAINING COURSES
If you want to learn Continuous Delivery and DevOps skills, check out Dave Farley's courses
➡️ bit.ly/DFTraining
📧 Get a FREE guide "How to Organise Software Teams" by Dave Farley when you join our CD MAIL LIST 📧
The best way to keep in touch with the latest discussions, events and new training courses, get FREE guides and exclusive offers. ➡️ www.subscribepage.com/organis...
_____________________________________________________
🙏The Engineering Room series is SPONSORED BY EQUAL EXPERTS
Equal Experts is a product software development consultancy with a network of over 1,000 experienced technology consultants globally. They increase the pace of innovation by using modern software engineering practices that embrace Continuous Delivery, Security, and Operability from the outset ➡️ bit.ly/3ASy8n0
-------------------------------------------------------------------------------------
➡️ Links:
Allen Holub's Website ➡️ holub.com
Allen Holub's Heuristics ➡️ holub.com/heuristics/
The Agile Manifesto ➡️ agilemanifesto.org
Westrum Model of Organizational Culture ➡️ bit.ly/3QaK8bE
Mike Rother Describing the Toyota Kata ➡️ • Introduction to Toyota...
-------------------------------------------------------------------------------------
📚 BOOKS:
📖 Dave’s NEW BOOK "Modern Software Engineering" is now available here ➡️ amzn.to/3DwdwT3
📖 "Continuous Delivery Pipelines" by Dave Farley paperback ➡️
amzn.to/3gIULlA
ebook version ➡️ leanpub.com/cd-pipelines
📖 The award-winning "Continuous Delivery" book by Dave Farley and Jez Humble ➡️ amzn.to/2WxRYmx
📖 The Beginning of Infinity: Explanations That Transform the World, David Deutsch ➡️ amzn.to/2MrOEqA
📖 Toyota Kata, by Mike Rother ➡️ amzn.to/3vrh4V2
📖 Drive: The Surprising Truth about What Motivates Us, Dan Pink ➡️ amzn.to/3OGSXbS
NOTE: If you click on one of these Amazon Affiliate links and buy the book, Continuous Delivery Ltd. will get a small fee for the recommendation with NO increase in cost to you. - วิทยาศาสตร์และเทคโนโลยี
My god, this is so refreshing to hear. I've been writing software professionally for 35+ years, and witnessing the cargo culting of Scrum and the way it's infantalized what software engineering is has been frustrating and, honestly, a little heartbreaking. Writing software can be so creative and powerful when you're part of a team focused on building something amazing, and the layers of process and "ceremonies" around it sucks the joy out of it.
Thank you for talking about this.
Agreed. I've been on a similar journey and had similar experiences !
I have no issue with Scrum as a process, it allows a clear process for the business to pass clear requirements to the development team, and allows developers, collaborating maybe with UI/UX and other development teams (for instance a back end team) to get on and write software that the business actually wants. But the issues with it are that businesses try to use it as a project management tool rather then a product development tool.
Having gone through an 'agile transformation' which handicapped an engineering organisation which was pretty agile and effective, this resonates a lot.
completely Seeing that happen in 1/2 real time
I see most of the people who are forcing agile and scrum are business/management people. Similar to any other management certification. They took it as an opportunity to legitimize their position without knowing software engineering at all. They instinctively understand that their position doesn't produce any value rather than running the corporate hierarchy. So they need something else to be seen as doing something or bringing value. And since they are in the management, they shovel it down the throat of the actual developer who suffers from cleaning up all the gaps pushed down the project hierarchy. And dev who are not good at technical or can't withstand the prolonged stress change career to become agile coach/scrum master/product owner or any non-programming role. And also those roles have a better chance to climb the corporate ladder compared to the programming role. Then we start again the cultic cycle.
Bruh
Nah. Scrum masters are NOT AT all more likely to climb ladders faster. What they gonna be? Scrum master of management?
@@rishabhjain7543 😂
I know person, who is a Professional Scrum Master with 2nd level of certification(and close to 3rd level, to be honest), he just want to do his job well and happy to work so. Main work of Scrum Master is a boost productivity of his team. He raises performance of his team up to 3 or even 25 times(!) during 3-4 months per team, several different teams, several companies. No extra programing trainings or team members replacement or jira statistics manipulation. Basically, he used and keep improving base things like an "inspection" and "adoption", which are you scoff at.
@@dmitriylatukhin7356 You can improve the productivity of most software teams by simply implementing a few best practices. Have the teams improved because of Scrum or because of a competent individual?
The whole certificate culture is bewildering. Companies hiring folks who've passed an online open book exam over those with real experience delivering software and doing the roles.
I actually booked the wrong exam by accident and still passed...
🤣
My professor said that PMI certification is a waste of a lot of money and it expires. I totally agree. Certifications are just a business where companies pay partnerships with those brands and just want to show off where sometimes all of that is mere facade.
It's not to say that the system isn't broken, or bewildering, but when a candidate states on their resume (that they themselves created) that they have "n" years of experience delivering software, what does that really tell you? Clearly if they have 0 years experience it tells you a lot. However, if person A has 3 years and person B has 7 years, can you automatically assume that person B is more knowledgeable?
I would argue that if a specific certification gets you hired over someone who does not have that certification then that is not a waste of money. :)
@@JeffreySimpson I am not automatically against the idea of certification, but it has become so discredited in our industry that most of the places that I worked, often good places, that many people would like to work, treated certification as a downgrade. I am not say this is right or wrong, it is just what happened. If someone came in with certification, not just "Scrum Master" but technical certs from the big providers too, that was assumed to mean that they had been, at best, looking in the wrong places. The problem, as I think Allen said, is that certification for our industry is much more a commercial venture than a learning experience. How can anyone claim mastery of anything following a 2 day course that you pass if you only attend?
A car manufacturer in the far south of Germany uses a scrum model, where EACH STORY is a fixed price contract and the only way a provider gets payed. If a story takes longer (or there are any bugs), the provider has to pay for that out of the own pocket and if a story seems overestimated, there are tons of discussions with the POs. This of course results in a lot of "management" on provider side because if stories are your only income for everything including managers, scrum masters, BAs etc. they start to monitor heavily and annoy the team with all kinds of pre-plannings and pre-reviews and "status-checkpoints". Everything in JIRA + Confluence + Excel lists. And every "spill-over" is a giant drama, which requires even more bookkeeping and discussions. And god forbid that you don't deliver the ordered SP over multiple sprints, because then the customer starts all kinds of additional monitoring and tracking because the release might be in danger. And of course all developers have 0-2 years experience and each team has a scrum muster who never developed a single line of code, but has a certificate.
SCRUM was never a great experience, but not even a single year in that car company burned me out like crazy - I'm so done with SCRUM and agile in big corporations. And all that for a bunch of backend systems which must be ready in a year (of course as microservices...), so many aspects of scrum don't make sense anyways. But then you get stories like "As system A i want a masterdata batch job so i can transfer data to system B".
So personal ranting aside, i see a giant software crisis ahead because every year we throw more unexperienced developers into unexperienced teams, give them an unexperienced "scrum master" and a Cargo-Cult-like process and let them build software, which is not maintainable anymore after 12 months. No specification, no documentation, just unreadable unmaintainable code. I guess I will spent the rest of my career reviewing and firefighting projects and maintaining unmaintainable messes.
This is probably close to as bad as I have heard, what a ludicrous position for this company to allow itself to end up in!
you speak my soul out. I worked in 3 medium to large German componies with scrum and they are experiencing the same what you described. The solution is simple as it is to throw out scrum and all the bastards that make money from it, but noooo management forces to continue doing bs.
I feel you, this certain car manufacturing company also seems to have adopted SAFe which completely perverts the whole point of agile, having the "agile" teams commit to a 3 month plan, which of course never goes smoothly, leaving the teams scrambling to find "temporary" solutions to meet the unrealistic deadlines, which in turn leaves a mess of unmantainable code in its wake. I seriously don't think i will make it to one year without burning out as this has completely drained me of any joy i used to get from the software engineering craft. Sorry for the rant, just commiserating 😀.
"where EACH STORY is a fixed price contract" - that sounds like bureaucratic hell.
We have to understand that what you describe here is neither SCRUM not agile working. Your company uses the agile planning tools and name it agile. I wouldnt blame SCRUM in this case, but the company who implemented something different.
I like you comment, it reflects what goes wrong in many companies.
As a software engineer, I've yet to see Agile succeed in the workplaces I've been in that tried to implement it. And the failures have been spectacular and would be funny if they weren't so painful to have to live through. I've seen grown adults cry during stand ups, and retrospectives devolve into finger pointing, name calling, and even chair throwing.
That is unfortunate. I have almost the exact opposite experience. I worked as a consultant, leading teams using Agile and the Scrum framework to develop small and large client projects. Most of the project failures had to do with unrealistic expectations set by the sales and sales engineering team with the client.
I'm a heavy introvert and find overcommunication too much, Scrum is something I also despise. It causes over communication which is leading me to be burned out and loose all motivation, an endlessly growing list of tickets and stress, I don't like talking to people too much and when were talking its making me loose focus on programming
Try creating a product that has a budget and hiring a staff of engineers to build it. Then you will understand why understanding where a project is at is important.
@@saiinethe problem seems to be the way the project is managed. Rather than paving the way for the project to happen, you’re getting overly involved and preventing the workers from actually progressing.
Lead the project, don’t outsource and “manage” it. If you’re paying attention to the change log, or tickets or whatever, those should tell you where the project is without asking anyone.
@@mecanuktutorials6476assuming everyone is keeping the state of affairs up to date.
After about 3 years of work, i rarely hear anybody uses their introvertness or extrovertness as a factor to any decision in work.
I’ve seen extrovert devs that do deep work and introvert sales folks who talk to several prospects/clients every day. You just learn to do the work.
In my former company I had developers who focused only on analyzing traces and fixing bugs if they were obvious. There was not much of a communication ongoing with this guys, but it seemed to me they felt happy.
In this case you should think about a position where you can just program or fix/document software. Beeing a SW developer is less about programming, but more about communication and collaboration with other parties to find a solution. Once we start to write code, the actual work was mostly done. To this point we spent tons of hours in meetings, design documents and feedback loops with the stakeholders. This does not urgently apply if we decide to implement a fast prototype.
My experience with Agile/Scrum is that it's implementation constitutes all of the things that the originators said NOT to do. Pile on the concept that in product development involves estimating Jira tasks for yet unknown implementation details for features never done before, standup meetings that on their face are status meetings, more meetings for accountability when schedules predictably slip, and what you have is stressful results bordering on abusive.
Unfortunately this is what happens when people get too cult-like about stuff. Both cult-like in the sense of unwavering devotion and in a cargo cult sense: do this little dance and higher productivity will come!
As someone from the creative field (where iterative thinking has been the status quo and dominant philosophy for the better part of a century and yet NOBODY uses the same method) it's been simultaneously amusing and incredibly frustrating seeing the tech and corporate worlds grapple with this "new approach".
Early days everyone latched on like this was the second coming of Jesus and anyone who dared criticize did it wrong/didn't know what they were talking about/didn't do real agile. Forget the input of whole disciplines whose experience was not reflected in the design of these methods, whose work didn't even FIT in the structure that was now being imposed on it. After all if "17 very smart people" said so, who were you to suggest otherwise?
Now management and corporate are doing their usual trick: take what high performing teams and people do and distill it to a paint-by-numbers version that fails to capture the essence, so people who don't really get it can do predictably mediocre work covered by a thin veneer of the original.
Every single methodology can and should be questioned. The manifesto itself is also something that should be questioned, because it's not THE infallible, single expression of an iterative philosophy. Its assumptions and constraints do not apply to every project, nor every stage or activity within one. Every single one of its points are going to be the wrong call in a certain context.
100% agree with this!
And stories grouped into epics which are then grouped into what can only be described as waterfall projects ...
If I was a student majoring in computer science, I'd take math classes such as liner algebra and a statistics class with calculus as a prerequisite as well as some electrical engineering classes and look for jobs in real time embedded software and more math intensive products like inertial reference systems. You don't have anything until almost everything is nearly completed, which makes these product lines more scrum proof.
Working as a software engineer was better back in the 80's and 90's before agile scrum. I graduated college in 1982 with a degree in electrical engineering and worked as a software engineer since 1987. I started working exclusively as a contractor in 1990. Since I mostly work in real time embedded, safety critical software, I hadn't heard of agile scrum until 2016. I worked at a job that does agile scrum in 2021 to 2022 and it was like being a character in a dystopian sci fi movie, with all their cult like behaviors. Most of my career I worked autonomously and was treated like an adult. With agile scrum and the pointless daily morning meetings, employees are treated like six year olds. I just started working what will probably be my last contract job before I retire for good, with a former employer that makes inertial reference systems in the commercial avionics industry. The reason I went back there, and not some other companies is because they are not doing agile scrum. It is good to be able to work autonomously and be treated like an adult.
I can only echo this. I have worked with / for several companies using "Agile and Scrum" and in my experience it's been a tool used to micro manage the development process and give managers (BTW I have managed teams myself) the illusion of regular progress and control. In these companies progress was measured by the completion of artificial tickets and lots of time is wasted with inefficient tools like JIRA.
I'm sure Agile and Scrum is properly implemented somewhere but I haven't seen it myself yet. So when a company empathises their "Agile process" I get suspicious. When they start talking about JIRA I get worried because. If they have a scrum master I am genuinely scared !
I think the root problem is one of competence. If you have a small group of highly talented engineers who work well together then almost any process will work. So you have very skilled people defining a light weight iterative process and some basic principles as “agile.” Then you have a mass of management and mediocre software developers trying to apply concepts that, while simple, they don’t fully appreciate. Most software developers think they are great. Not everyone can be the best. The majority are simply code monkeys. The folks who defined agile originally are probably all really smart. Often smart people underestimate their own ability and drastically overestimate the ability of the average software developer.
I had a conversation with project lead who is also a very senior back end dev in the company leading a team of some 50 ish people, I could not believe that someone of that "competence" would ask how much space do you have for client side cashing of network requests in a browser. As if it even matters you will send that same data many times over the network if you don't do client side cashing and you can limit cash size and fetch what you can't store. I guess that is what happens when you don't have anyone to tell you what you are doing is stupid for a bit too long.
I totally agree! The process doesn't matter as long as you give engineers clear (concise) requirements and we'll make it work.
One of the issues we face with daily standups is that you need to have accomplished something substantial every day; otherwise, it feels like overcommunication. Not all engineers possess that ability
@@kilamoblack7532 And actually a standup doesn't serve to say what you've done and what you are going to do -- that is actually why they are so useless. It's about seeing if there are impediments for certain stories.
This is why I really don't care for them -- at all of agile. I know the big picture and how to work towards that end goal. And if things are unclear or there are problems, I will talk immediately to the people hindered by this or some how involved.
In Special Effects I never had a meeting after the initial requirement briefing. You just work towards the solution only when the dead line can't be met you call the producer. And frankly I never had to do that.
As a certified Scrum Master I actually love a lot of your points. Just my experience, but I've found elite teams don't need a framework at all; excellent people driven to work together just get it done. But far too many people - both on the technical side and business side - need to be dragged into complying with transparency and regular inspection. Even as a Scrum Master I would drop Scrum in a heartbeat if a company embraced most of the 4 Agile values and 12 Agile principles and embraced the idea of not only continuous delivery but also continuous (or more realistically, somewhat frequent) improvement to how we work. Almost all the Scrum hate I've witnessed first hand has, upon deeper probing, been frustration with how Scrum exposed underlying organizational problems that needed addressing regardless of what framework we used. For me, Scrum is like training wheels for both business and technical people on how to work together. Once we embrace a path to continuous delivery and sincerely asking on a regular basis "How can we do better?" then all the ceremonies and buzz words can go away.
" Almost all the Scrum hate I've witnessed first hand has, upon deeper probing, been frustration with how Scrum exposed underlying organizational problems that needed addressing regardless of what framework we used."
In a sense, that is Scrum succeeding. My POV is Scrum/Agile does not solve your big problems. It exposes certain kinds of information that makes certain kinds of problems more apparent. Whether the team and management decide to solve a problem, well, that is a choice. Since the problem was not solve already, you can bet it made someone uncomfortable to address it in the first place.
It's like the Kimba: The white lion story. People read and watch every piece of content on the Internet without confirming the credibility, but they spread the bullshit everywhere. I read so much Scrum dogmatism, articles made by Scrum priests and other nonsense. Scrum, agile and other phrases are now weaponized. The whole thing is really sad because it was really eyeopening when I 1st saw the manifesto and I researched it.
Scrum masters' work is to unshit agile and start the tough conversations with the management. Not just facilitate a retrospective and having a coffee with the team.
If you get it, you don't need Scrum. If you don't get it, here's some cargo and there's a path to march along.
I have been fortunate to work in a few "elite teams". I don't agree that it is automatic that you get the best results, just because the people are good. It takes more than that. You can make a good analogy with sport. If you want to be world-class, you need to pick the best players, and you need to work hard on training and strategy. Best player alone will loose to less good players who have better training and better strategy. I have seen this for real in real teams. I once worked with a bunch of genuinely great devs, but they didn't work as a team, and though their output was very good, it wasn't as good as I had seen produced before, with less skilled teams. You need smart people, but you need to find smart ways of working too.
@@ContinuousDelivery, we agree then that having great people doesn't guarantee great results. I've seen that common mistake: People falsely believe top performing individuals make an elite team. I disagree with that belief.
When I wrote "elite team" I meant those who are not only great individuals but who are great at working together as well by embracing the principles of agile whether or not they embrace any particular framework, and by doing so can forecast accurately, deliver bug-free features quickly and incrementally, and most importantly delight the users. One of those elite teams was considered by many to be the "lesser" team despite their phenomenally high quality output, because another team had "better" individuals despite those top-tier individuals being unable to accurately forecast, unable to deliver incrementally, and unable to deliver code without more bugs than features in it.
But I see how the wording of my second sentence from my comment could've let you to think I was saying the opposite.
My first experience with Agile/Scrum outside of college was as far as I know a full-on implementation of the techniques. So I feel that I can speak to Agile/Scrum. My first understanding was that Agile/Scrum is a way to allow developers to sort of manage themselves, with acknowledgement that they can't get away from management completely and therefore tack on the idea of accountability to make it fit in a business context. But instead it has become a way for the business to micromanage developers. Agile/Scrum, I thought, was a way to identify work that is blocked or not working, and to fix it as a group. But In my experience it was not always done with the right attitude. Agile/scrum techniques are meant to quickly identify developer problems. Since everybody is different, all developers have different abilities. And so developer problems can also look like problem developers; problematic or underperforming developers. It can put rockstar developers on a pedestal, since they are responsible for making the burn down charts look good, and incentivizes those developers to look out for themselves. Instead, you have to have the right attitude, so that solving problems as a group means working with the group that you have. If you don't do that, it incentivizes developers to cut corners, in order to make artificial deadlines, and so you end up with bug-driven development instead of high quality code. The same goes for deadlines, where strict adherence to deadlines incentivizes mediocre developers to avoid taking the time to build in quality, and to cut corners instead, since only the top performers can be safely transparent.
Apparently they didn't teach not to write in walls of text at your impeccable institution. Also, you're wrong.
@@redflipper992 Scrum is garbage. It is only useful for junior little bootcamp developers who actually need micromanaging in order to be somewhat effective. So how much did your Scrum cult leaders pay you for your comment? Also Scrum masters and Scrum coaches are a waste of space(and money). Nobody competent takes the "Certificate" seriously.
Scrum exists like a virus that steals the joy away from coding and building software. It's only great success is its ability to convince upper management who know nothing about programming that it is actually useful. Using false claims of 2x productivity boosts and promises of providing tools upper management can use to observe developer productivity. It is all a load of BS, full of meaningless metrics. It isn't hard to claim 2x productivity boost from sprint 1 to sprint 10 when developers simply adjust the ranking of story points attached to different tasks in order to create the impression of increased velocity(because increased velocity is what management wants, even if it is meaningless). So tickets that were ranked a 2 in sprint 1 are ranked a 4 on week 10. This creates the appearance of a 2x productivity increase while when it comes to actual functionality being put in place(real productivity) there has actually been a decrease because in sprint 1 developers underestimated tasks and were forced to work overtime to meet the commitments(that weren't actually supposed to be commitments). The next 9 sprints were spent ranking the tickets as being increasingly difficult in an attempt by the developers to reestablish the maintainable pace that they used to have that allowed them to actually write good quality code before the nightmare that is Scrum was instituted. Of course the developers can't say any of this to management because that is how you get fired(You can't question the scrum religion that the Scrum evangelists sold the CEO on and who now believes it has provided a 2x productivity boost).
@@jacoberinc that's a whole lot of text I didn't read. If your code is anything like your writing, I'm not surprised you haven't been hired to a competent organization which has resulted in your awful take.
I'm a mid to senior dev that spends a lot of time reading Plato/Socrate and Stoicism related things, and I have in the back of my mind for a while to give a look at scrum and agile methodologies, but what Alan says here just flickered the light switch in my mind about what it's its use: "if we only paid attention to each other as human beings and worked small and did things iteratively [...] we don't need any of this agile stuff...".
Oh, boy... How that just made sense for me!
There are some serious problems with extreme programming. Having people sit close together without any privacy or personal space. Which is then contradicted by wanting people to be focused and free from distractions. Then there is pair programming, the perfect way to induce increased stress, fatigue and ultimately burnout. It is a practice that takes giving people no privacy or personal space to it's extreme. These practices seem to be driven by people who have no need of personal space or a quiet place to work.
The problem with scrum is that it becomes a cult focussed on the ceremonies. You may not abandon the ceremonies even when you don't need them. It is also common to blame the implementation when it goes wrong while simultaneously attacking a parody of waterfall.
Another issue I encountered with scrum was management expectation that it would inherently improve performance regardless of a team's pre-existing performance. Then what happens is that management starts interfering in a team that already performs well and produces quality results.
As a serious introvert I can confirm the pair programming issue with XP.
@@karoshi2 yes, I can understand. In fact, it's not for everyone and it should not be imposed. Also, people shouldn't do pairing all the time.
Our team got a new scrum master recently.
He came in with a list of mandatory practices that cannot change. I asked about aligning some of the stuff to our business model to ensure that we deliver value more efficiently - he replied "we can't change this because these rules are fixed in stone". Okey, coooooooool. Really agile.
I watched this video at a 1.3x rate... every time Allen & Dave laughed together they sounded like Beavis & Butthead, but in a good way! 😂
They are broken because companies got the agile manifesto, throw everything away and kept only the “respond to change”. Who needs working software when we can push to delivery even with cumbersome release management processes? Who needs to talk with clients when we can have a surrogate called Product Owner.
The problem I've seen with Agile (particularly in larger business) is that it's a methodology primarily for management, not for software engineers. Software engineers become disempowered under layers of middle management ceremony, and product owners are often so far removed from the actual production of the software that they equally become disempowered. This leads to a true lack of actual ownership and quality assurance yet it looks good and sensible from a line management point of view (and there are lovely graphs!) so it's the defacto tool of choice for big tech brother. Nobody uses it on smaller more passionate projects which are often far superior in quality, as they actually care about what they're doing.
Which is kind of funny, since agile was created by engineers working in small teams in order to avoid the bureaucracy of the alternatives. It has been subverted and changed into what it tried to replace, which is really what Allen and I were trying to describe. The original ideas were, and remain, sound, the current commonest practice is far from what the creators envisaged, and it doesn't work as well as a genuinely agile approach.
I have been working without scrum during the last three months, and they have been the happier months in the last three years. Also I have delivered more value than ever. The last time I was that happier in my job and in my life was before using scrum in my first project.
Maybe Scrum is useful only for larger software projects where nobody has a clear idea about how long it will take and which features to implement first. Smaller individual projects bring higher personal pride, satisfaction and professional happiness.
@@mateiacd issue is that if scrum is for large projects, I have seen how the larger the project the more difficult, messier and stressful becomes.
Where are you that you work without scrum?
I worked for a company that used Agile/Scrum and it was an F'n nightmare. Nothing kills the soul quicker than this Management tool for total control. It's completely unrealistic to be able to predict the difficulty of many jobs when tickets are voted on. The constant meetings every other day, that's for a single project, is a waste of time and just adds more unneeded pressure.
This is one of my questions for interviews when they ask me, "Do you have any questions for us?"
"Yes, do you use Agile" It's a deal breaker for me.
I think they just used AGILE without even knowing the core of that. For my team we only have stand-up everyday (it only takes 5 minutes if no one has any issues, otherwise they would hold a separate meeting with only people who are blocked or have issues) then get back to work right away. On the other hand, we have a weekly meeting with briefly-prepared agenda to make sure it doesn't go off-topic, which usually only take around an hour or two once a week. It's not about the system itself, but the people who use the system that doesn't know how to utilize that to the fullest without making unnecessary steps.
I guess the AGILE conductor of your company is kinda wacked lol.
EDITED: Spelling
Exactly!
I got chosen as a scrum master (Because, despite knowing very little about it, I knew more about agile than most at the company I work for). Everyone is continually amazed when I say that I hate scrum despite my job title. I think I am the only one who as ever really read the agile manifesto or the principles of agile and I want to keep it simple. Management wants some crazy interpretation of scrum and are forcing it on the teams, because it works. I on the other hand keep trying to get teams to try XP and a Kanban board and everyone wants to fall back to either scrum or whatever we did before. Then, to coordinate teams, management pushed a bizarre version of SAFe onto the teams. So now we have a perverse version of scrum which no-one can explain with a perverse version of SAFe over it just because it pleases management. On the upside, I have very little to no accountability and very little responsibility and I am well paid.
Scrum isn't a lightweight wrapper and a few ridiculous meetings at many places. It's a complete efficiency killer with excessive disruptive meetings that prevent your talented devs from actually being able to sit down and get work done. I was at a job for 10 years and loved it, then quit at 13 years after 40% of my hours (not exaggeration) were spent in ceremonies accomplishing nothing while management kept trying to figure out why productivity was non-existent.
That's not agile then.
The very core of agile development to me has been to be able to transform the way you organize yourself anytime it is necessary.
If your company follows a stupid framework, forcing you to have of 15 meetings a week in different workgroups killing your productivity, you're not being agile, you're being micromanaged, you're in a control freak's wet dream, you have too many contention points or your company is taking "communication" too far.
If the company was truly agile, you'd see in your retrospective that all the meetings were holding people up and they'd change whatever was necessary to help the situation, e.g. by distributing the people differently among the projects, removing some meetings entirely, they might chose to not do a certain feature in parallel, they might need to limit the number of people per meeting (so not 15 people are in a meeting where only 3 people have something to say to something to get out of) or whatever. And if that change turned out to be way worse than before, they'd go another route until they'd find a modus operandi that works well, until it stops working well.
Scrum, Kanban, XP, they're all just starting points that, when installed first, might open up new doors and perspectives on how things can work and break a crusted dysfunctional structure, but they've got to be massaged into your individual form, if they don't work for you properly.
The first thing for me to understand is that "agile" is not a noun.
If someone says they're "doing Agile", they're executing a fixed recipe, which is the opposite of being agile. Being agile is starting from a base recipe and making it your own and perfecting it to your taste, knowing that will change as well. being able to quickly react to your own and your customer's need is the main focus and it doesn't matter at all how you do that.
@@brixomatic my whole point is that what agile has become is all of the things you correctly say it should not be. It's been turned into it's own industry and sold itself to basically all companies with IT except maybes if we're talking startups. Scrum in particular has been sold so well it's become the universal standard at every company Ive worked for or applied for, yet it's the variant with endless meetings and pointless ceremonies that provide finely structured updates to clueless executives but chokes developers to the point they can't do their work.
@@TomSolo128 I know exactly what you're talking about and I'm with you on that.
This is what happens if people say we "do agile", but didn't get the memo that they need to be agile. Instead they got someone with a certificate who teaches "the method" without getting its main point. All they should really read instead is the agile manifesto with the last line being the most important in my book.
Agree with you 100%. It inevitably turns into an environment of excessive meetings. It not only kills productivity, it becomes mentally exhausting. It becomes very difficult to even start in on work because you are anticipating the upcoming meetings or the meeting that will materialize on the spot.
Really? How does that work? Are your developers clairvoyant? Do they automatically understand the problem they’re trying to solve? How simple is your product? Your developers must be amazing if they never have to research anything and just start coding without any input at all. That’s … unbelievable.
I think reading, pondering and understanding the philosophy of Agile is a good thing. Being dogmatic about something is rarely practical though.
No framework is going to be useful when your employer (in my case past employer) keeps making the same mistake of sitting on things until they need them yesterday. In my experience some managers just want a patsy to blame for their own incompetence.
it's manager like him who are the worst.. they use others who have skills for everything.. everything they know they stole it from others and they produce mostly 0 quality code.. this is why they always ramble about non technical stuff.. like if it's of any true importance.. who the people are when they are good at what they do.. it's your job as a manager to use the best of your people.. they can be junior or superstar coders who cares.. it's your job to make the best out of it..
"THANK YOU! THANK YOU! THANK YOU!* I wasted so much of my working time (and life time) in completely useless agile meetings instead of contributing to the code 😭 and no one wrote any tests!
So refreshing. No need for lots of arguments. Just gut feeling. I like :-) - Where i work, people use to say "lets make scrum", when we have a weekly standup. And i just feel like coming from another planet.
I have said many times before and many years ago, Agile and Scrum is basically MAKING SOFTWARE LIKE ASSEMBLY LINE. It is a process to force the creative software developers to chase one task after another on tight schedule controlled by management. Yes we all know schedule is tight, but once you try to solve the problem using ASSEMBLY LINE process, you are creating a chaotic environment that resulting in mess.
Two of the most annoying things about the way scrum is practiced, as a dev, is effort of stories and stand up.
EVERY SINGLE COMPANY (5+) requires devs to effort a brand new item/story/ticket, with no research done, using a unit of time. Whether its hours, or days. I thought it was supposed to be based on complexity, but that has never been allowed.
The other issue I have is the Stand Up. I thought it was supposed to be ONLY THE PEOPLE who are working on the items/stories/tickets that were needed to complete the Sprint were allowed to speak. Nope, its everyone giving their status of yesterday. Either create a item/story/ticket for every person so to speak on, OR just let the people with assigned items/stories/tickets speak. Stand up shouldn't be like 15-20 minutes long where the BA talks about an email they sent out.
Then you've worked at supremely shitty organizations. That's not how scrum is practiced. You should make better life choices and maybe you can get into a real company.
@@redflipper992 No, scrum and agile are shitty, phony systems. If they were any good, if they were intuitive and organic, they would always succeed no matter how good or bad the organization is. If they were good systems, this argument wouldn't have continued for decades. The only people who still champion this crap are smug people like you who like to tell people who disagree with them that they've made "bad life choices." Get over yourself.
I think you had (many) Scrum-ish implementations. I have been the Product Owner of a great Scrum team once and we NEVER sized things in hours/days, we just assigned story points and let the sprint unfold itself through the days. While in our daily calls (hardly lasted more than 10 minutes) the dev. team expressed what they had planned for the day and what problems they foresaw. Those with risks to their day would stay for a few more minutes at the end of the call to discuss potential actions with the Scrum Master, and that was it.
One last bit about sizing: As a PO I never asked a dev "how many hours would it take you?". Instead we would go through sizing during Sprint Planning using a tool (Scrumvee) and based on our team velocity & sprint backlog size, we could tell if a user story could be done within the sprint or not. After about 4 or 5 sprints, these estimations became better and better.
@@pedrofernandes4148 well said
@@pedrofernandes4148 The problem with story points is that it doesn't matter if the points mean complexity or time. It always means time. You can't plan for the team of a specific size, to accomplish a specific number of story points within a specific time period and not have story points mean time. If the time period is 10 workdays and 80 story points are expected to be accomplished in that time period and you have 4 developers on the team, this means | 80 / 4 | (20) | 20/10 | (2). So in this case each story point means 1/2 day of work. If it takes more than 1/2 day for a developer to finish a story ranked as a 1 then management will com a knocking, which is just annoying, creates unnecessary stress and makes the developer feel like he isn't trusted. It turns the workplace into a surveillance state for developers(arguably the smartest and most capable people in the company). Good developers caught up in this system will leave.
As a computer programmer since the 1970s, I've seen the same happen to every software development method as is now happening to Agile. I've been through no process, iterative process with 6 week releases, waterfall, spiral development, CMM, and now Agile. I'm currently working using Agile development and it has been much harder to get a handle on it. I feel completely disassociated with the team because we use Jira and tasks are broken down so much that you don't really know the reason for the change. I have to ask the team lead what is meant by its Jira story. You go back to the same piece of code you were working on a few months ago and it has completely changed because the developer working on it decided to refactor the code as part of his/her Jira story. You end up with no expertise in any area and sometimes completely out of the loop. It's very frustrating.
I read the agile Manifesto long ago and it helped a lot. I still stand there. Didn‘t find any better. I think, a developer, who does things „because it‘s done this way“ already is on the path to get stuck.
Are most companies applying the agile manifesto correctly? Like the way it was intended?
Scrum is absolutely training wheels for a business.
That said, the one thing it fixes that I can't find a good solution for is estimates.
While working small is key, we need to work towards something larger. At the end of a quarter we've iterated our way in a targeted direction.
This is why estimates are important. Would you order off a menu with no prices? Maybe if you have cash to burn but small businesses do not. To answer whether I want something or not I need to know what it costs.
I haven't found a good way to do that without using some kind of scrum process.
The funny part about the methodology of software development is that the essence of the agile principles was formulated in the fundamental paper that people blame for the waterfall model. It was a paper by Winston Royce "Managing the Development of Large Software Systems" published in 1970. That paper was most largely misunderstood and distorted. However, Royce in fact was suggesting to do a miniature process of development, on a small-time scale, test and then integrate the results in the design changes. He also suggested involving the customers: "For some reason, what a software design is going to do is subject to wide interpretation even after previous agreement. It is important to involve the customer in a formal way so that he has committed himself at earlier points before final delivery."
Yes, I spoke about that a few years ago, you can see me describing some of Royce's stuff in this video, from about 06:35 th-cam.com/video/nauFRW6gYjc/w-d-xo.html
@@ContinuousDelivery Yay! This is great. I am glad to meet a fellow engineer, who knows about Royce.
Exactly. I worked in companies that used waterfall properly.
"It's called a stand up, because everyone hates it and it is not funny".
In my case one client insists that we would be Agile and wants us to do daily meetings with them. But all we do in those meetings, is just status reporting.
Had the same but also with did everything internally also, I had twice the meeting a day were no one listed until there was a huge problem and then it was my fault.... good stuff.
like others say it justifies a lot of otherwise unneeded roles. it's the managerial class's self-justification of their existence. the managerial class are the people who decide among each other that they are the decision makers and strategists and others are to merely execute on their ideas.
Agile strikes me as being glorified prototyping, except that it gets in the way.
Magic comment
I'd love to hear Allen and David discuss the way Agile Coaching has evolved from the time Lyssa Adkins & Michael Spayd became famous in the Agile Community.
There are actually two SCRUM-organizations. One that has a high focus on monetizing SCRUM, and one that really don’t try to.
The seasoned developers are already familiar with various systems' requirements and don't need to be guided on implementing what they already know. Spending time in endless meetings will definitely reduce productivity and make the development process so tedious.
Exactly. It's just a magic pill for a dummy managements that gives illusion of control
Agile has turned into a burden for developers and a godsend for managers to look relevant. Reminds me of the high priests in Egypt performing rituals to predict the overflowing of the Nile River. People were sacrificing their belongings to the priests for naturally occurring events. The priests were deceiving the people for their own benefit.
The people in charge are usually clueless about what actually makes development work, so they are easily deceived into believing that some mindless rituals will actually deliver tangible results. And nobody is going to tell them the truth either. And so, this madness will go on until the next mindless hype comes around the corner.
Great video on the subject!
After year's of working with the largest organizations Ive said this once and ill say it again, Agile is not a process, it's a mindset. People forget Agile has a become a backlog for waterfall. Let's either scrap the entire agile methology or completely adopt it to it's fullest. Imagine saying to an organization hey let's do a partial change management.
Agile is a set of values and principles about how to build software.
What a fun interview. This was like watching two giggling school boys having a good laugh 😁
I worked with IT for more than 25 years. Agile broke me. I refuse to work for any company that claims to be Agile.
Love it!
Slightly different take on Scrum. I can see why you say it's to sell more, but there is a second purpose. A lot of people don't understand how to work in a self-organizing environment, so Scrum provides some 'training wheels' for people to get used to it. The Scrum Guide also used to say that people should eventually evolve beyond Scrum.
Also agree completely with the point on the word accountability. Throw empowerment on that list too. You can't empower anybody, because the entire idea that you have authority to give them power means you have the authority to take it away. People have to decide to take ownership of their actions and results and the best you can do is encourage them to do so.
I agree that Scrum can act as "training wheels", though I think that Allen may disagree, but the problem is that it very rarely seems to succeed at the training. I see lots more orgs that aren't agile at all, where Scrum is seen as the problem, than I see orgs that have used it to do the training and got to the good stuff.
@@ContinuousDelivery totally agree that a lot of people don't do well with Scrum and blame it for their problems, but saying Scrum doesn't work is kind of like saying a diet doesn't work. Most of the time, it's not the diet but the person using it.
For those of us in the coaching space, it's tempting to blame the client when things aren't working, but it's our job to educate them and show them the way. It's only in rare cases where the people we work with really can't be coached.
The teams I work with rarely (if ever) blame scrum from their problems and my clients average over 407% increase in their KPIs.
@@OrganizationalEngineering Which is certainly my point, and I think Allens, Scrum doesn't work well, on average, at really delivering value, most Scrum adoptions don't end up being agile projects. Whereas I think that pretty much ALL XP adoptions or Continuous Delivery adoptions do. You can't duck agility with XP or CD, as you can with Scrum.
So while Scrum maybe easier to adopt, it is easier to adopt because it is easier to cheat. So I don't think that Scrum really adds anything to XP or CD, and XP and CD are a better route to real agility, than Scrum is.
@@ContinuousDelivery I follow you. If you implement CI/CD it will enhance your ability to deliver and pivot quickly.
That doesn't mean Scrum is bad though. There is a lot of value in having regular touch points to discuss the plan and to identify the next thing you want to improve, especially for people that don't naturally think about those things.
But not if people are forced into doing it against their will, which is how most companies run their transformations.
Replacing and flushing all the fluids at least every 50 miles is so important to keep bimmers behaving properly. It's so worth making sure the front diff, rear diff, transfer Case, transmission engine and brake fluid make such a huge difference in behavior and avoiding damage, breakage, and failure.
I've been trying to bring this to my colleagues like 10+ years and guys always have been looking at me like I was an idiot who was trying to say bad things about saint Agile/Scrum :)
During all these 10+ years I saw none Agile/Scrum usage success story and it was always some ugly/funny variant of it :)
I think of Agile as a piece of music and a manager as a conductor, so most of the time people are just bad at conducting lol.
But I still think Agile and Scrum are pretty good when the manager know at least briefly about everyone's work pipeline so that they can assign task appropriately, which I don't think that's the case for everyone (T _ T" )
@@polawattantiransee3410 It is probably like 1/5 implementations of Scrum in an organization ends up not being a nightmare for developers and in all of those cases it is due to management being really gifted. In all of those successful cases the team would have found more success and developers would have found more enjoyment developing under nearly any other framework or just a kanban board with a ticket backlog where adjustments are regularly made based on priority and time is made available as needed for planning, architecting and mapping out functionality needed for each thing.
Agile is an idea, a suggestion, it is not a standard…that is why it became a monster; interpreted by everyone as a strict way of executing projects, and that is the problem.
Daily scrum is a waste of time, as well as all the ceremonies around. In reality a good Manager and leader knows how to organize a process and the teams if guidance is needed, the leader can provide guidance and decisions.. finally at the end People should behave in a professional way to perform all assigned duties.
As I got enough experience to have demands as a sw dev, I demand that there are no or very rough estimates or I quit, and it works where I work now.
I've always been amused coming across people who call themselves "Scrum Masters", and then you ask what projects they have done, and they haven't done any. They did a certificate course, got a certificate, and that's that. You're not the master of something if you've never actually done the thing you're claiming to be a master of.
💯
I come from the other side, having worked for decades on many projects in everything from tiny to very large companies, but no-one would allow me to be the scrum master because I don't have the piece of paper.
Doing the work in the right way is improved by Scrum as a stepping stone to XP & Kanban. Scrum also creates space for clarity of doing the right thing. Product ownership is crucial for clarity of intent and surfacing and resource assumptions. Agile helps with getting both the how and the what right.
Scrum creates a surveillance state where developers are stressed out and constantly forced to explain why such and such took longer than anticipated based on an estimation that was based on a poorly worded story they they were forced to make an estimate on with only 1 minute of time to consider how complex the task is going to be. This causes the dev to over estimate the next sprint in order to avoid the stress only to be hit with the "looks like you are working faster than anticipated you should be more aggressive with your estimates". So next time you estimate more aggressively and repeat the first experience. So you then estimate less aggressively the next sprint and pretend that the tickets are taking as long as you estimated they would. Now you are successfully hitting your estimates. What a great Scrum success story.
@@jacoberinc I totally agree. Scrum all too often is instantiated poorly by people who don’t know what they are doing
I hated agile when it was introduced at the company I was working at in 2016 but after awhile of doing it, it did start to click and help a lot. Then I changed companies this year and I'm back to hating it, probably even more than I did originally. SAFe is profoundly awful, and has really made software development a miserable experience.
I also would say that Scrum master/ADL roles are a joke. They provide negative value to the situation and just get in the way. They are never technically in tune with what's going on to actually help with unblocking things. Agile was much better for my team at my prior company after they eliminated the Scrum master role.
Even scrum master hates SAFe, we can say UnSAFe at any speed, you just met a bad implementation in your new company.
That sounds like you've had some bad experiences with scrum masters/ADLs. The scrum master/ADL role should work like a coach works in any sport or personal/professional development. They are there to help you. Think about how can they make you better wherever you need it. Personally, I don't believe there is ever a point at which we are done learning, so there should always be opportunities to grow and improve. The caveat to that is that your company has to align with that belief and the scrum master has to believe it as well. What we think informs what we believe and what we believe informs how we act. So, if a scrum master believes that a developer would need to change some aspect of their behavior, they have to find a way to change that belief. That is all soft work and not simple at all. Nobody teaches any of those skills in scrum master training and that, in my opinion, can result in some poor experiences. Something like your scrum master just telling you to do something because "that's scrum". Or getting you to do certain things so the metrics turn out a particular way. Your scrum master/ADL should be providing a safe space where the team can talk about anything - and that includes if you believe the scrum master isn't helping. Have that conversation. If you believe in individuals & interactions and continuous improvement, it should be a welcome conversation.
I'm a software developer since high school, professionally for 5 years, and then I've become a Scrum master and actively doing it for 5 years. Usually, I don't get along with other Scrum masters, because of the reason you mentioned. I think this role is vastly misunderstood and under utilized. Where I currently work, people hated Scrum masters and used them as scribble and task board maintainer or secretary. When I got there, I had to prove them that I'm not the Team's jester and I am capable of doing much more than the others. Now I'm equally a team member as others, and for example there are success stories where devs needed support for management negotiations, and we together had an impact on the whole project. People in the organization (hundreds) know my team's name because we deliver and innovate.
OC it is not my achievement alone, I have a great team!
Scrum "master" role is a fake worldwide
@@huaweihonor7714 the same with your phone lol.
I think the problem is that managers, want to speed up all things, with crowded sprints, in order to use the framework to improve the products quality with some small tasks.
The problem can be the car, but the driver has to many fault in this too!
yes this is essentially the main problem, it is the way management abuse the process, and the scrum master is supposed to protect the developers from the management bs. The other thing is AGILE is never about making things goes fast, is a measure of how screwed up a project is.
Thank you!!! 🙏
Could someone please tell me in which video/post Bob Marshall addresses the topic of "language of violence"? I'm quite intrigued by this but couldn't find it.
100% agree, just thought I was just an outlier.
But I ain't one to gossip... .
Agile, Scrum and Kanban are the names of three energy vampires that drain the blood, soul and decency from otherwise creative and effective developers.
I'm so glad I retired last year from a software developer job. I don't miss the Agile/Scrum/Lean/ call it what you want BS one little bit 😊.
I get it being agile and doing agile or not the same thing. The problem is it's really hard to teach a way of thinking, it's much easier to teach a process and framework at scale. I don't like these videos because they only criticize what not to do and don't tell you what to do
Well said. These two were scoffing away like they knew the recipe to some magic sauce. Ha! Scrum! Look at these hilarious people doing the agile! Unbelievable! SMH
Agile causes lot of stress, burnouts and turnovers. Top managers and organizations seem don’t care about it!
I think scrum only works for a well predefined projects with good stakeholders.
I find that in reality scrum is pushed to teams who are not working in clearly predefined projects.
I like working with kanban, and if needed use scrum for projects separately under the kanban umbrella.
To me the main problem with agile in large corporate environments is that agile is by definition a bottom up approach to do business. Meaning devs/SMEs tell managers what they should be doing in order to succeed.
But management still holds on to the top down approach telling the devs/SMEs what they should do. It clashes in the middle obviously and creates disfunctional teams without mandate. It destroys the spirit, creativity, trust, motivation etc.
Extreme programming is one solution, but doesn't really solve the mandate issue.
High performance teams could make a difference. I've seen examples, coupled with a strong mandate, they can make enough changes high up the command chain that it works.
My experience is that the agile principles on their face are actually pretty good: continuous delivery, embracing change, frequent reflection, testing new ideas, and most importantly, letting the team self-organize.
My experience is also that Scrum is a terrible monster that needs to be driven back into its cage. Scrum is not Agile. It is a management overlay of Agile, and has wreaked havoc on my team's ability to get things done.
is allen doing live XP videos ? curious to see him operate
Since I have been in Portland I have been in 4 “Agile” teams. In each case, it was clear that management had never seen and had no interest in reading the Scrum guide. In each case management fully expected to interfere with any given ceremony, or force us to stop in the middle of a sprint to work on something unrelated to the sprint, or Palpatine us into “stretch goals” whenever it suited their needs just so they could tell their peers that we have doubled our efforts.
In short, Scrum has become an excuse to begin dev immediately without gathering requirements or understanding the roles necessary to complete a project, otherwise it’s waterfall or generic iterative dev as usual.
It is particularly frustrating to hear how much Scrum was compromised to sell certs because most orgs never intended to follow it in the first place. They seem to have just wanted to be associated with the sex appeal of implementing “scrum”, never mind the inevitable churn, burnout and turnover.
Gathering requirements? Not even that, they don't do that anymore.
@@errrzarrr Exactly, it is often how long do you think it will take to implement this poorly written story that you haven't seen before and whose functional requirements, architectural requirements etc haven't even been considered yet. Now you have 1 minute to read the story, and 30 seconds to consider the architectural and functional implications in order to make an estimate of how long it will take. Which we are going to hold over your head later when it inevitably takes more work than estimated.
Exactly
Love this guy
When I met Ken Schwaber 20 years ago at an agile development conference in New Zealand, I asked him what things organisations did most badly. I thought he was going to bash waterfall methods or promote scrum. Instead he said 1. They do too many things at once and 2. They fail to prioritize. After 20 more years in IT I couldn't agree more
Yes, it is nearly all about getting the fundamental things right, the rest is process ceremony.
At first I was like, no agile is ok. But you made me realize we have actually the version you mentioned video that makes sense (no stupid meetings no scrum master etc). You may call me lucky that I never worked with the "by the book" agile scrum bullcrap.
agile and scrum made me switch my mindset in programming from loving doing programming it to consider it as work then i watched silicone valley
I know person, who is a Professional Scrum Master with 2nd level of certification(and close to 3rd level, to be honest), he just want to do his job well and happy to work so. Main work of Scrum Master is a boost productivity of his team. He raises performance of his team up to 3 or even 25 times(!) during 3-4 months per team, several different teams, several companies. No extra programing trainings or team members replacement or jira statistics manipulation. Basically, he used and keep improving base things like an "inspection" and "adoption", which are you scoff at.
Just to be clear, I am pretty certain that Allen wasn't scoffing at the idea of "Inspect & Adapt", but rather at the way that people talk and think about it, characterised by the saying things like "Inspection and Adaption". This is a misuse of English, the word "Adaption" exists, but doesn't make sense in this context. What that means is that people are using the words as tokens and not really thinking about their meaning. Inspect and adapt is a key concept, not just to agile, but to science, and Scrum doesn't help much with our ability to do that, unless other more important things are in-place, like Continuous Integration for example.
Not enough detail in this conversation. Just two people having a rant without saying much at all.
What is he suggesting as an alternative? Straight up XP? Why can't we use product owner and backlog to do the 'listening' and 'designing' part of XP? Why can't we use SCRUM to self-organize a small team and use sprint to timeframe our work? I might come from a different place, but I never had any problems with the various Agile/Scrum practices I've seen as a programmer, and yet I constantly see people dissing it.
My experience has been similar to yours and has been mostly positive. I think it all comes down to the implementation, and how some of these corps put to much process and additional meetings and retrospectives in what is supposed to be a straight forward development pattern.
I see it as treating something as a useful tool towards a particular end and treating it as the only way to do something. If the tool is working for the developers, great -- if management wants the developers to work for the tool (or if a group of developers focus on the tool instead of the goal), then we get "someone should release a stress-headache cure specifically for developers, you'll get rich." *And* bad product.
You can. The rant is about you should be focusing on being agile, instead of being scrum, though. Agile development means being flexible, the complaint is that when people are focusing on being scrum and treat it as the Bible, they stop being flexible, eliminating all the benefits of this development model. Why then use it in the first place at all?
as far as I could understand after watching this crap, the reason why is because he needs some controversy to sell books and present in IT seminars
If agile/scrum is broke, there must be an alternative presented. It's very easy to critizice. From my experience, things like estimations doesn't add that much value. But the sprint itself, and especially the retrospective event adds a lot of value.
Focused so much on putting Scrum down didn't get to the details on why it is bad.
I think their main argument was that it's superfluous in practice and cringe in principle.
Agility solves the issue of working on something that’s unknown till is known. Scrum adds some sugar on it by adding a bit of structure, aka Product Owner, Scrum Master, Developers, Stakeholders, etc.
The business still don’t understand neither agile nor scrum, because it is still focused on time and responsibility… instead of estimation and accountability.
The best approach for any business would be waterfall… but that doesn’t solve the initial mentioned problem, so it is being forced to deal with agility and unknowns.
The fact that business is always pushing towards waterfall and the development team towards agility… created a beast… I will call it “the tech debt of agility”…
And these guys are complaining about “the beast”.. nothing to do with agile, nor scrum, nor even waterfall…
The solution to this is pick a pure path… waterfall or agile and stick to it.
All the scrum coaches that exist are trying to make the business stay on the agile path, sometimes forcing it… because, at the end of the day… everyone knows, business included… that waterfall will put them out of business anyways… but still their natural way of looking the software development… they would love to use waterfall…
A couple of months the team knows what they are working on. Why not ditch Agile/Scrum altogether then? Oh no. That's not the intention at all to begin with.
@@errrzarrr All the scrum coaches that exist, exist simply to sell Scrum to upper management. It doesn't change the product that needs to be built nor the amount of work that developers need to do to build it. All it really does is add additional cost in the form of scrum coaches and scrum masters while putting the cost of their salaries on the dev teams.
It does nothing more than burden a team with meetings.
I believe that those who are not focusing on a product, which can be continuously improved and released, they cannot be truly agile.
When you center development around one or many projects to focus on at the same time, then you enable micro-management and the benefits that the philosophy of agile software development gets lost.
Can you do a video about when to use libraries/frameworks and when to DIY? I feel like grabbing whatever we can and black boxing it is just bad.
I talk about about that in this video: "How to avoid big upfront design" th-cam.com/video/8GONv6jJsG0/w-d-xo.html and this one: "What Software Architecture Should Look Like" th-cam.com/video/ElMnHDSFaCw/w-d-xo.html
Work together in small batches .. delivering iteratively
Scrum meant to be used with xp
Rest is bunkum
Scrum and all those BS like story points, retro, daily draining meetings,etc make our job feel so superficial, unsecure and not enjoyable.
I don't have problem with Scrum because i believe in Flexibility & adaptability however Management uses Agile to track what people are doing instead of Looking at the Quality they produce. To me Quality is everything than just finishing sprint.
Wonderful genius comment at 03:45 "Extreme Programing without Scrum works fine. Scrum without Extreme Programing does not work at all" :)
I see you took my comment on the previous video to heart! 🙂
What was that? Is ironic to me that these priests that keep preaching about being "flexible" and open to change and criticism are the most rigid ones, take comments to heart and are NOT flexible to change. You can change anything in a project, except Agile, don't touch that even if the team dislikes it and proves is not working. I keep seeing this again and again.
I lost a couple of opportunities because I stated these same issues. Scrum and Agile are buzz words for turning "Geek to Speak" to senior management and are inhibitors to CI/ CD. Scrum and Agile have fallen victim to the curse that every new methodology encounters that becomes popular. It was originally created for a size of project or market sector and is very effective, but it becomes completely watered down in the impossible attempt to make it work in ALL projects. My business is a real two-week business. Scrum and Agile are way too bulky to leverage as our methodology. XP works without Scrum and Scrum doesn't work without XP. This is truth. But I would argue that nothing works without requirements and scope and that is where most projects fail.
Good points. When the ideology veers away from self-organizing teams toward cookie cutter patterns and individual commitment, the fun is drained.
This was basically just too old guys bitching about accountability. Total waste of time.
Have you ever been on a scrum team when you have a regular scrum and it goes well past 15 minutes it turns into more than just a scrum but sometimes you feel like nothing is accomplished with that extra time that in a nutshell is the ritual losing its meaning.
What do you guys say about kanban with xp..
People selling agile junk insist that the problem is NEVER Agile or Scrum or whatever. It's always teams "using it incorrectly." But if a concept can't ever be implemented correctly, then ultimately there's a problem with the concept. It's not taking into account the way people actually work, think, or interact even if it thinks it does.
If it only ever describes a mystical ideal that can only be implemented by a magical software team in a vacuum with no friction, it doesn't describe anything that can actually be used to get anything done.
I love agile cuz it pays me to fail hard, set up drama at the workplace and repeat the process.
Was at an Agile planning meeting in which it was clear we wouldn't make the deadline.. Too much work to little time.. Everyone knew we wouldn't make. Yet they pretty much forced us to commit to making it. Any person who felt we as a team could not make the daedline and commit would have to come up with a scenario in which they would vote to commiting, until everyone voted to commit. Only four people of around 30 were honest that they time didn't look feasable. Expressed my opinion but backed down immediately.. kinda weak on my part.. but seems like the meeting continues until everyone commits. Honestly felt like the only way I could say we can do it is if you can control time or bend some other laws of physics. But even before Agile the official story has to be we will make it until we don't regardless of red flags. Late news even came in while voting that a key component would also be delayed after we all voted... just ignore that new news and revote with more confidence as now everyone conformed. Manager gave pep talk that he was confident we would self organize and come up with creatiive solutions to the problem.
Be glad that you kept your mouth shut. Everyone else was willing to say they were on schedule. If you were the only one saying you couldn't meet schedule, the slip would be blamed squarely on you. Unpaid overtime is mostly political theater. Those overtime hours aren't all that productive (overburden). Management can claim the engineers are doing everything they can, while they leave early to get a haircut and pick up their suit from the cleaners. Gotta looks good for the big meeting coming up.
Introducing Scrum is the pseudonym of getting rid of middle management. But restructuring a large enerprise to be agile is way beyond the scope of the methodology and that is why most of these attempts result in the so called "zombie agile" which is what I think you are talking about.
It may work for small startups but may not work in the long run for large organizations.
It's all b/s, every single bit of it. People need these jargon to justify jobs with high pay for NO technical ability.
If I remember what agile is, it's a fancy way of saying: We're going to run around in all directions with our hair on fire and blindfolds on, and nobody will no why.
All these organizational ideas are ----, the reality is, you can't have a billion miles of management for programming. It's odd to call it an artisan skill, but at the end of the day it is. It's not designed for massive teams all working synchronously.
It's smaller teams, working to put something together...it's the only way to actually get things done well.
The real issue is in trying to find patrons to commission the 'artwork'. They start cutting the check and instead of getting the masterpiece, they start getting picky and demanding change after change, and the expectations are just too high.
Looking at web/web apps...how many scripts? It's like dumping more syrup on month old pancakes already drenched from it daily.
Constantly adding new scripts, draining user resources and destroying responsiveness to ensure you show someone the right retargeting ad for a watch they just wanted to see the price of, to laugh at the ridiculousness.
Of course we want the users addicted to the app, so let's add constant micro-interactions. And jumping all the way to the end... security...the dirty after-thought.
How do you properly secure this spaghetti? You don't... you've used so many techs, in so many ways that regardless of what you do, you cannot fully secure this mess. Log4j was just the beginning back when that sploded, the neverending throw more at the wall integrations will be our downfall.
Now, if I'm wrong in any of the above, by all means, start tearing into me, but...I think I'm fairly solid here.
I wonder, all the devs complaining here about scrum… did you ever try to use retro to optimize the process? I do it every time. After two months it works, after six months it's perfect. Maybe the problem isn't scrum at all?
The problem with agile are the managers, processes are there to justify the manager, but they behave as Tom DeMarco would say, news anchors reporting on the news for some sponsor or high manager, getting in the way and not providing any value.
Nice interaction this one
If being an agile trainer is someones only job in software, I figure they're like an eunuch. They know how it works.
only good part is scrum meetings ... but 2 weeks delivery to QA impossible.
Reading through the comments makes me wonder how many people who hate agile have ever worked in anything but an "agile" environment? Do they have anything else to compare it to? Would they prefer a CMMI Level V process with a 5-6 level deep detailed WBS with an Integrated Master Schedule and Integrated Master Plan with a critical path high-lighted that takes 2-3 hours a day to keep updated. Where everything but the actual code sucks up all the attention. I came to agile back in 2000 after working in a heavy-weight CMM process and started doing XP. It was a breath of fresh air. This is a great interview though and there are definitely a lot of issues with the way the term agile is thrown about and how lots of people implement agile.