9 ms·

Leave scrum to rugby, I like getting stuff done

59 points by lanecwagner 6y ago

quickthrower2 6y ago
Good points in the article but I have to mention a scrum master isn’t supposed to be telling people what to do, but rather coach on the scrum process.
- BiteCode_dev 6y ago
  And you are not suppose to have the entire rugby team in the scrum, only people who's work intersect. If currently the designer is not working on the same project than the dev, they should not be in the same scrum. Keep it short, to the point. Scrum is not a meeting, it's an interactive tiny bite of field report. Make it anything bigger than that, and you are not doing agile anymore.
  - richliss 6y ago
    The Daily Scrum is frequently misunderstood - it's actually to replan to remaining work required to achieve the sprint goal not a status update or field report. It might well mean that you need to bring in the Product Owner to tell them the news so that together you discuss what is delivered to meet the definition of the sprint goal can be adjusted within acceptable boundaries. If you're wondering why you should accept this definition it's because I recently attended the Scrum Patterns course run by Jim Coplien (the guy who codified the definition of the Daily Scrum and is the co-author of "A Scrum Book" with Jeff Sutherland) and heard it directly from him.
    - BiteCode_dev 6y ago
      Field reports are meant to replan the remaining work. That's the whole purpose of field reports. But I understand what you mean: too many people use it to track activity, not as input for the agile loop.
- chrisseaton 6y ago
  > but I have to mention a scrum master isn’t supposed to be... This is a major problem with Scrum. There's always someone telling you you're doing it wrong. If nobody's able to implement your big idea properly, maybe the problem is with the idea or how you're explaining it, not the people trying to do it.
  - a_imho 6y ago
    There's always someone telling you you're doing it wrong. Of course there are, and they are probably paid handsomely for their insight. How is a process that wants to implement individuals and interactions over processes and tools not a parody?
- taneq 6y ago
  I dunno if you've ever played team sports but roughly 50% of the coach's job is figuring out what you could be doing better, and the other 50% is telling you what to do and how to do it.
  - quickthrower2 6y ago
    My point is that it’s the scrum process they coach on, not the content of tasks themselves.
- thrower123 6y ago
  If a process is so hard to implement correctly that no one is able to do it effectively, then maybe the process should be tailored to the realities of real people.
caust1c 6y ago
I'm no scrum fanatic, but there's real value in doing estimates at the beginning of work, then reviewing how long it took at the end of work (without revising estimates mid workstream). The point of separating these from actual time is not to make people feel better about themselves, it's about accounting for how much unplanned work there is in your organization which is different from org to org and even project to project. By reflecting on how many "story points" some piece of work took, then you get better at estimating how much calendar time something will actually take. FWIW, I've never seen this work in a team setting. I use it in an individual setting where I estimate work for myself, then gauge how much I can get done in the context of a project or org.
- hrktb 6y ago
  I always wondered how it worked in functionnal organizations so perhaps You could tell me. We were told the base principle was to have a stable team and a stable stack, and at some point we had reference tasks to calibrate our point system. But then we had team shuffles about every 6 months ~ 1 year, so team velocity was a fantasy. Then we changed core libraries, introduced services using new stacks, built new API, adapted to other teams’ new paradigms. And all of these changes felt to be for the better to us. Everyone would have left if we kept everything inu place for the sake of point consistency. Basically, how did you deal with change ?
  - loopz 6y ago
    If you read your own post, for you, the answer gives itself. For managers and executives, maybe the answer is different?
robertlagrant 6y ago
> An API that could have been completed in 2 months will now take almost 4 months because I’ve wasted time putting in artificial stopping points along the way. My imposter syndrome starts to set in, but at least management will have pretty burndown charts. This seems to be a failing of the author.
- cdmckay 6y ago
  And when he delivers the API in 2 months, it's not what the customer wants and has a bunch of problems that are difficult to fix because he delivered it all at once instead of incrementally.
  - choeger 6y ago
    "incremental API", exactly. Did you ever do that in practice or are you just repeating some scrum talking points?
    - fvdessen 6y ago
      If the hypothetical API is taking 2 months to implement best case scenario I assume it's doing multiple things and each of those things can be done and tested piecewise.
      - Traster 6y ago
        I really think you're missing the forest for the trees. His point was simply a big task can be broken down into smaller tasks that don't necessarily magically fit into 2 week chunks, and if you pick tasks that you know you can do within 2 weeks, often you're picking between 1-2weeks worth of work, and then the work stretches to fill the time. It's not about how many actual endpoints there are or how you actually choose to split the tasks.
      - choeger 6y ago
        Or maybe, the model is actually just rather complex and a good API cannot be just a bunch of random methods on some losely related entities. Or maybe the non-functional aspects of the implementation need to be carefully considered before releasing an API that makes safety, correctness, security, or performance impossible. Or maybe the developers have an inconsistent specification and delivering piece A now makes it logically impossible to ever deliver piece B, which is arguably more important, but got lower priority because noone took the time to understand the whole thing.
rergaerg 6y ago
Dont need to see who wrote this, clearly a very junior engineer with a lot of opinions and not a lot of experience.
tgaj 6y ago
Seriously, you don't plan 14 sprints at once. You plan for one sprint, and you need to synchronize with the rest od the team. Scrum is about teamwork and product iterations, if you start from "i need API with 14 endpoints" and you will do that alone then that's not Scrum.
- the_other 6y ago
  Totally! - How do you know you need 14 endpoints? - What do they do? - Do you need them all delivered in one go? Why? - Can you make something, useful to the bulk of your users, with three or four endpoints? - Who uses the endpoints? Can they do some of their work whilst you make your endpoints? - What goes over these endpoints? All these, and more, affect how you build and what you build. Scrum, and agile in general, should help you organise the work (where "work" includes planning, design, collaboration, as well as build and release), and gives you space to improve the quality of the work (when it's done well).
- snovv_crash 6y ago
  "That's not scrum" is what I hear every time someone has a problem with it. Being able to follow Scrum seems to be harder than getting work done...
michaelmior 6y ago
I don't really feel the need to read this since I'm currently working from home on Rugby Ave.
foobar_ 6y ago
Can't we just create a new methodology called blame game ?
mnm1 6y ago
At my current job, scrum is just a half hour meeting every day where people discuss whatever for however long and the most important is the status update to make sure management knows that you are working. The upside is we don't do sprints, retrospectives, scrum master etc. although estimates are still required. Someone will probably claim this is not scrum, the no true Scotsman fallacy. I wouldn't mind much if it wasn't early in the morning at such a shitty time it messes up the whole day's schedule by interrupting sleep for no reason. Whatever. It's management's loss as contributing meaningfully, by speaking or listening, is simply impossible. The half hour duration is extreme. It's a great argument against such meetings, regardless of what they are called, especially morning meetings. It definitely makes the whole day and especially the morning much less productive due to draining the natural energy one has in the morning. Really, I can't think of a way it could be worse other than it being earlier and longer.
kstenerud 6y ago
I've yet to find myself in a scrum or agile situation that wasn't dysfunctional. The most common sin is the standup, where each person talks for 5 minutes about something while everyone else tunes out. It's a complete waste of 30 minutes a day, made worse because you're tired of standing and just want to get back to doing things or meeting with people you actually need to meet with. I understand the theory behind it, but I haven't seen that actually happen in my entire 25 year career. Next up is the sprint, which I've actually seen work somewhat in some companies. Generally, when they're doing it right, they'll have a "next up" lane for things that someone is serious about, in priority order, and actively maintained by the stakeholders (with an arbiter). And then the "backlog" is a black hole where things go to die (which isn't a bad thing). People grab from the "next up" lane the things they think they can get done in a sprint (keeping in mind the priorities), and off they go. That's the best case. More commonly, it's a morass of crap nobody cares about anymore, complete with questionable tasks, top-down requests (with no pipeline to discuss), or not broken down into manageable chunks. Generally, when companies adopt "agile", there's a lot of paperwork, meetings and activity, but very little communication and accomplishment. The only worse thing I can think of is peer reviews.
- matthewmacleod 6y ago
  30 minutes a day I have found your problem.
  - kstenerud 6y ago
    No, you haven't. The problem is the useless interruption and waste of time that saps your flow, and the aggravation of scheduling your daily activities around it. The duration of this interruption only serves to make a bad thing even worse. Even if it were only 5 minutes, it would still be a problem because you're still stuck in a meeting that's not accomplishing anything useful.
    - gbear605 6y ago
      If it’s the first thing done in the morning it doesn’t interrupt anyone, and I’ve personally gotten more than my five minutes of value out of standups.
LandR 6y ago
Scrum is a way to take a below average or poor developer and turn them into an average developer. It's also great at taking great developers and turning them into average developers. Everyone just wants to take something easy off the board that you can get done in a day so you have something to report in tomorrows daily scrum. It's just everyone trying to pick the low hanging fruit. THere's no incentive to be smart and to take time to think about solutions, if nothing is moving across what are you even doing? You're letting the team down! The velocity is falling! I think if you have hard problems to solve you solve them by giving them to smart people then leaving them the fuck alone. You don't constantly harras them everyday demanding to know what they did yesterday and what they plan to do today. With daily updates where is the incentive for the smart people to work on the hard problems? They now have the same incentive as the junior developer, find the easiest tickets to move across the board. Sometimes I will want to just be alone and think about a solution for a few days. If I do that though I'd have nothing to say at the scrum. So instead I'll pick the user story where the colour on a front end was the wrong shade of green or a spelling mistake! See, I knocked out 2 stories in one day, before lunch! Go me! And it all looks like progress because stupid cards are moving across a pointless board. Scrum exists because managers don't trust developers to get things done without constant supervision and an ever present threat of looking bad for your team. It takes a team of potentially really smart people and turns them into a code production line. It's depressing.
- gbear605 6y ago
  I’ve had good experiences with scrum helping a team that has both experienced (10+ yrs) and junior (straight out of college) devs be productive. Letting the junior devs take the easy tickets allows the seniors to focus on the hard problems while the junior devs learn the system. But that only works when management is willing to say “this ticket will be on the board for a while and that’s okay, we won’t harass you about it.” That is, scrum is decent for organization but bad for management. A good tipoff is how long standup lasts. It should be no longer than 15 minutes for a team of six, and that’s stretching it. Aim for 1-2 minutes of talking. That’s more than enough to say “I worked on tickets X and Y, I’m stuck on A and making good progress on B.”
  - 6y ago
jon-wood 6y ago
I've always been quite fiercely against Scrum as a development process, and I still am in the context of constantly evolving cloud based services, but I've recently seen it being done to great effect for mobile app development. I think this is similar to Pete Hodgson's clarification[1] that gitflow (which he originally documented) isn't suitable in that sort of environment. If you've got a constantly deployed set of artifacts it doesn't make sense to plan in two week blocks, and then freeze a release. In the world of software which has actual discrete releases then you either have a massive gap between releases as you get everything just right, or you say "every two weeks we'll release what's ready", and for that approach Scrum works really well. When you're working on cloud hosted services the typical approach is more of releasing things as they're ready, possibly sitting behind feature flags or partial rollouts, and for that Kanban has worked much better in my experience. It gives more flexibility around changing priorities, and space for the inevitable production incidents and technical support that can suck up a week of time out of nowhere. [1] https://twitter.com/ph1/status/1260702766118232065?s=21 https://twitter.com/ph1/status/1260702766118232065?s=21
- bryanrasmussen 6y ago
  I agree scrum is too heavy for a release every two weeks thing, what it's good for in my book is: You have a very big project to make and you know exactly what it needs to contain, examples: 1. you have an application that users already use but you need to move off a platform by a particular time or you are screwed. So you know exactly what you need to replicate in the new platform (your current functionality) and you have a set deadline to do it in. For me it was the company got sold and we needed to be off of Thomson Reuters platform within a year or pay over $100,000 a month to use it. 2. You have entered into a legally binding contract and you know what the application is going to need to contain and what you can drop without getting sued or not getting paid. If it is your own application you can always stretch timelines out a bit to get to where you need to be, or you can decide to drop features to get to where you want to be. But once there are other people in there you might not be able to stretch timelines of drop features, and then you need something that gives you a way of alerting you beforehand if you're going off the rails.
  - 6y ago
oneplane 6y ago
Every time another one of those anti-agile or anti-agile-scrum pops up it seems to just be someone having a bad experience. The point of a methodology isn't to follow the methodology, but to use what is useful. Maybe 1 or 2 weeks per sprint isn't useful. Then maybe don't do that. Or maybe you can't estimate how much time your development might take. In that case, maybe do a little more thinking instead of presenting a black hole of time to the people that pay you. Take apart the problem until you do get a sense of how complex and/or time-consuming it might be. Same goes for the deliverables or measurable impact; just because something has a name "an endpoint, a button, a page" doesn't mean that that defines a quantity of work or defines what you can or must deliver. Plan for what you know can be made, not for what you don't know. Having 6 months of 'planned' development seems highly unlikely to be successful, why not plan 1 month at most, and re-plan when you are near the end of the run. If people keep planning things they cannot predict it's going to keep failing.
- choeger 6y ago
  > The point of a methodology isn't to follow the methodology, In scrum, it is. Scrum was developed for managers to distract from the fact that they know nothing about software. So the methodology is all there is. Go ahead, ask a (non developer) scrum master about why there need to be cross functional teams, when 80% of your work never crosses the component boundary. Or go ask them who priorizes bug fixing (do this when PO, Ops, and customer care share the same room, hilarious!).
  - oneplane 6y ago
    I'm not sure what managers have to do with scrum here. A manager is a person that insulates business from the execution on a non-functional level. Perhaps this is a difference in where you work (the company, the culture, the country), but here a manager is just someone who has the job of making sure there are no obstructions and people have what they need and don't get shifted around too much. Priorities are made based in input from owners, users and developers, and cross-functional teams are something that you do in a SIG, not in a development team. Maybe SCRUM (R) as a commercial idea has a lot of things it wants you do to, but that's not really why you'd even consider something; you consider something because it might help you or clarify something for others, and for novices it can be great if you don't have the experience, skills, insight or level of thinking to come up with a self-improving process by yourself.
yoz-y 6y ago
> Let’s also say that in my head I believe the whole task to take two months if I can work consistently. Believe it as much as you want but this estimate has a massive chance of being wrong. After that the reasoning falls apart. Also don't assign time to points, that's completely missing the point.
- bvrmn 6y ago
  > Also don't assign time to points, that's completely missing the point. Yeah, yeah. We are not true Scotsmans. In every job for last 10 years there was an implicit points -> time conversion table. And management can walk in and ask why you promise to complete a task in 1 point. It makes no sense at all.
  - yoz-y 6y ago
    One article I quite liked was the one about Commoditized Excellence. https://barryhawkins.com/blog/posts/the-myth-of-commoditized-excellence/ https://barryhawkins.com/blog/posts/the-myth-of-commoditized... It would be ironic to resume the article but the gist is that when rather complex reasonings get distilled into few bullet points tagged with a catchy name, then they get misused and criticised for things the original idea expressly called out. In this case you shouldn't be promising management anything because the points only mean something in the context of a team.
    - bvrmn 6y ago
      If you dig deeper then scrum overall is a very complex thing trying to solve non-root problems. It is very ironic that scrum is Commoditized Excellence on its own. Scrum in a nutshell: 1) We need to periodically check product to cut invalid activity on early stages. Let's do it in sprints with defined goals! 2) Great, now we need to complete a goal to the end of a sprint. How do we know that a team will fulfill a goal? Lets plan a sprint according to team capacity! 3) What is team capacity? It is a historic velocity metric measured in time per task in past sprints. But estimating time in time units is ... ... mambo jambo ... whatever (I did not grok what is TRUE SCRUM explanation is) ... bad, sorta. So we introduce points to estimate task size. 4) How do we estimate? Planning poker every sprint! 5) And let's add formal process to evaluate every sprint to be more serious! It's an artificial construct to solve point 2) only. Drop a goal completion requirement and scrum will not be needed.
wayoutthere 6y ago
I look at it this way: Agile is a bare-minimum project management methodology. That can mean different things for everyone, so look at "traditional Agile practices" as a menu rather than a recipe. If scrums don't work for your team, then either don't do them or find a way to make them more useful. I've always felt that most companies do "scrums" wrong. It's not supposed to be an hour-long status report; it's supposed to be a 15-minute check-in to identify blockers and connect people so those issues can be addressed outside of the scrum. A good scrummaster should be able to clamp down on the "status report" aspect of it, but it's really hard to find a good scrummaster since it's largely seen/compensated as an entry-level position.
dogman144 6y ago
Estimate the work that comes in, commit to that work for x amount of time +/- 5-10% variance, evaluate ability to finish it all, and re-balance accordingly, all in all is a pretty effective productivity approach. When the alternative is a near certainty miss of waterfall and tremendous, tremendous cost overages, then scrum starts to look like the less ugly dance partner. Consistent challenges I see for anti-Scrum arguments: 1) Their POs are doing a horrible job defining what an MVP is, or the devs aren't following good MVP practices. The MVP solution as something that works outside of Scrum is well proven in numerous other contexts, regardless of what a developer designing an API may think. 2) Their Scrum Masters are allowed to turn into managers, not process governors. The silly SM metrics SMs start to make to increase their job justification suddenly govern teams and paychecks. 3) Their management doesn't understand what POs and SMs are really supposed to do. 4) Ok, present an alternative to Scrum, waterfall, in a way that works with financial reporting and accountability to the people that pay the bills and paychecks. This is the major sticking point. Criticize Scrum :thumbsup: Come up with an alternative that meshes with the reality of software the profit-seeking business :silence:.
kemiller2002 6y ago
I think the theory of scrum is great. When you think about it, Scrum does most of everything that we should be doing. Thinking about problems before tackle them. Talking everyday about the problems in case someone needs help. Course correcting when you need to. The problem is management. Tools (burn down charts) now become executive metrics. Amount of code completed now becomes a review item for advancement. We've applied measures to things that are inappropriate for what they are used for, and because of this honest communication has been replaced with guarded statements to make sure that the team never stumbles with its work. No matter what process an organization uses in those places will fail, because management wants to hear things are running fine.
deleted 6y ago
[deleted]
DanielBMarkham 6y ago
Sort of a whirlwind tour of all the misconceptions the average dev might have about agile/scrum. Yet again, here goes. - The problem here is dogmatism, both yours and whoever is "doing scrum" to you. There is no Scotsman! He ran away. That is, it's only if you're insisting whether you're doing it right or wrong can you start to have the conversation about what is right or wrong. Your premise is invalid. - Confusion over terms. These things are much better represented mentally by the image of a bookstore. You arrive at a bookstore and want to read up on some stuff related to teams and planning. Cool! There's a scrum section, just next to the agile section. Guess what? The books don't all agree with one another, and that's fine. It's a marketing term, a place to go for ideas. It gets worse after that, with dysfunctions of estimating and so forth, but you start out with your head in the wrong place, whether you love X or hate X, it's not going to end well. Do stuff you like, make stuff people want, and get stuff done. If that's not working for you, here's some titles of sections in the bookstore where you might want to read some other stuff. There are other sections. If you find some sections that have cool stuff, let me know. I might could learn some neat stuff I might use one day. That's it. It's nothing more complicated than that. You can go to those sections and learn a whole bunch of stuff about various problems you might have. Try some if you like. Or not. What you can't do is go to that section and pull some book out as if it were a recipe and then "implement" it on a team or organization. It doesn't work like that, and it's never going to work like that, whether your view is from the top or bottom of an org. You're doing it backwards. It hurts when you do that? Ok. So stop doing it that way.
supermatt 6y ago
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. That said, lets clear up some misinformation: 1) Scrum is vague? It said it right there: "Scrum is a framework" - Scrum is NOT a process, technique, or definitive method. 2) On delivery windows - "I’m not against management being informed… but at what cost?". Scrum works well for businesses/departments that have a development need, not where the business IS development. It needs to fit into the business, not vice versa, and that means managing stakeholder expectations. 3) On scrum managers - "let the lead developers handle the job." Of course! Or your development team manager, depending on your org setup. The roles in scrum are ROLES - not a new org structure. 4) Estimates - sure, points are stupid. They literally make no sense. They aren't prescribed by scrum in any way, shape, or form. There is nothing wrong with using time as an estimate. Period. I think the target audience of Scrum could be made a LOT more clear. It would save a lot of heartache and hate. I think successful marketing and certification have become the chief enemy of Scrum - orgs have tried to shoehorn it in everywhere, and thats not what it is for.
matthewmacleod 6y ago
I, too, like getting stuff done. The way I get the most stuff done is meeting with the rest of my team every two weeks to: - Look at what stuff needs to be done next, based on the stuff we want to do, stuff that other people want us to do, and stuff we don't want to do but need to do anyway - Figure out between us how much work is involved in doing that stuff - Review how much stuff we did in the last two weeks to see if we did what we expected to - Use that information to agree between us how much of that stuff we think we can do in the next two weeks - Make sure that we have all of the information and prerequisites to do that stuff - Based on all that, to estimate how long all the stuff will take, pick which stuff that we expect to be able to reasonably do, and prioritise what's most important Then every day, we check in for 10 minutes to see if there are any problems doing the stuff, if unexpected stuff needs to be done urgently, or if we want to show the stuff to anyone else. Once every two weeks, we show everyone else what stuff we did and answer any questions about it; once every couple of months, we all sit down together with other people, look at our list of stuff that we want to do over the next six months, make sure we all agree on what the plans are over that timeframe, and make any adjustments we think we need to. Someone is in charge of making sure that all those things happen, that everyone has what they need to do their stuff, and that everyone outside the team knows what stuff is being done. This is just Scrum using words that don't piss engineers off to the same extent. Scrum is nothing particularly special or magic – it just provides a basic set of tools and terms to describe a bunch of interactions and help keep them on track, and they are for the most part pretty reasonably tools. And here's the reason this is not a good article – it makes the same basic mistake as many others do and assumes that a development framework is somehow supposed to magically fix your broken team. A bad manager is a bad manager, regardless of whether you call them a "scrum master" or something else.
ubermonkey 6y ago
In my experience, the vast majority of developers grousing about scrum and agile are mostly mad they're being made to (a) talk to their coworkers or attend ANY meeting at all or (b) account for their work. But hey, it's HN, so I'm sure there will be absolutely no other positive comments about the methodology here.
lanecwagner 6y ago
Author here, love the comments. The biggest criticism that makes me want to revisit and edit the article is the 2-month -> 4-month API example. I remain convinced that the Scrum process that I describe is OFTEN responsible for slowing down projects AT LEAST this much. That said, I think I need to come up with a better example. It's honestly hard to explain in words.
lasereyes136 6y ago
Scrum is a tool. It can be used well, it can be used poorly. It is good for some situations and bad for others. The author of the article makes some good points with the key for me being Scrum isn't agile. For me Scrum is a place to start an agile transformation but it is often the wrong place to end your transformation.

59 points by lanecwagner 6y ago

Good points in the article but I have to mention a scrum master isn’t supposed to be telling people what to do, but rather coach on the scrum process.

BiteCode_dev 6y ago
And you are not suppose to have the entire rugby team in the scrum, only people who's work intersect. If currently the designer is not working on the same project than the dev, they should not be in the same scrum. Keep it short, to the point. Scrum is not a meeting, it's an interactive tiny bite of field report. Make it anything bigger than that, and you are not doing agile anymore.
- richliss 6y ago
  The Daily Scrum is frequently misunderstood - it's actually to replan to remaining work required to achieve the sprint goal not a status update or field report. It might well mean that you need to bring in the Product Owner to tell them the news so that together you discuss what is delivered to meet the definition of the sprint goal can be adjusted within acceptable boundaries. If you're wondering why you should accept this definition it's because I recently attended the Scrum Patterns course run by Jim Coplien (the guy who codified the definition of the Daily Scrum and is the co-author of "A Scrum Book" with Jeff Sutherland) and heard it directly from him.
  - BiteCode_dev 6y ago
    Field reports are meant to replan the remaining work. That's the whole purpose of field reports. But I understand what you mean: too many people use it to track activity, not as input for the agile loop.
chrisseaton 6y ago
> but I have to mention a scrum master isn’t supposed to be... This is a major problem with Scrum. There's always someone telling you you're doing it wrong. If nobody's able to implement your big idea properly, maybe the problem is with the idea or how you're explaining it, not the people trying to do it.
- a_imho 6y ago
  There's always someone telling you you're doing it wrong. Of course there are, and they are probably paid handsomely for their insight. How is a process that wants to implement individuals and interactions over processes and tools not a parody?
taneq 6y ago
I dunno if you've ever played team sports but roughly 50% of the coach's job is figuring out what you could be doing better, and the other 50% is telling you what to do and how to do it.
- quickthrower2 6y ago
  My point is that it’s the scrum process they coach on, not the content of tasks themselves.
thrower123 6y ago
If a process is so hard to implement correctly that no one is able to do it effectively, then maybe the process should be tailored to the realities of real people.

caust1c 6y ago

I'm no scrum fanatic, but there's real value in doing estimates at the beginning of work, then reviewing how long it took at the end of work (without revising estimates mid workstream). The point of separating these from actual time is not to make people feel better about themselves, it's about accounting for how much unplanned work there is in your organization which is different from org to org and even project to project. By reflecting on how many "story points" some piece of work took, then you get better at estimating how much calendar time something will actually take. FWIW, I've never seen this work in a team setting. I use it in an individual setting where I estimate work for myself, then gauge how much I can get done in the context of a project or org.

hrktb 6y ago
I always wondered how it worked in functionnal organizations so perhaps You could tell me. We were told the base principle was to have a stable team and a stable stack, and at some point we had reference tasks to calibrate our point system. But then we had team shuffles about every 6 months ~ 1 year, so team velocity was a fantasy. Then we changed core libraries, introduced services using new stacks, built new API, adapted to other teams’ new paradigms. And all of these changes felt to be for the better to us. Everyone would have left if we kept everything inu place for the sake of point consistency. Basically, how did you deal with change ?
- loopz 6y ago
  If you read your own post, for you, the answer gives itself. For managers and executives, maybe the answer is different?

robertlagrant 6y ago

> An API that could have been completed in 2 months will now take almost 4 months because I’ve wasted time putting in artificial stopping points along the way. My imposter syndrome starts to set in, but at least management will have pretty burndown charts. This seems to be a failing of the author.

cdmckay 6y ago
And when he delivers the API in 2 months, it's not what the customer wants and has a bunch of problems that are difficult to fix because he delivered it all at once instead of incrementally.
- choeger 6y ago
  "incremental API", exactly. Did you ever do that in practice or are you just repeating some scrum talking points?
  - fvdessen 6y ago
    If the hypothetical API is taking 2 months to implement best case scenario I assume it's doing multiple things and each of those things can be done and tested piecewise.
    - Traster 6y ago
      I really think you're missing the forest for the trees. His point was simply a big task can be broken down into smaller tasks that don't necessarily magically fit into 2 week chunks, and if you pick tasks that you know you can do within 2 weeks, often you're picking between 1-2weeks worth of work, and then the work stretches to fill the time. It's not about how many actual endpoints there are or how you actually choose to split the tasks.
    - choeger 6y ago
      Or maybe, the model is actually just rather complex and a good API cannot be just a bunch of random methods on some losely related entities. Or maybe the non-functional aspects of the implementation need to be carefully considered before releasing an API that makes safety, correctness, security, or performance impossible. Or maybe the developers have an inconsistent specification and delivering piece A now makes it logically impossible to ever deliver piece B, which is arguably more important, but got lower priority because noone took the time to understand the whole thing.

rergaerg 6y ago

Dont need to see who wrote this, clearly a very junior engineer with a lot of opinions and not a lot of experience.

tgaj 6y ago

Seriously, you don't plan 14 sprints at once. You plan for one sprint, and you need to synchronize with the rest od the team. Scrum is about teamwork and product iterations, if you start from "i need API with 14 endpoints" and you will do that alone then that's not Scrum.

the_other 6y ago
Totally! - How do you know you need 14 endpoints? - What do they do? - Do you need them all delivered in one go? Why? - Can you make something, useful to the bulk of your users, with three or four endpoints? - Who uses the endpoints? Can they do some of their work whilst you make your endpoints? - What goes over these endpoints? All these, and more, affect how you build and what you build. Scrum, and agile in general, should help you organise the work (where "work" includes planning, design, collaboration, as well as build and release), and gives you space to improve the quality of the work (when it's done well).
snovv_crash 6y ago
"That's not scrum" is what I hear every time someone has a problem with it. Being able to follow Scrum seems to be harder than getting work done...

michaelmior 6y ago

I don't really feel the need to read this since I'm currently working from home on Rugby Ave.

foobar_ 6y ago

Can't we just create a new methodology called blame game ?

mnm1 6y ago

At my current job, scrum is just a half hour meeting every day where people discuss whatever for however long and the most important is the status update to make sure management knows that you are working. The upside is we don't do sprints, retrospectives, scrum master etc. although estimates are still required. Someone will probably claim this is not scrum, the no true Scotsman fallacy. I wouldn't mind much if it wasn't early in the morning at such a shitty time it messes up the whole day's schedule by interrupting sleep for no reason. Whatever. It's management's loss as contributing meaningfully, by speaking or listening, is simply impossible. The half hour duration is extreme. It's a great argument against such meetings, regardless of what they are called, especially morning meetings. It definitely makes the whole day and especially the morning much less productive due to draining the natural energy one has in the morning. Really, I can't think of a way it could be worse other than it being earlier and longer.

kstenerud 6y ago

I've yet to find myself in a scrum or agile situation that wasn't dysfunctional. The most common sin is the standup, where each person talks for 5 minutes about something while everyone else tunes out. It's a complete waste of 30 minutes a day, made worse because you're tired of standing and just want to get back to doing things or meeting with people you actually need to meet with. I understand the theory behind it, but I haven't seen that actually happen in my entire 25 year career. Next up is the sprint, which I've actually seen work somewhat in some companies. Generally, when they're doing it right, they'll have a "next up" lane for things that someone is serious about, in priority order, and actively maintained by the stakeholders (with an arbiter). And then the "backlog" is a black hole where things go to die (which isn't a bad thing). People grab from the "next up" lane the things they think they can get done in a sprint (keeping in mind the priorities), and off they go. That's the best case. More commonly, it's a morass of crap nobody cares about anymore, complete with questionable tasks, top-down requests (with no pipeline to discuss), or not broken down into manageable chunks. Generally, when companies adopt "agile", there's a lot of paperwork, meetings and activity, but very little communication and accomplishment. The only worse thing I can think of is peer reviews.

matthewmacleod 6y ago
30 minutes a day I have found your problem.
- kstenerud 6y ago
  No, you haven't. The problem is the useless interruption and waste of time that saps your flow, and the aggravation of scheduling your daily activities around it. The duration of this interruption only serves to make a bad thing even worse. Even if it were only 5 minutes, it would still be a problem because you're still stuck in a meeting that's not accomplishing anything useful.
  - gbear605 6y ago
    If it’s the first thing done in the morning it doesn’t interrupt anyone, and I’ve personally gotten more than my five minutes of value out of standups.

LandR 6y ago

Scrum is a way to take a below average or poor developer and turn them into an average developer. It's also great at taking great developers and turning them into average developers. Everyone just wants to take something easy off the board that you can get done in a day so you have something to report in tomorrows daily scrum. It's just everyone trying to pick the low hanging fruit. THere's no incentive to be smart and to take time to think about solutions, if nothing is moving across what are you even doing? You're letting the team down! The velocity is falling! I think if you have hard problems to solve you solve them by giving them to smart people then leaving them the fuck alone. You don't constantly harras them everyday demanding to know what they did yesterday and what they plan to do today. With daily updates where is the incentive for the smart people to work on the hard problems? They now have the same incentive as the junior developer, find the easiest tickets to move across the board. Sometimes I will want to just be alone and think about a solution for a few days. If I do that though I'd have nothing to say at the scrum. So instead I'll pick the user story where the colour on a front end was the wrong shade of green or a spelling mistake! See, I knocked out 2 stories in one day, before lunch! Go me! And it all looks like progress because stupid cards are moving across a pointless board. Scrum exists because managers don't trust developers to get things done without constant supervision and an ever present threat of looking bad for your team. It takes a team of potentially really smart people and turns them into a code production line. It's depressing.

gbear605 6y ago
I’ve had good experiences with scrum helping a team that has both experienced (10+ yrs) and junior (straight out of college) devs be productive. Letting the junior devs take the easy tickets allows the seniors to focus on the hard problems while the junior devs learn the system. But that only works when management is willing to say “this ticket will be on the board for a while and that’s okay, we won’t harass you about it.” That is, scrum is decent for organization but bad for management. A good tipoff is how long standup lasts. It should be no longer than 15 minutes for a team of six, and that’s stretching it. Aim for 1-2 minutes of talking. That’s more than enough to say “I worked on tickets X and Y, I’m stuck on A and making good progress on B.”
- 6y ago

jon-wood 6y ago

I've always been quite fiercely against Scrum as a development process, and I still am in the context of constantly evolving cloud based services, but I've recently seen it being done to great effect for mobile app development. I think this is similar to Pete Hodgson's clarification[1] that gitflow (which he originally documented) isn't suitable in that sort of environment. If you've got a constantly deployed set of artifacts it doesn't make sense to plan in two week blocks, and then freeze a release. In the world of software which has actual discrete releases then you either have a massive gap between releases as you get everything just right, or you say "every two weeks we'll release what's ready", and for that approach Scrum works really well. When you're working on cloud hosted services the typical approach is more of releasing things as they're ready, possibly sitting behind feature flags or partial rollouts, and for that Kanban has worked much better in my experience. It gives more flexibility around changing priorities, and space for the inevitable production incidents and technical support that can suck up a week of time out of nowhere. [1] https://twitter.com/ph1/status/1260702766118232065?s=21 https://twitter.com/ph1/status/1260702766118232065?s=21

bryanrasmussen 6y ago
I agree scrum is too heavy for a release every two weeks thing, what it's good for in my book is: You have a very big project to make and you know exactly what it needs to contain, examples: 1. you have an application that users already use but you need to move off a platform by a particular time or you are screwed. So you know exactly what you need to replicate in the new platform (your current functionality) and you have a set deadline to do it in. For me it was the company got sold and we needed to be off of Thomson Reuters platform within a year or pay over $100,000 a month to use it. 2. You have entered into a legally binding contract and you know what the application is going to need to contain and what you can drop without getting sued or not getting paid. If it is your own application you can always stretch timelines out a bit to get to where you need to be, or you can decide to drop features to get to where you want to be. But once there are other people in there you might not be able to stretch timelines of drop features, and then you need something that gives you a way of alerting you beforehand if you're going off the rails.
- 6y ago

oneplane 6y ago

Every time another one of those anti-agile or anti-agile-scrum pops up it seems to just be someone having a bad experience. The point of a methodology isn't to follow the methodology, but to use what is useful. Maybe 1 or 2 weeks per sprint isn't useful. Then maybe don't do that. Or maybe you can't estimate how much time your development might take. In that case, maybe do a little more thinking instead of presenting a black hole of time to the people that pay you. Take apart the problem until you do get a sense of how complex and/or time-consuming it might be. Same goes for the deliverables or measurable impact; just because something has a name "an endpoint, a button, a page" doesn't mean that that defines a quantity of work or defines what you can or must deliver. Plan for what you know can be made, not for what you don't know. Having 6 months of 'planned' development seems highly unlikely to be successful, why not plan 1 month at most, and re-plan when you are near the end of the run. If people keep planning things they cannot predict it's going to keep failing.

choeger 6y ago
> The point of a methodology isn't to follow the methodology, In scrum, it is. Scrum was developed for managers to distract from the fact that they know nothing about software. So the methodology is all there is. Go ahead, ask a (non developer) scrum master about why there need to be cross functional teams, when 80% of your work never crosses the component boundary. Or go ask them who priorizes bug fixing (do this when PO, Ops, and customer care share the same room, hilarious!).
- oneplane 6y ago
  I'm not sure what managers have to do with scrum here. A manager is a person that insulates business from the execution on a non-functional level. Perhaps this is a difference in where you work (the company, the culture, the country), but here a manager is just someone who has the job of making sure there are no obstructions and people have what they need and don't get shifted around too much. Priorities are made based in input from owners, users and developers, and cross-functional teams are something that you do in a SIG, not in a development team. Maybe SCRUM (R) as a commercial idea has a lot of things it wants you do to, but that's not really why you'd even consider something; you consider something because it might help you or clarify something for others, and for novices it can be great if you don't have the experience, skills, insight or level of thinking to come up with a self-improving process by yourself.

yoz-y 6y ago

> Let’s also say that in my head I believe the whole task to take two months if I can work consistently. Believe it as much as you want but this estimate has a massive chance of being wrong. After that the reasoning falls apart. Also don't assign time to points, that's completely missing the point.

bvrmn 6y ago
> Also don't assign time to points, that's completely missing the point. Yeah, yeah. We are not true Scotsmans. In every job for last 10 years there was an implicit points -> time conversion table. And management can walk in and ask why you promise to complete a task in 1 point. It makes no sense at all.
- yoz-y 6y ago
  One article I quite liked was the one about Commoditized Excellence. https://barryhawkins.com/blog/posts/the-myth-of-commoditized-excellence/ https://barryhawkins.com/blog/posts/the-myth-of-commoditized... It would be ironic to resume the article but the gist is that when rather complex reasonings get distilled into few bullet points tagged with a catchy name, then they get misused and criticised for things the original idea expressly called out. In this case you shouldn't be promising management anything because the points only mean something in the context of a team.
  - bvrmn 6y ago
    If you dig deeper then scrum overall is a very complex thing trying to solve non-root problems. It is very ironic that scrum is Commoditized Excellence on its own. Scrum in a nutshell: 1) We need to periodically check product to cut invalid activity on early stages. Let's do it in sprints with defined goals! 2) Great, now we need to complete a goal to the end of a sprint. How do we know that a team will fulfill a goal? Lets plan a sprint according to team capacity! 3) What is team capacity? It is a historic velocity metric measured in time per task in past sprints. But estimating time in time units is ... ... mambo jambo ... whatever (I did not grok what is TRUE SCRUM explanation is) ... bad, sorta. So we introduce points to estimate task size. 4) How do we estimate? Planning poker every sprint! 5) And let's add formal process to evaluate every sprint to be more serious! It's an artificial construct to solve point 2) only. Drop a goal completion requirement and scrum will not be needed.

wayoutthere 6y ago

I look at it this way: Agile is a bare-minimum project management methodology. That can mean different things for everyone, so look at "traditional Agile practices" as a menu rather than a recipe. If scrums don't work for your team, then either don't do them or find a way to make them more useful. I've always felt that most companies do "scrums" wrong. It's not supposed to be an hour-long status report; it's supposed to be a 15-minute check-in to identify blockers and connect people so those issues can be addressed outside of the scrum. A good scrummaster should be able to clamp down on the "status report" aspect of it, but it's really hard to find a good scrummaster since it's largely seen/compensated as an entry-level position.

dogman144 6y ago

Estimate the work that comes in, commit to that work for x amount of time +/- 5-10% variance, evaluate ability to finish it all, and re-balance accordingly, all in all is a pretty effective productivity approach. When the alternative is a near certainty miss of waterfall and tremendous, tremendous cost overages, then scrum starts to look like the less ugly dance partner. Consistent challenges I see for anti-Scrum arguments: 1) Their POs are doing a horrible job defining what an MVP is, or the devs aren't following good MVP practices. The MVP solution as something that works outside of Scrum is well proven in numerous other contexts, regardless of what a developer designing an API may think. 2) Their Scrum Masters are allowed to turn into managers, not process governors. The silly SM metrics SMs start to make to increase their job justification suddenly govern teams and paychecks. 3) Their management doesn't understand what POs and SMs are really supposed to do. 4) Ok, present an alternative to Scrum, waterfall, in a way that works with financial reporting and accountability to the people that pay the bills and paychecks. This is the major sticking point. Criticize Scrum :thumbsup: Come up with an alternative that meshes with the reality of software the profit-seeking business :silence:.

kemiller2002 6y ago

I think the theory of scrum is great. When you think about it, Scrum does most of everything that we should be doing. Thinking about problems before tackle them. Talking everyday about the problems in case someone needs help. Course correcting when you need to. The problem is management. Tools (burn down charts) now become executive metrics. Amount of code completed now becomes a review item for advancement. We've applied measures to things that are inappropriate for what they are used for, and because of this honest communication has been replaced with guarded statements to make sure that the team never stumbles with its work. No matter what process an organization uses in those places will fail, because management wants to hear things are running fine.

deleted 6y ago

[deleted]

DanielBMarkham 6y ago

Sort of a whirlwind tour of all the misconceptions the average dev might have about agile/scrum. Yet again, here goes. - The problem here is dogmatism, both yours and whoever is "doing scrum" to you. There is no Scotsman! He ran away. That is, it's only if you're insisting whether you're doing it right or wrong can you start to have the conversation about what is right or wrong. Your premise is invalid. - Confusion over terms. These things are much better represented mentally by the image of a bookstore. You arrive at a bookstore and want to read up on some stuff related to teams and planning. Cool! There's a scrum section, just next to the agile section. Guess what? The books don't all agree with one another, and that's fine. It's a marketing term, a place to go for ideas. It gets worse after that, with dysfunctions of estimating and so forth, but you start out with your head in the wrong place, whether you love X or hate X, it's not going to end well. Do stuff you like, make stuff people want, and get stuff done. If that's not working for you, here's some titles of sections in the bookstore where you might want to read some other stuff. There are other sections. If you find some sections that have cool stuff, let me know. I might could learn some neat stuff I might use one day. That's it. It's nothing more complicated than that. You can go to those sections and learn a whole bunch of stuff about various problems you might have. Try some if you like. Or not. What you can't do is go to that section and pull some book out as if it were a recipe and then "implement" it on a team or organization. It doesn't work like that, and it's never going to work like that, whether your view is from the top or bottom of an org. You're doing it backwards. It hurts when you do that? Ok. So stop doing it that way.

supermatt 6y ago

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. That said, lets clear up some misinformation: 1) Scrum is vague? It said it right there: "Scrum is a framework" - Scrum is NOT a process, technique, or definitive method. 2) On delivery windows - "I’m not against management being informed… but at what cost?". Scrum works well for businesses/departments that have a development need, not where the business IS development. It needs to fit into the business, not vice versa, and that means managing stakeholder expectations. 3) On scrum managers - "let the lead developers handle the job." Of course! Or your development team manager, depending on your org setup. The roles in scrum are ROLES - not a new org structure. 4) Estimates - sure, points are stupid. They literally make no sense. They aren't prescribed by scrum in any way, shape, or form. There is nothing wrong with using time as an estimate. Period. I think the target audience of Scrum could be made a LOT more clear. It would save a lot of heartache and hate. I think successful marketing and certification have become the chief enemy of Scrum - orgs have tried to shoehorn it in everywhere, and thats not what it is for.

matthewmacleod 6y ago

I, too, like getting stuff done. The way I get the most stuff done is meeting with the rest of my team every two weeks to: - Look at what stuff needs to be done next, based on the stuff we want to do, stuff that other people want us to do, and stuff we don't want to do but need to do anyway - Figure out between us how much work is involved in doing that stuff - Review how much stuff we did in the last two weeks to see if we did what we expected to - Use that information to agree between us how much of that stuff we think we can do in the next two weeks - Make sure that we have all of the information and prerequisites to do that stuff - Based on all that, to estimate how long all the stuff will take, pick which stuff that we expect to be able to reasonably do, and prioritise what's most important Then every day, we check in for 10 minutes to see if there are any problems doing the stuff, if unexpected stuff needs to be done urgently, or if we want to show the stuff to anyone else. Once every two weeks, we show everyone else what stuff we did and answer any questions about it; once every couple of months, we all sit down together with other people, look at our list of stuff that we want to do over the next six months, make sure we all agree on what the plans are over that timeframe, and make any adjustments we think we need to. Someone is in charge of making sure that all those things happen, that everyone has what they need to do their stuff, and that everyone outside the team knows what stuff is being done. This is just Scrum using words that don't piss engineers off to the same extent. Scrum is nothing particularly special or magic – it just provides a basic set of tools and terms to describe a bunch of interactions and help keep them on track, and they are for the most part pretty reasonably tools. And here's the reason this is not a good article – it makes the same basic mistake as many others do and assumes that a development framework is somehow supposed to magically fix your broken team. A bad manager is a bad manager, regardless of whether you call them a "scrum master" or something else.

ubermonkey 6y ago

In my experience, the vast majority of developers grousing about scrum and agile are mostly mad they're being made to (a) talk to their coworkers or attend ANY meeting at all or (b) account for their work. But hey, it's HN, so I'm sure there will be absolutely no other positive comments about the methodology here.

lanecwagner 6y ago

Author here, love the comments. The biggest criticism that makes me want to revisit and edit the article is the 2-month -> 4-month API example. I remain convinced that the Scrum process that I describe is OFTEN responsible for slowing down projects AT LEAST this much. That said, I think I need to come up with a better example. It's honestly hard to explain in words.

lasereyes136 6y ago

Scrum is a tool. It can be used well, it can be used poorly. It is good for some situations and bad for others. The author of the article makes some good points with the key for me being Scrum isn't agile. For me Scrum is a place to start an agile transformation but it is often the wrong place to end your transformation.