I have used scrum and I dont see it really helps people build the right product. There is so much jargon and cruft around it; planning poker, story points, scrum master etc..<p>Software quality of what is built in the scrum way seems poor as it does local optimization and doesnt focus on long term.. seems like some thing that would work for consultancies the best?<p>Simple Kanban seems more effective, do you feel the same way? Am I doing scrum wrong? Is scrum built to ensure that program managers / product managers have something to do?
I've seen scrum done to the point of _religion_ at one company, and as loose as a few times a week async over slack at others.<p>What I've seen is that the more hardcore you are about scrum/agile, the more it works against you. It's something of an anti-pattern.<p>That isn't to say the entire notion of regular short meetings should be thrown out entirely, though. What seems the right balance, depending on your situation of course, is to have a quick team meeting over zoom/other two or three times per week if possible, async otherwise over slack or similar. Leave the rest of the ceremony out entirely, and use something like kanban/trello/etc for tracking specifics.<p>The meeting isn't at all about the kanban board/cards, it's about the team spontaneously discussing approaches/issues and helping each other out. One of those "the whole is more than the sum of its parts" things.
It's like a religion. You have a simple gospel, but religious nuts turn it into a faith-based dogma. If you don't get results, it's because you're not following the rituals well enough. You get the idea.<p>In practice, I think it's one of those things where you should follow the rules for a while, until you can tell where it makes sense to break them. If you half-ass the implementation, you end up doing the same things as before. If you overdo it, the process stops serving you, and you start serving the process.<p>I do appreciate daily standups and retrospectives, but only if they're well-run. Otherwise people attend it like the Simpsons attend mass.<p>Personally, I prefer Kanban for its lack of arbitrary divisions and estimations. It doesn't encourage basing solid deadlines on guesstimations, and allows for on-the-fly priority changes. It requires a lot less discipline, as your only job is to keep the backlog sorted.
Scrum is a reasonable baseline starting point for an agile team to iterate on for process. Like any process, it is bad as an inflexible, canned process instituted as a rote ritual.<p>> There is so much jargon and cruft around it; planning poker, story points, scrum master etc<p>Neither planning poker nor story points (nor even <i>stories</i>, which are a prerequeisite for planning points to be “story points”) are parts of Scrum. They are independent practices each with their own history, rationale, and associated bodies of knowledge that are frequently used within various development methodologies including Scrum.<p>> Software quality of what is built in the scrum way seems poor as it does local optimization and doesnt focus on long term.<p>“local optimization and doesn't focus on the long term” doesn't seem to be an inherent feature of Scrum particularly contrasted with “simple kanban”, which you suggest is the superior alternative.<p>> Simple Kanban seems more effective, do you feel the same way?<p>I think flow-based rather than increment-based methods are generally superior, and I am increasingly convinced that the Scrum Master and Product Owner roles defined in Scrum are counterproductive, demotivating, contrary to the Agile principle of collective ownership, and thus generally a bad idea, abd I think that while a daily checkup/plan update meeting is useful, I think most of the common ritualized use of the daily scrum (“did/doing/impediments”) is better served by a shared visual indicator, so, yeah, I tend to favor something more kanban-ish than Scrum (whether by that you mean Scrum-by-the-book or Scrum-as-commonly practiced).<p>> Is scrum built to ensure that program managers / product managers have something to do?<p>No, nor does Scrum even define roles for them. If they exist in an organization, they are outside the scope of Scrum.
All of these fancy-dancy layers to software development just seem ridiculous to me. Coordinate with the rest of your team, coordinate with your customer. However that takes form is up to the team. You want quality? Give the devs some breathing room.<p>However as one commenter said, it's not about quality. Big companies have to feel that sweet, sweet cash, as soon as possible, at the cost of the devs.
Basically anything with a capital letter is a tool designed to sell training materials and consulting services. It doesn’t matter whether or not it actually works, it just has to sell well.
Scrum is not a scam.<p>It was popularized as a way to micromanage developers and drive them to produce more.<p>I think we can argue about whether that 'more' has been quality or not, the right output or not, whether developers and other workers deserve dignity or not, etc., but I think it continues to deliver on its core goal -- tighter management control of and domination of workers, with all the benefits for management and ownership and investors that brings.
I've found most large companies introduce things like scrum without really understanding why they're doing them.<p>For example, a company I worked for a few months back paid a management consultant tens of thousands of pounds to help them improve the productivity of the engineering team. As a result various new ways of working were introduced, one of which was a very strict implementation of scrum.<p>To oversee these new ways of working several scrum masters were hired at the cost of several hundreds of thousands of pounds in salaries.<p>At no point during this process was the engineering team themselves consulted so of course the whole thing was a nightmare and significantly reduced our productivity as we were now spending half of our time attending unneeded scrum meetings and being chased by scrum masters. Actual problems we faced such as needing to support legacy system and the constant bug fixing of crappy code we were forced to ship were never discussed.<p>In my experience scrum works well as a rough guide for how to manage a modern software team, but it rarely works when it's done bureaucratically and introduced by people higher up in the organisation who have little understanding of the actual problems faced by the engineering team. Rarely have I found scrum to be the core problem. It's usually that the people who introduce scrum care more about introducing scrum than something that works.<p>My experience of scrum in small companies, especially small companies with a software focus is far more positive. When companies are able to be flexible and avoid dogmatically implementing scrum it can work well, but I've certainly shared your frustration several times in my career.
Not sure but all the companies I've joined tried to use these kinds of tools and none of them worked. Projects still gets delayed with mounting backlogs and increased pressure from business to ship. Maybe I'm just unlucky.
I think it’s somewhat of a solution in search of a problem. Every company I’ve worked for, regardless of their Scrum religion level, seem to end up in the same place - the PM nagging for updates (even if we just had our scrum an hour ago) and constantly asking if there’s anything they can do to help or if there’s anyone else on the team that can help.<p>No, I would have told you if there are blockers. Just because there aren’t don’t mean this is “easy”, and while I realize you need to explain to the stakeholder why it’s taking longer, neither of you are going to understand anyway, so it’s a waste of everyone’s time.
I don't trust scrum because it has a whole industry around it. People who's main source of income is to go train companies to do scrum so the trainers can do more training. Conferences, books, authors, personalities, the works.<p>Why would I trust something like that instead of something organic?
The main problem I see with scrum (and agile generally) is that it has wandered away from where it was originally conceived into places it just doesn’t work.<p>If you are building a product with a very close partnership to the end user with a small, experienced team who share a both a common view of the world and a common definition of success then scrum can work very well. Although, ANY methodology can work well in that environment.<p>The further away from that ideal the less successful scrum will be. Do you have a team of mixed ability? Scrum will have trouble because you are supposed to view everyone’s opinion as equally valid (but that new grad just doesn’t know as much as the grizzled veteran and scrum doesn’t accommodate mentorship).<p>Are you one or two steps removed from the end user? Then you are going to have problems because scrum demands a tight feedback loop with your user so if the “product owner” needs to launch a three month “customer survey” to answer every question you have many sprints without any meaningful feedback.<p>The fundamental truth is you can dictate what is built, or you can dictate when you want it. You can’t do both (because any meaningful software is by definition novel).<p>Scrum tries to say “deliver every sprint” without being opinionated about what get’s delivered. That can work with a tight feedback loop with the end user, but invariably product managers, sales, and business strategists get involved and they all want to be able to promise Things by Dates (“we won’t hold you to the dates, honest”) and that’s where it breaks down.<p>All of this is before you even get into the cargo cult of points poker (the value is in identifying mismatches in shared reality, not in sizing the stories) or stand ups (which only work if you are all trying to deliver One Thing).<p>Finally factor in that early adopters or scrum were actively looking for alternative ways to develop software beyond the “conventional wisdom” of waterfall whereas now everyone views agile/scrum as conventional wisdom and it’s unsurprising that most people have a decidedly subpar experience.
As a dev who has spent a few years in a product role, Scrum has its place. Mostly to get people used to being in a formal process instead of cowboy coding. But almost all teams mature away from Scrum to Kanban or something else. Scrum is a starting point, not a goal.<p>As a product owner, I find Scrum to be limiting. It does not empower me, it restricts me. We can't just tell a talented dev to go figure something out, we need to break it up into the right sized pieces and fit it onto a board. That does not give me "something to do", it actually burdens me with micromanagement. I just want to lay out what needs done, then let the engineers do it.<p>In that, you are correct - Scrum does not fulfill the main goal of product management, of building the right product. It does make the dev process more predictable. But I've never known a good product person who care more about the predictability of the dev team than they do about the quality of the product. Standard cliché here - be careful what you measure, as that it what you will improve.<p>So yes, Kanban is better. I can lay out details, devs can work it, and it takes the time it takes. Maybe Scrum does give better charts and graphs to our leaders. But we get things done. We research what needs researched with freedom to find the right solution... not just a solution that fit into the timebox on a Jira card.
Scrum isn't for everybody. I would say it is for organisations or departments whose business is not developing products, but who develop products to service their business needs. For everyone else, there are many better options to choose from.<p><a href="https://news.ycombinator.com/item?id=23234572" rel="nofollow">https://news.ycombinator.com/item?id=23234572</a>
Not necessarily a fan of scrum. Most of the times it feels like companies strive to do scrum instead of striving do work iteratively, closer to the customer and all of that jazz.<p>Scrum could be a consequence of a goal it shouldn't be the goal.
Scrum as a concept is great - at it's best it cuts through all the noise, gets the proper stake holders to communicate quickly and clearly, aligns everyone at the right levels, and of course allows for quick movements with large teams.<p>However it takes a level of commitment and often breaks down if you're not active in implementing it. The standup is a perfect example - stakeholders shouldn't be part of it and it shouldn't go into strategy or deeper discussions. Everyone knows that, and understands why that's helpful, yet both of those rules are constantly violated. A good scrum master (and you need one because it's impossible to stick to the rules without someone who feels empowered to enforce them) will keep things on topic, and I remember at one company one scrum master kicking out the stake holder from the standup multiple times. At most companies the power difference is too large to do that.<p>The jargon and emphasis on processes makes it too easy to focus on the surface level of scrum rather than the intention behind it. If it were presented as a flexible set of processes that you can customize to your team and project I think it would be far more successful.<p>And when it comes to Kanban, it really depends on the project. If you're working in a factory setting (like making assets from a list) or if you have a stable product and you're adding orthogonal features, Kanban is ideal and scrum doesn't work. If you're working in a space with unclear or developing requirements and some amount of R&D then scrum is a good fit. Scrum can make large teams move quicker but everyone needs to be on board with WHY it works, instead of HOW (which is typically how it's presented).<p>Ultimately though there is no one-size fits all approach. What you want is as dumb a system as is possible given the complexity of the requirements and communication.
Scrum is a tool. Like any tool, if it is used the wrong way, it does not provide a solution. Similarly, no one tool is a silver bullet - it does not fit all circumstances.<p>Nowhere in Scrum does it mention how to create software. This is for the team to decide. If the team is creating bad software, I struggle to see how it can be attributed to a team management framework they use, unless of course it isn't official Scrum but some bastard child of the organisation.<p>You are correct that Kanban is effective. But again, it is a tool that can solve problems in certain contexts. It is more suitable than scrum in some organisations, and vice versa in others.<p>For example, a product that has many high demanding customers who require plans months or even years in advance will find Kanban ineffective for planning. Telecoms companies are good examples of this where their customers take new software and integrate it with their own systems. They require a tight schedule.<p>On the other hand a bank which has a product that is only used within the company and no external stakeholders may serve better with Kanban.<p>There is a lot of 'scrum hating' in the comments here. It's important to remember, companies have every incentive to get effective processes that everyone likes. Bad processes means unhappy developers means more turnover. The ones who focus on bureaucracy suffer for it in the long run. Scrum is used by large companies across the world because it works. Is it perfect? Absolutely not. Is it easy to abuse? Certainly - it's flexibility is perhaps it's biggest benefit and flaw. But when it's done well, it's highly effective. Just ask anyone who works in an effective scrum environment.
I think scrum and all agile frameworks are trying to solve two problems.<p>1) Making good software efficiently<p>2) How can stakeholders get a better sense of how much work a team can do per unit of time<p>I don't think scrum offers anything in the first department that "Hey, don't do waterfall" doesn't. I don't think this advice needs a capital "Agile" or Scrum though. It's pretty obvious nowadays.<p>As for the second gaol, I don't think it offers much either beyond the advice "Hey, speak up if you encounter a blocker and think it's going to take longer." Again, I don't think that deserves a capital Agile / Scrum. Has anyone actually been on a team where you nailed down your velocity and this truly helped anyone?<p>I think a good process is Design <-> Iterate -> Ship, have a real quick standup to identify problems early and often and then report back to stakeholders. Just pull tickets Kanban style. Have a retrospective once a month or so.<p>Doesn't deserve or need to be a whole religion.
Had same experience, people even adjust estimations according to their needs. Daily scrums, scrum planning, backlog grooming may take hours and exhaust people.<p>There are some basics that should be addresses though, progress visibility (issue tracker, milestones, ...), estimation by assigned developer (for responsibility), product management, shared expertise.
I've never seen scrum work, and I don't believe it can. Lots of other people agree with me on this. More and more people every day are discovering the real truth about scrum.<p><a href="https://github.com/rayfrankenstein/AITOW" rel="nofollow">https://github.com/rayfrankenstein/AITOW</a>
Scrum defines very little: working in teration, Product Owner, regular checkups. Other than that, there's a lot of space that gives you freedom and choice how to perform the actual work. Eg. you are free to skip estimations altogether (this isn't a Scrum thing per se; good practise at best).<p>If you ask if scrum is good then I read it "if working in iterations with PO and regular checkups is good" and my answer is yes. But you can achieve the same with kanban or any agile workflow.<p>There is a lot of misconceptions about what is and what isn't scrum. Eg. the fact that all scrums I've seen come automatically with estimations is Cargo Cult to me. From my experience, problems with scrum don't really relate to scrum, but rather these Cargo Cults or "our scrum incarnation", which comes down to misunderastanding it.
These development methodologies all start with a seductive promise of "giving the power back to the developers", then they get hijacked and trojan-horsed by the business people to do the opposite. Hmm ... come to think of it, very similar to a particular political system.
One of my gripes about any agile like process is how the daily standup turn into a status meeting. I feel that is just a waste of time, we don't need to give status daily. It should be a time to identify blockers and identify who is going to help resolve them.
I'm in a project using scrum (scrumbut - but I attribute that to a failing of scrum). There's more talk about story points and planning than there is actual development
There’s a wonderful talk by Dave Thomas, one of the creators of the Agile Manifesto, about the perversion of its original intents by the “Agile Industrial Complex”.<p>Basically, Agile with capital A is ridiculous. But needs to exist in order to sell the industry behind it.<p><a href="https://m.youtube.com/watch?v=a-BOSpxYJ9M" rel="nofollow">https://m.youtube.com/watch?v=a-BOSpxYJ9M</a>
I think the places where it looks like a sham are places that are too focused on ceremony, metrics, and process. If it's just treated as any other tool, them it works well enough.
Scrum is a tool, it all depends how it's used. Kind of bizarre to me that some people think there is no value in planning out work, or thinking about how long it will take, or what will be involved, or prioritizing, or keeping stakeholders informed... If there's no customer, there's no product. At the end of the day, it's a business.
Common, but unspoken, knowledge at this point. The problem is nontechnical
college graduates need jobs too, and only tech companies have the
balance sheets to provide them.