Leave scrum to rugby, I like getting stuff done
qvault.io
qvault.io
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.
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.”
That's really the key a lot of development orgs miss. You have to actually break down the work into smaller pieces and track progress on those pieces. "This feature will take 3 months to do. I will start now and three months later, a working feature will pop out of the black box." - will give most Project Managers a heart attack. "This feature will take 3 months to do. I'll take a few days to break it down into approximately 1-week sized milestones and throughout development we can talk about progress vs. those milestones." - ahhh, that's much better!
Given the available pool of poor/average/great developers, this may be the correct decision.
Model: There are a1, a2, a3 developers of poor/average/quality. Poor developers cost p1, have a default productivity of q1. Average developers cost and produce p2, q2 and great developers cost, produce p3, q3. Scrum brings everyone's productivity to q2. Note that no one gets a raise or pay cut.
Without Scrum your total payoff is
a1*(q1-p1) + a2*(q2-p2) + a3*(q3-p3)
a1*(q2-p1) + a2*(q2-p2) + a3*(q2-p3)
a1*q2 + a3*q2 > a1*q1 + a3*q3
(a1/a3) > (q3-q2)/(q2-q1)
q2 - q1 > 3q3 - 3q2
1Reminds me of https://youtu.be/VAAOnmOlrLU?t=155
Of course star developers hate Scrum. But star developer code is often crummy too, and technology advances so fast that I'm glad for every dollar I didn't pay for divine Win32 code.
Ye... No. Note that your made-up productivity algebra model crumbles as soon as you stop seeing developers as code churning machine and instead as what they should be, problem solvers. That's because quantity is not the only metric by which you can measure problems. Complexity and ease are others. A dozen average problems do not necessarily equate a single hard one. Hard problems can prove elusive to average devs and they're usually where you see materialize the limitations of the thinking that a single great developer can simply be replaced with a dozen average ones. One such manifestation is commonly called "technical debt".
I've run into situations recently where the work that nobody wants to do never gets done. Even experienced engineers fall into the trap of only wanting to work on interesting features and nobody wants to do the "needs to be done" shit work.
The deadline rapidly approaches, the senior engineers are working on whatever they want to work on and it's the dev lead who stays up late and gets done what needs to be done before the deadline. Lather, rinse and repeat for a few releases and you realize why even good managers fall to the temptation of micromanagement.
it's not that they don't trust them, it's that they don't get things done without constant supervision.
> potentially really smart people
potential is not actual. in actuality, most of your coworkers are decidedly average. and the average coder, like the average driver, isn't that great.
the solution for smart people (who also produce), is to not work at these places. easy.
i say this having only worked at 2 places that do scrum. both of those places had only enough superstars to count on one hand, and the rest of the staff were dullards. yet, they got things done, thanks to the micromanagement of scrum. i didn't participate in the scrum, because f' that.
In my team, we are just able to take the S cards, when the L cards are done. If a Junior get a L card, a senior will come and pair with him/her. Nobody tries to be clever, we all try to move forward together. As a Team.
What is your Scrum Master doing?
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.
I have found your problem.
If different people start at different times (the norm in tech), then there's no such thing as "first thing in the morning". You must interrupt people, which means that you should make sure it's more beneficial than the cost of interrupted flow.
This is not a reasonable argument.
As a former manager I had enormous fun tweaking and tuning the morning stand up to actually get it into a useful state. As with anything involving people there are complex dynamics, there are people who talk too much, talk too little, go off on tangents, only talk about what they want to do, don't mention blocks, insist on asking questions, Some talk too much- but only if they're the first to talk, some will always talk as much as the person before them.
It is very very difficult to get a group of engineers to have a productive stand up meeting.
Most likely because it's such an artificial construct. There are some people who will only talk when forced to. Others just won't shut up. Others try to embellish because they may not have "enough" to report at that time and don't want to look bad.
Ultimately, my experience has been that stand-up meetings slowly devolve over time into status reports, people don't listen during meetings, and if someone needs to know something, you pull them aside later talk with them (because it's almost certainly going to take longer than your stand-up allotment).
I just can't see any actual benefit to this process that was invented out of whole cloth (not to say that trying new things is bad - even invented things; rather, they should be tested and measured). What can't be measured can't be invalidated.
The key is being intentional about your process, no matter what that process is. If you can put in place strategies to solve all the problems standups are meant to solve, that's great, but the standups weren't originally designed by middle management, they were designed by engineers for a purpose.
Quite the opposite. Standup take no longer than 15 minutes, we frequently address issues which otherwise would have led to lots of rework. You need some discipline to do it right however.
Lot's of engineers are afraid to ask for help, or too proud. The standup helps people get help sooner. It also often shows where two people are actually doing the same thing, take a wrong path, help prioritize etc. I can't imagine a software project without a standup anymore.
It's funny, if I would pick out the two single most valuable things out of agile I would say standup and peer review.
I've never seen what you describe actually happen (although I know that this is the theory behind it).
TBH I haven't really noticed much difference in the accomplishments of scrum and non-scrum teams.
lol. too true.
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.
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 ?
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.
This seems to be a failing of the author.
It's not about how many actual endpoints there are or how you actually choose to split the tasks.
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.
There's definitely a time and a place for Agile-derived methodologies but not every project is a nail for this particular hammer.
Also, however, most software, especially 'enterprise', doesn't actually do what it's users need, and is a nightmare for it's users. That the functionality it would deliver and how it would do so was decided by managers in advance doesn't mean it actually works for those using it.
(And note even OP concludes by saying he does like "agile", just not "scrum" -- so taneq in arguing for avoiding rapid iteration for "functionality relatively well known in advance" is not necessarily making the same evaluation as OP either).
Part of what always happens in these discussions is we all come from our experience. I've seen it work, in such a way that convinces me it was because of it's iterative nature that it worked. taneq above, I would guess, has not.
As a field, we still haven't done great at working out a methodology to extract/abstract from these differing experiences to general consensus principles, when it comes to "how we write software". So we're all just arguing from our experiences, and such arguments show that experiences really differ. Not sure what to do with that. The arguments just go round and round. I don't think attempts to make this "empirical" and "data-driven" have proven satisfactory, they often seem to suffer from artificiality/lack of validity to me too.
(And as far as personal experience -- I think most of us who have been around 10+ years find that our opinions about 'the right way to do it' change over time, as our experiences show us different things; but that doesn't necessarily mean those who have been around longer are more likely to be right and should be defered to; clearly that defering to experience rarely happens anyway).
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.
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.
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.
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.
1) It is impossible to have specs for a complete project at the beginning. So let's ship piece by piece and accommodate spec changes as they are discovered.
2) We need at least some visibility on what to do so let's bundle a few short tasks for the (literally) foreseeable future.
3) Since we can't estimate task duration precisely because nobody ever managed to do it, let's find some measure on how much work we can get done.
4) How do we estimate this: empirically by progressive approximation.
5) This is not actually necessary.
Also I think that one of the more interesting parts of the planning poker is discussing the why a task may or may not take a long time. It can give insight into system complexity to people less familiar with a specific part of the project.
I must say though that the goal completion was more of a unicorn where I worked. We always had sprints overspill to the next one but that was not necessarily an issue.
If there is one thing I dislike about the scrum it is the rigidity which is often introduced. I think a laid back approach to it makes it more useful.
Backlog on every level is always non-empty. So sprint filling is not a problem. Planning step is not about visibility. You can have a near roadmap with any process.
But scrum tries to promise that we put only particular amount of tasks to be able to finish it. Sorta, in my experience there were only few finished sprint cases in different jobs with different teams, with and without scrum master. And from this moment scrum goes over the rails. Why we need this restriction at first place?
If they're time, you get held to it. People vaguely responsible for your rumeneration might look at ponder, "Why did it take eterm 3 days to complete that 6 hour task? He must be slacking!".
Points abstracts it away, so you don't get held to account over how long work took but instead hold the estimates to account in a fair way.
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.
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.
The whole point of sprints is that requirements are allowed to change, just not more frequently than there are sprints.
Most modern scrum implementations, you release every story when you're done. The sprint is just a concept for planning what stories you're going to do in those 2 weeks, and retro.
Personally I think plans and information can change in 2 weeks, so I prefer kanban.
But at this point here isn't much between them.
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.
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!).
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.
Then what's the point? If you cherry pick whatever you feel like, then why call it Scrum? There are people who benefit from Scrum but they are mainly not developers.
It doesn't matter how many fancy processes are named and marketed out there if they don't work for you.
The base concept of Scrum isn't any different from the base concepts of feedback loops and self-improvement; but if you call it feedback loops and self-improvement people don't really want it. That's where that marketing bs comes in, and the whole 'certified' nonsense.
You make your units of work as clear as possible, you make them small enough so you have an idea how things are going and you measure periodically to ensure you're not blindsided by human flaws all the time.
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.
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:.
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.
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.
But I understand what you mean: too many people use it to track activity, not as input for the agile loop.
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.
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?
But hey, it's HN, so I'm sure there will be absolutely no other positive comments about the methodology here.
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.
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.
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.
- 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).
Being able to follow Scrum seems to be harder than getting work done...