Having gone through an 'agile transformation' which handicapped an engineering organisation which was pretty agile and effective, this resonates a lot.
before agile: 20 developers that get things done after agile: 15 developers, 5 team leads, 5 box tickers, 3 coaches, nothing gets done, the 15 developers spend 20 hours of their week explaining to the leaders, box tickers, coaches, what is going on, so they can submit their reports.
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.
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.
"the way it's infantalized what software engineering" you are so right on that one! Every day I feel like the only engineer surrounded by children who just pretend to software-engineers. Why? Because nothing is specified. Nothing is planned. Nothing is engineered. The solution is to start stupid half-baked ideas and then add a million meetings with way too many people, where the actual issue is not tackled nor solved. Agile development allows amateurs to write code without ever learning software engineering. Instead they just write code.
Before the advent of Agile and the Scrum processes, software engineering and design were more akin to an art and hand craftsmanship. After Agile and Scrum started to become a cultish mantra, software engineering turned into a Ford factory and assembly line with little to no creativity involved, it was all about delivery of your widgets as quickly and efficiently as possible, it doesn't need to be efficient and beautiful only that it's below budget, on time and it does the job.
"layers of process" Clearly, you have not actually been following Scrum if that's how it looks for you. There are a handful of meetings and other elements that describe what Scrum is, but the expectation is that these take the place of existing process and so forth, not "in addition to". Clearly, the people leading your transition to Scrum just had no idea what they were doing and neither did any of you who were adopting it or you would have pointed this out to them.
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.
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 😀.
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.
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?
I have had some fortunate experiences because of certifications. Not needing to get a degree that would have me in debt for years and instead getting certifications that tie to that job for example.
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.
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?
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.
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.
Is he certified in PSM or CSM? Or just some traditional manager who took over the Scrum Master role when his company decided to go agile???😂 We had one such scrum master who was not even certified 😂
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.
@@MeursaultYTthe 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.
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.
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.
@@c0r5e That wasn’t the case in the late seventies and early eighties when I was in college. Even today, it varies from one university to another if you look at the course requirements. I majored in electrical engineering. I have worked in safety critical industries like commercial avionics and medical devices over the years. These are products that have a very high consequence of failure. To inflict scrum on the employees is very dangerous. The time pressure to finish ”stories” by the end of those infantile sprints greatly increases the likelihood of bugs being released in the code.
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.
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 !
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 have personally lead teams from being under insanely hard PMI/PMP/Prince project management thumbs into flourishing engineering organisations delivering value and caring about the profession. What we did to do that was using parts of scrum and parts of XP tailoring it to the organisation. Picking things for our context and chucking things that didn't.
At a past job, we did Show and Tell's during sprints to show what we were working on and get any feedback. I've seen people have very heated discussions over datepickers, and a product owner basically walked out of Show and Tell after we told her the small feature we working on had to be done a certain way given the tech stack we were using at the time. Also have seen a lot of bike shedding too.
Wow you people are the definition of existing to create your own bullshit job. The fancyness and also non-concrete words you use reek of this. Hope you get fired. Because people like you are creating nothing. You are just creating your own work space.
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.
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.
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.
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.
@@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.
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.
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.
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.
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.
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.
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'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!
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.
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.
Agile is a tool for reducing highly skilled and experienced developers into interchangeable cogs while conferring their abilities to a sustainable level into a team of low-skill and inexperienced developers which cost less and don't make managers uneasy by being outpaced intellectually.
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.
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 ua-cam.com/video/nauFRW6gYjc/v-deo.html
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
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.
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..
A developer explained it to me very well. Scrum gives management continuous visibility of every single thing an employee does and how long it takes. There is no hiding place, nobody can slack off, or explore anything interesting or do anything which is not explicitly discussed, sized, prioritized and authorized Everything a dev is doing must be on the JIRA backlog and the manager can get a nice dashboard to see how many user stories everyone has completed each week. It is the panopticon.
Similar to EVMS. So since the software is just a part a product, the product will have EVMS and then the software will have even another layer of reporting.
"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!
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.
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!
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.
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?
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.
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
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.
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.
I came here looking for an explanation of exactly why agile/scrum are broken and found a video of two guys laughing at how bad it was without any explanation of why, like this was some inside joke that I was not in on. Anywhere in this video, does Allen explain why he thinks agile and scrum are broken?
In these monthly "Engineering Room" videos, I talk to interesting and influential people about their views and experiences. In my regular weekly content, I have several videos about Agile and Scrum which may answer your question, from my point of view: ua-cam.com/video/fjeVFxL9MQA/v-deo.html ua-cam.com/video/U-u8xquguWE/v-deo.html
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.
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.
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'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.
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.
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.
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.
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.
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.
Was recommended this video after watching another on Scrum, hoping to maybe get some counter arguments as to why its broken but heard nothing here but the same old pandering that its broken and dying. What are some alternatives? Why is it broken and what recommendations do you have on fixing it?
The largest problem with most agile methods, is that there isn't even a shred of empirical evidence that the claims made about those methods, are ACTUALLY true.
We're about to implement scrum in our team. Before that we used kanban but didn't like how some tasks never get done because something always has a higher priority. We're doing everything in jira and confluence. We're not even software devs but eng-ops. And i HATE all this talk about "being agile" and "optimizing" everything. And those ceremonies. Yeah i'm sure they're great for people who love showing off their work, but please just let me work in peace and read my tasks if you need to know what i'm doing. That's literally what they're here for
The only thing I agree with you on is that the problem occurs when people stop treating SCRUM as framework and treat it as a doctrine. The same is true of any framework. e.g. XP-pair programming sometimes useful sometimes not. Colocation sometimes good sometimes unnecessary. UML - Use cases are a waste of time and the other diagram types are not semantically equivalent. TOGAF - Dont get me started. For my current client we have a kanban board and weekly planning meetings . No standups because we are not developing full-time. Tasks are not written in story format. There are some practices I would like to introduce because I think they would be helpful and that is the key - use the practices that are helpful.
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.
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.
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.
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.
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 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.
Scrum should be outlawed for safety critical products. It puts unnecessary time pressure on developers and testers, which could make them overlook latent bugs in the code. I have worked as an engineer since 1982 and as a software engineer since 1987, mostly in safety critical real time embedded software in the commercial avionics and medical device industries. Agile scrum is incompatible with embedded safety critical software. In making big architectural changes, a task can take much longer than a silly two-week sprint with nothing to show for it until the task is completed to some degree. The same can be said when working on low level software that interfaces the hardware, such as when you have to spend time in the lab using an oscilloscope to verify the data coming across a shift register. Sure, it doesn’t interfere with your work when doing something trivial like changing the layout of a few buttons on a GUI, but even then, with all those pointless meetings, it is a colossal waste of time. In my first DO-178 (safety critical standard) job, by not being rushed and micromanaged, I was able to discover latent bugs in an avionics product that was written in assembly language that other engineers had overlooked. It was usually a comparison statement using a variable using indirect addressing versus direct addressing. That is similar to misusing a variable that is defined as a pointer to an int as an int or vice versa. The data that was in that location just happened to be a value that coincidentally would work, but it was subject to change to something that might not work in the future. Getting things done FAST should NEVER be the primary goal in safety critical software. And I am not anti-process. Safety critical standards like DO-178B in aerospace and IEC 62304 in the medical device industry define the SDLC, but the things they deinfe make sense, like requiring 100 percent path coverage in testing flight code, because you don’t want to be flying near an airport and find out the altitude reading froze up because the code is stuck in a while loop. All the things I see being done name of agile scrum make no sense. Unfortunately, even some aerospace companies are starting to do this agile scrum nonsense. It has the look of - All the cool kids do agile scrum, so the cool kid wannabes emulate the cool kids to try to be cool themselves. Fortunately, after starting a new contract job that will likely be my last job before I retire, they aren’t doing agile scrum. I actually sent a resume to them because I figured they weren’t doing that nonsense and didn’t send a resume to some other companies advertising for SW engineers because they said they were agile. Things that make me glad to be nearing retirement: Agile scrum and open office seating arrangements. Working remote at least mitigates open office seating arrangements. Fortunately, working in what will likely be my last contract job before I retire, working on a safety critical product in commercial avionics, they are not doing agile scrum.
@@erastvandoren I know it is a colossal waste of time. I also find those daily meetings quite infantile. What you suggest is pointless when “as much time as needed” is measured in months and sometimes years, which is often the case on embedded systems. Do a Google search for inertial reference systems, Kalman filters, cosine matrix, to see how math intensive these products are. I’m old enough to have enough in retirement savings to have no fear of getting fired from a job, but younger people feel pressured by these daily meetings, and they may rush through their work to show they are making daily progress. You must not be someone who works on safety critical software. The most important thing is to be allowed the freedom from distractions in order to pay meticulous attention to detail.
@@erastvandoren I’ve noticed that a lot of engineers hate scrum and the people who defend it are those who profit from it, like scrum masters and scrum coaches. FWIW, in the fifties and sixties, tobacco companies did their own “studies” on the effects of smoking and came to the conclusion that it didn’t cause any health problems, because of, you know, the profit motive.
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.
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.
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.
I talk about about that in this video: "How to avoid big upfront design" ua-cam.com/video/8GONv6jJsG0/v-deo.html and this one: "What Software Architecture Should Look Like" ua-cam.com/video/ElMnHDSFaCw/v-deo.html
I quit so many jobs because of the sh**ty agile concept. we only do the opposite of agile with all the jira process and the daily’s that turned to endless meetings and so on, and we are forced to call it agile, I used to make so many revolution by saying that this is clearly not Agile but this caused me only problems 😂 I’m currently wondering to change vocation because I can’t work in IT departments with this mindset anymore
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.
The engineering went out of software engineering more than a decade ago. Even from the xp days it was an ideology. The result is we now have heaps of crap, insecure software because teams choose the features, tools and methods they want to do at the expense of stuff that needs to be done. Just look at the 2022 cisq report on sw quality and security in the us and tell me how ideology driven development has served anyone other than the 5minute experts (probably from marketing) who attend a weekend scrum master course and then carry on about how they know sw development. /rant
I would like to agree and disagree at the same time. There is, in my opinion, a fundamental imbalance between programmers, management and customers. Various approaches over the decades have tried to redress this imbalance. To be honest, I don't see any real progress in it. Don't get me wrong, I love Agile and enjoy working with Scrum, but the above protagonists are still talking past each other. No "Eureka!" moment to date. So, what do we do about it?
Scientific Management Theory have such a strong impact on our culture that its virtually impossible to make principles of agility ingrained in our professional life. Humans love hierarchical structures, thats our natural preference. We are more than capable of shedding both scientific Management legacy or our natural "defaults", yet it takes so much effort and it practically hurts. It's as it was said in the video: you need to have a skilled and well motivated people for agility to work properly. Because of that its stastistically impossible to build a large and fully agile organization. Being "great" is hard and we have some unrealistic expectations that average people will be able to achieve that if they will follow some well written script and make the "recomended movements" part of their daily routine. Greatness is not for masses but selected few who made a lot of cognitive effort and energy expenditure to make things as great as we can at the moment. On average software engineer is paid a lot more and a lot less miserable when working with corporations. Thats a visible improvement. There is this extremely untrue expectations that somehow we are all the same and doing things in the same way will guarantee the same outcomes. Thats a big lie.
I understand some of the points they made but I wish they gave more proper arguments explaining more in detail what things are wrong about it. It was too vague and speaking out of emotion, imo. But I think I have felt the pains they were mentioning, like some ceremonies, You need to identify which things provide value to you and ditch whatever acts as a filler.
I view Scrum as a framework that provides a structure to the Agile philosophy, which is more of a mindset or a set of guiding principles (like the Agile Manifesto). I've found that Agile and Scrum worked exceptionally well on projects where I was the sole developer, as I was able to carry out all Scrum ceremonies independently. In fact, I've become so accustomed to Agile practices that I can't imagine working without them. Additionally, it worked well on a project with another developer who was more junior. He respected my experience, followed the Agile/Scrum processes I implemented, and together, we were able to deliver a quality product. However, I've had negative experiences on teams where some members don't fully understand or embrace Agile development. I believe a senior developer who has been deeply involved in multiple phases of a project (2-3 projects, ideally) and is trained in Agile should serve as the Scrum Master. Unfortunately, I've often seen people from non-technical backgrounds, such as sales or management, with no software development experience, stepping into this role, which I think is less effective.
If you recoil at accountability then why should anyone pay you for the project? If i am paying you to develop and deploy X software by X date becuase I have customer commitments relying on that production date, how do I convince the people with the money that they can trust you? How do you prove that progress is on track?
You should see software development as “RESEARCH and development”. It’s like asking scientists how long it’s going to take to find a cure. They know the end goal, they know what tasks to try but ultimately (unless you’ve done the exact same thing or near enough to it) there is a huge…HUGE part of research and figuring stuff out. How long is a piece of string? This is why it’s near impossible to accurately estimate deliver times and costs with large projects - RESEARCH and creative thinking forms a major part of it. You can’t put a solid number or commitment to that.
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.
A lot of the pushback I've seen with agile & scrum were a result of either poorly implemented practices or "over process" which gets in the way of progress. At its core, agile allows our teams to quickly pivot commitments while being able to progress forward. Sometimes all a team needs is, agile/scrum light. Overall, do which ever process works best for your organization.
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.
@@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.
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
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?
You can find the definition of "agile" in a dictionary (earliest known use between 1150 and 1500 AD). "Agile" is related to flexibility. "Scrum" (coined in the mid/late 1980's) is something that nowadays has nothing to do with "agile" or flexibility.
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.
You can find time tons of scrum talks here in UA-cam, and they're hilarious. I think they miss the point which is "scrum master is just a hat" that anyone can wear, and they push so hard in order to justify their position. The goal is to deliver by paying attention to quality, the rest is just burocracy.
The money making side of agile and certs is annoying but it’s a priceless tool for disorganized teams of people who just aren’t on the same page. Agile and scrum isn’t bible. I think their gripe is with people who do treat it as bible. But for people who understand it to be a tool versus a strict regime, it’s create seamless workflows. It’s not meant to be a perfect process, that why portion of it are vague because it’s not one size fits all. This video is the definition of people who take things way too seriously and are ready to condemn anything they believe is beneath them. Like “how dare we try to give people structure?!” The truth is some teams do need structure to develop habits and a process that eventually leads them to become self managed. Then you adapt and take what works and leave what doesn’t. That’s literally the point. I can agreed that teams sometimes do take agile too seriously in the sense that they practice it rigidly and religiously which I think is what causes so much distaste for scrum. Unfortunately sometimes the wrong people are put in positions to run teams and use scrum as an opportunity to micro-manage. Which is the opposite of what agile is suppose to achieve. So their arguments are really against what people make scrum not what is intent actually is and what it produces when been successfully.
there is Jira... which I have almost no problems with... and there is JIRA FROM HELL where hard wired spaghetti workflow changes constantly. Every time I work a ticket in jira I must ask everyone what the current process is. I hate this agile crap so much. It has taken all the joy out of development.
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.
Wow! Allen Holub - I took a class from you at U. C. Berkeley years ago! Great class, by the way. I also hate scrum and fixed it in my life by retiring 🙂
There's currently about an 83% burnout rate in developers and I think much of that is done by Agile turning programmers into short order cooks. It's completely exhausting to keep having to rewrite a program because the customer is always right and their feet are not held to the fire. The problem is that your software engineers probably are some of the hardest working people - they have a mountain of mandated knowledge that never ends and the expectations are getting ridiculous with all the churn in various industries through various frameworks and middleware. Engineering takes time and very firm up front specification.
To the point, Agile started as lightweight and "agile". Now it's a monster, the way it is implemented. Professional software developper since 1981 here. And trainer since 1982. I was teen.
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
before agile:
20 developers that get things done
after agile:
15 developers, 5 team leads, 5 box tickers, 3 coaches, nothing gets done, the 15 developers spend 20 hours of their week explaining to the leaders, box tickers, coaches, what is going on, so they can submit their reports.
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.
"the way it's infantalized what software engineering" you are so right on that one! Every day I feel like the only engineer surrounded by children who just pretend to software-engineers. Why? Because nothing is specified. Nothing is planned. Nothing is engineered. The solution is to start stupid half-baked ideas and then add a million meetings with way too many people, where the actual issue is not tackled nor solved. Agile development allows amateurs to write code without ever learning software engineering. Instead they just write code.
Before the advent of Agile and the Scrum processes, software engineering and design were more akin to an art and hand craftsmanship. After Agile and Scrum started to become a cultish mantra, software engineering turned into a Ford factory and assembly line with little to no creativity involved, it was all about delivery of your widgets as quickly and efficiently as possible, it doesn't need to be efficient and beautiful only that it's below budget, on time and it does the job.
"layers of process" Clearly, you have not actually been following Scrum if that's how it looks for you. There are a handful of meetings and other elements that describe what Scrum is, but the expectation is that these take the place of existing process and so forth, not "in addition to". Clearly, the people leading your transition to Scrum just had no idea what they were doing and neither did any of you who were adopting it or you would have pointed this out to them.
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.
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?
I have had some fortunate experiences because of certifications. Not needing to get a degree that would have me in debt for years and instead getting certifications that tie to that job for example.
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?
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 ...
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.
It's funny because it's true
Is he certified in PSM or CSM? Or just some traditional manager who took over the Scrum Master role when his company decided to go agile???😂
We had one such scrum master who was not even certified 😂
Hybrid?
I like it when management wants all the advantages and no downside lol
All the scrum masters I've worked with were totally and utterly useless.
@@revietech5052 it's a job qualification
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.
@@MeursaultYTthe 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.
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.
@@recmtnbiker4368 you dont get to take linear algebra and stats you HAVE to in a CS degree
@@c0r5e That wasn’t the case in the late seventies and early eighties when I was in college. Even today, it varies from one university to another if you look at the course requirements. I majored in electrical engineering. I have worked in safety critical industries like commercial avionics and medical devices over the years. These are products that have a very high consequence of failure. To inflict scrum on the employees is very dangerous. The time pressure to finish ”stories” by the end of those infantile sprints greatly increases the likelihood of bugs being released in the code.
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.
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 !
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 have personally lead teams from being under insanely hard PMI/PMP/Prince project management thumbs into flourishing engineering organisations delivering value and caring about the profession. What we did to do that was using parts of scrum and parts of XP tailoring it to the organisation. Picking things for our context and chucking things that didn't.
At a past job, we did Show and Tell's during sprints to show what we were working on and get any feedback. I've seen people have very heated discussions over datepickers, and a product owner basically walked out of Show and Tell after we told her the small feature we working on had to be done a certain way given the tech stack we were using at the time. Also have seen a lot of bike shedding too.
Wow you people are the definition of existing to create your own bullshit job.
The fancyness and also non-concrete words you use reek of this.
Hope you get fired. Because people like you are creating nothing. You are just creating your own work space.
Sounds more like culture problem rather than a framework problem.
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.
@@fulconandroadcone9488 *cache
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.
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.
What is you alternative?
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.
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?
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.
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.
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'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!
"It's called a stand up, because everyone hates it and it is not funny".
Scrum and all those BS like story points, retro, daily draining meetings,etc make our job feel so superficial, unsecure and not enjoyable.
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.
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.
We are agile, take 15 minutes per day in our scrum (small teams of 3-5 devs) and maybe 1 hour or less every week or 2 for replenishing and such.
Agile is a tool for reducing highly skilled and experienced developers into interchangeable cogs while conferring their abilities to a sustainable level into a team of low-skill and inexperienced developers which cost less and don't make managers uneasy by being outpaced intellectually.
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.
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 ua-cam.com/video/nauFRW6gYjc/v-deo.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.
Agile strikes me as being glorified prototyping, except that it gets in the way.
Magic comment
I think reading, pondering and understanding the philosophy of Agile is a good thing. Being dogmatic about something is rarely practical though.
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!
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.
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..
That's agile "just in time" planning 😉
A developer explained it to me very well. Scrum gives management continuous visibility of every single thing an employee does and how long it takes. There is no hiding place, nobody can slack off, or explore anything interesting or do anything which is not explicitly discussed, sized, prioritized and authorized Everything a dev is doing must be on the JIRA backlog and the manager can get a nice dashboard to see how many user stories everyone has completed each week. It is the panopticon.
That isn't scrum or agile. That's capitalism.
Similar to EVMS. So since the software is just a part a product, the product will have EVMS and then the software will have even another layer of reporting.
"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!
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.
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.
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.
Exactly. It's just a magic pill for a dummy managements that gives illusion of control
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.
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.
"XP without Scrum works fine, Scrum without XP doesn't work at all".
Man, I'm so gonna steal this.
There are actually two SCRUM-organizations. One that has a high focus on monetizing SCRUM, and one that really don’t try to.
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?
There is no way for everybody to apply it. It's about 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.
I came here looking for an explanation of exactly why agile/scrum are broken and found a video of two guys laughing at how bad it was without any explanation of why, like this was some inside joke that I was not in on. Anywhere in this video, does Allen explain why he thinks agile and scrum are broken?
In these monthly "Engineering Room" videos, I talk to interesting and influential people about their views and experiences. In my regular weekly content, I have several videos about Agile and Scrum which may answer your question, from my point of view: ua-cam.com/video/fjeVFxL9MQA/v-deo.html
ua-cam.com/video/U-u8xquguWE/v-deo.html
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.
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.
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'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.
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.
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.
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.
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.
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.
Was recommended this video after watching another on Scrum, hoping to maybe get some counter arguments as to why its broken but heard nothing here but the same old pandering that its broken and dying. What are some alternatives? Why is it broken and what recommendations do you have on fixing it?
The largest problem with most agile methods, is that there isn't even a shred of empirical evidence that the claims made about those methods, are ACTUALLY true.
We're about to implement scrum in our team. Before that we used kanban but didn't like how some tasks never get done because something always has a higher priority. We're doing everything in jira and confluence. We're not even software devs but eng-ops. And i HATE all this talk about "being agile" and "optimizing" everything. And those ceremonies. Yeah i'm sure they're great for people who love showing off their work, but please just let me work in peace and read my tasks if you need to know what i'm doing. That's literally what they're here for
The only thing I agree with you on is that the problem occurs when people stop treating SCRUM as framework and treat it as a doctrine. The same is true of any framework. e.g. XP-pair programming sometimes useful sometimes not. Colocation sometimes good sometimes unnecessary. UML - Use cases are a waste of time and the other diagram types are not semantically equivalent. TOGAF - Dont get me started. For my current client we have a kanban board and weekly planning meetings . No standups because we are not developing full-time. Tasks are not written in story format. There are some practices I would like to introduce because I think they would be helpful and that is the key - use the practices that are helpful.
is allen doing live XP videos ? curious to see him operate
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'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.
Wonderful genius comment at 03:45 "Extreme Programing without Scrum works fine. Scrum without Extreme Programing does not work at all" :)
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.
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.
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.
WHO and WHO's original book on Scrum? I have a hard time hearing those names.
Huh okay I guess it is this one: "Agile Software Development with Scrum" by Ken Schwaber (Author), Mike Beedle (Author)
Work together in small batches .. delivering iteratively
Scrum meant to be used with xp
Rest is bunkum
Scrum should be outlawed for safety critical products. It puts unnecessary time pressure on developers and testers, which could make them overlook latent bugs in the code.
I have worked as an engineer since 1982 and as a software engineer since 1987, mostly in safety critical real time embedded software in the commercial avionics and medical device industries. Agile scrum is incompatible with embedded safety critical software. In making big architectural changes, a task can take much longer than a silly two-week sprint with nothing to show for it until the task is completed to some degree. The same can be said when working on low level software that interfaces the hardware, such as when you have to spend time in the lab using an oscilloscope to verify the data coming across a shift register. Sure, it doesn’t interfere with your work when doing something trivial like changing the layout of a few buttons on a GUI, but even then, with all those pointless meetings, it is a colossal waste of time. In my first DO-178 (safety critical standard) job, by not being rushed and micromanaged, I was able to discover latent bugs in an avionics product that was written in assembly language that other engineers had overlooked. It was usually a comparison statement using a variable using indirect addressing versus direct addressing. That is similar to misusing a variable that is defined as a pointer to an int as an int or vice versa. The data that was in that location just happened to be a value that coincidentally would work, but it was subject to change to something that might not work in the future. Getting things done FAST should NEVER be the primary goal in safety critical software. And I am not anti-process. Safety critical standards like DO-178B in aerospace and IEC 62304 in the medical device industry define the SDLC, but the things they deinfe make sense, like requiring 100 percent path coverage in testing flight code, because you don’t want to be flying near an airport and find out the altitude reading froze up because the code is stuck in a while loop. All the things I see being done name of agile scrum make no sense.
Unfortunately, even some aerospace companies are starting to do this agile scrum nonsense. It has the look of - All the cool kids do agile scrum, so the cool kid wannabes emulate the cool kids to try to be cool themselves. Fortunately, after starting a new contract job that will likely be my last job before I retire, they aren’t doing agile scrum. I actually sent a resume to them because I figured they weren’t doing that nonsense and didn’t send a resume to some other companies advertising for SW engineers because they said they were agile.
Things that make me glad to be nearing retirement: Agile scrum and open office seating arrangements. Working remote at least mitigates open office seating arrangements. Fortunately, working in what will likely be my last contract job before I retire, working on a safety critical product in commercial avionics, they are not doing agile scrum.
You obviously haven't the foggiest what Scrum is. You take as much time as you need, and push the feature into the next sprint if needed.
@@erastvandoren I know it is a colossal waste of time. I also find those daily meetings quite infantile. What you suggest is pointless when “as much time as needed” is measured in months and sometimes years, which is often the case on embedded systems. Do a Google search for inertial reference systems, Kalman filters, cosine matrix, to see how math intensive these products are. I’m old enough to have enough in retirement savings to have no fear of getting fired from a job, but younger people feel pressured by these daily meetings, and they may rush through their work to show they are making daily progress. You must not be someone who works on safety critical software. The most important thing is to be allowed the freedom from distractions in order to pay meticulous attention to detail.
@@erastvandoren I’ve noticed that a lot of engineers hate scrum and the people who defend it are those who profit from it, like scrum masters and scrum coaches. FWIW, in the fifties and sixties, tobacco companies did their own “studies” on the effects of smoking and came to the conclusion that it didn’t cause any health problems, because of, you know, the profit motive.
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.
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.
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.
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" ua-cam.com/video/8GONv6jJsG0/v-deo.html and this one: "What Software Architecture Should Look Like" ua-cam.com/video/ElMnHDSFaCw/v-deo.html
I would love to hear you go deep on SAFe. My company just adopted it and it is horrid.
I quit so many jobs because of the sh**ty agile concept. we only do the opposite of agile with all the jira process and the daily’s that turned to endless meetings and so on, and we are forced to call it agile, I used to make so many revolution by saying that this is clearly not Agile but this caused me only problems 😂 I’m currently wondering to change vocation because I can’t work in IT departments with this mindset anymore
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.
The engineering went out of software engineering more than a decade ago. Even from the xp days it was an ideology. The result is we now have heaps of crap, insecure software because teams choose the features, tools and methods they want to do at the expense of stuff that needs to be done. Just look at the 2022 cisq report on sw quality and security in the us and tell me how ideology driven development has served anyone other than the 5minute experts (probably from marketing) who attend a weekend scrum master course and then carry on about how they know sw development. /rant
I would like to agree and disagree at the same time. There is, in my opinion, a fundamental imbalance between programmers, management and customers. Various approaches over the decades have tried to redress this imbalance. To be honest, I don't see any real progress in it. Don't get me wrong, I love Agile and enjoy working with Scrum, but the above protagonists are still talking past each other. No "Eureka!" moment to date. So, what do we do about it?
Why do you enjoy working with scrum?
Scientific Management Theory have such a strong impact on our culture that its virtually impossible to make principles of agility ingrained in our professional life. Humans love hierarchical structures, thats our natural preference. We are more than capable of shedding both scientific Management legacy or our natural "defaults", yet it takes so much effort and it practically hurts. It's as it was said in the video: you need to have a skilled and well motivated people for agility to work properly. Because of that its stastistically impossible to build a large and fully agile organization. Being "great" is hard and we have some unrealistic expectations that average people will be able to achieve that if they will follow some well written script and make the "recomended movements" part of their daily routine. Greatness is not for masses but selected few who made a lot of cognitive effort and energy expenditure to make things as great as we can at the moment. On average software engineer is paid a lot more and a lot less miserable when working with corporations. Thats a visible improvement. There is this extremely untrue expectations that somehow we are all the same and doing things in the same way will guarantee the same outcomes. Thats a big lie.
I understand some of the points they made but I wish they gave more proper arguments explaining more in detail what things are wrong about it. It was too vague and speaking out of emotion, imo.
But I think I have felt the pains they were mentioning, like some ceremonies, You need to identify which things provide value to you and ditch whatever acts as a filler.
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
What do you guys say about kanban with xp..
I view Scrum as a framework that provides a structure to the Agile philosophy, which is more of a mindset or a set of guiding principles (like the Agile Manifesto). I've found that Agile and Scrum worked exceptionally well on projects where I was the sole developer, as I was able to carry out all Scrum ceremonies independently. In fact, I've become so accustomed to Agile practices that I can't imagine working without them.
Additionally, it worked well on a project with another developer who was more junior. He respected my experience, followed the Agile/Scrum processes I implemented, and together, we were able to deliver a quality product. However, I've had negative experiences on teams where some members don't fully understand or embrace Agile development. I believe a senior developer who has been deeply involved in multiple phases of a project (2-3 projects, ideally) and is trained in Agile should serve as the Scrum Master. Unfortunately, I've often seen people from non-technical backgrounds, such as sales or management, with no software development experience, stepping into this role, which I think is less effective.
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.
If you recoil at accountability then why should anyone pay you for the project? If i am paying you to develop and deploy X software by X date becuase I have customer commitments relying on that production date, how do I convince the people with the money that they can trust you? How do you prove that progress is on track?
You should see software development as “RESEARCH and development”. It’s like asking scientists how long it’s going to take to find a cure. They know the end goal, they know what tasks to try but ultimately (unless you’ve done the exact same thing or near enough to it) there is a huge…HUGE part of research and figuring stuff out. How long is a piece of string? This is why it’s near impossible to accurately estimate deliver times and costs with large projects - RESEARCH and creative thinking forms a major part of it. You can’t put a solid number or commitment to that.
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.
A lot of the pushback I've seen with agile & scrum were a result of either poorly implemented practices or "over process" which gets in the way of progress. At its core, agile allows our teams to quickly pivot commitments while being able to progress forward. Sometimes all a team needs is, agile/scrum light.
Overall, do which ever process works best for your organization.
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
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
only good part is scrum meetings ... but 2 weeks delivery to QA impossible.
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?
... I've been programming for almost 50 years. What are "scrum" & "agile"?
You can find the definition of "agile" in a dictionary (earliest known use between 1150 and 1500 AD). "Agile" is related to flexibility. "Scrum" (coined in the mid/late 1980's) is something that nowadays has nothing to do with "agile" or flexibility.
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.
You can find time tons of scrum talks here in UA-cam, and they're hilarious. I think they miss the point which is "scrum master is just a hat" that anyone can wear, and they push so hard in order to justify their position. The goal is to deliver by paying attention to quality, the rest is just burocracy.
On the contrary, quality suffers once teams start doing Agile/Scrum.
The money making side of agile and certs is annoying but it’s a priceless tool for disorganized teams of people who just aren’t on the same page. Agile and scrum isn’t bible. I think their gripe is with people who do treat it as bible. But for people who understand it to be a tool versus a strict regime, it’s create seamless workflows. It’s not meant to be a perfect process, that why portion of it are vague because it’s not one size fits all. This video is the definition of people who take things way too seriously and are ready to condemn anything they believe is beneath them. Like “how dare we try to give people structure?!” The truth is some teams do need structure to develop habits and a process that eventually leads them to become self managed. Then you adapt and take what works and leave what doesn’t. That’s literally the point. I can agreed that teams sometimes do take agile too seriously in the sense that they practice it rigidly and religiously which I think is what causes so much distaste for scrum. Unfortunately sometimes the wrong people are put in positions to run teams and use scrum as an opportunity to micro-manage. Which is the opposite of what agile is suppose to achieve. So their arguments are really against what people make scrum not what is intent actually is and what it produces when been successfully.
there is Jira... which I have almost no problems with... and there is JIRA FROM HELL where hard wired spaghetti workflow changes constantly. Every time I work a ticket in jira I must ask everyone what the current process is. I hate this agile crap so much. It has taken all the joy out of development.
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.
Wow! Allen Holub - I took a class from you at U. C. Berkeley years ago! Great class, by the way. I also hate scrum and fixed it in my life by retiring 🙂
There's currently about an 83% burnout rate in developers and I think much of that is done by Agile turning programmers into short order cooks. It's completely exhausting to keep having to rewrite a program because the customer is always right and their feet are not held to the fire. The problem is that your software engineers probably are some of the hardest working people - they have a mountain of mandated knowledge that never ends and the expectations are getting ridiculous with all the churn in various industries through various frameworks and middleware. Engineering takes time and very firm up front specification.
If being an agile trainer is someones only job in software, I figure they're like an eunuch. They know how it works.
To the point, Agile started as lightweight and "agile". Now it's a monster, the way it is implemented.
Professional software developper since 1981 here. And trainer since 1982. I was teen.