Hacker News Reader

Comment by DanHulton | Hacker News Reader

Every team I've worked on that has switched from Kanban to Scrum has slowed down and never regained the previous velocity. Further, many of the promised benefits of Scrum (things like better insight and predictability about delivery rates) never materialized.

Every team that I've worked on that has switched from Scrum to Kanban saw an immediate improvement in speed that never disappeared.

Once, just once, I was lucky enough to work on a team that switched from Kanban to Scrum, and then, mercifully, blissfully, back again. To be fair, I think we actually worked quicker after the return, though I don't know if that could be attributed to having actually learned some lessons from Scrum, or out of a fear that we'd one day return to it.

View on HN

I think the "problem" is that Scrum orients more to the needs of people outside the team. So, (in theory) you get clearer reporting and more visibility into whats going on. People expect that extra reporting to be free, but its not free. The time taken to do team task estimation, update jira tickets and have retrospectives is time spent not programming.

The sad truth is that most management teams would prefer their employees to be predictable and observable (ie, under control) than be efficient. Especially if nobody can actually quantitatively measure the loss of efficiency.

I agree. In my experience that outside visibility is mostly a mirage.

Velocity metrics, burndown charts, point estimations, and all of that have been at best aspirational white lies and at worst outright falsehoods on almost every scrum/agile team I've ever worked on in the past fifteen years.

In actuality many scrum teams are doing something closer to kanban day-to-day under the fake veneer of scrum/agile sprints on top to satisfy management and/or external parties.

Ye padding estimates and report time according to the estimate to make the burn down chart straight was what I learned to do when Scrum was forced on my team for no good reason at all.

-"It is impossible to do accurate estimates"

-"You will get better at it"

I wonder if the Scrum Master knew that in the end "get better" is "starting to cheat".

Do anyone else share this experience?

Estimation often is way off for construction projects, but would you hire a contractor who refused to hazard a guess of how long a job would take or how much it would cost?

Most companies have already hired the contractor though so this little dance is just pointlessness that kills motivation and velocity.

Surely an understanding of how much effort is needed to complete one project or another will inform their decisions of which to pursue.

If scrum provided that it might have some value.

It’s extremely doubtful if you get even a roughly accurate estimate of effort within one project let alone relative effort across two.

Meh. The time it takes to complete a project is usually somewhat flexible. What really matters is how valuable the project is. That is what needs to be estimated explicitly, and not just "I really like these two ideas lets do the cheaper one".

How can you estimate "value" without any idea what resources are needed or what else you will have to forgo to pursue the project?

Value meaning roughly revenue, not profit.

But estimating revenue is just as much of a shot in the dark as estimating effort, and if the effort is great enough it will cancel out the revenue.

The variation in effort is orders of magnitude smaller than that in value. Great value is very rarely canceled out by high effort and low value almost always cancel out low effort.

If revenue from a venture were so predictable you wouldn’t see the Funko Pop company destroying tons of inventory but you do.

You won't gain that understanding until you actually complete both of those projects.

Industries and occupations that manage estimates well do so because bulk of the work is repeatable and predictable, and the people doing that work have done nearly identical kind of work before. There is some variability involved, but there's only so much of it, and it yields to tried and true classical project management techniques (not the things that pass as "project management" in software companies).

For example, even an inexperienced carpenter, asked to install a door system they haven't seen before, will be able to do it two or three times to get a feel and work the kinks out, and then when they're hired to install it in 300 flats of a new apartment complex, they'll be able to give you an accurate estimate of time and effort required.

With software, almost universally, your project is meaningfully unique, and your workers have never worked on something very similar before. The sources of variability are endless - project-unique challenges ahead, programmers never doing that particular component in that particular combination of languages, libraries and frameworks, in their specific versions, programmers and PMs never working in that specific domain before, etc. - and that's before you add stakeholders changing their requirements every other week.

The understanding one needs to have first is that the software project they're holding a stake in is typically best thought of as R&D effort.

You’d think, but wildly inaccurate estimates are not rare at all (and many software projects are fairly routine themselves)

If revenue they bring is estimated you may only need relative comparison.

After all if dev team days that more perspective project is very likely cheaper to make, why would you choose the other one?

See? No need for detailed answers if there is sufficient difference in qualities.

Relative comparison is exactly the scrum method which is why they don't estimate with time. And I don't think revenue estimation is any less subject to variance.

At some point there is a need for time estimates, ye.

I don't ask contractors for a detailed breakdown, just the whole thing. And they either do a high padded fixed price or work per hour.

A friend who is an elictrician might do 100 similar rooms in a building and they have a detailed breakdown of "time per screw" more or less.

So I guess the accuracy depends on the sameness of tasks to do.

Would you hire a mathematician that doesn't "story point" conjectures? Yes. Would you hire one that does?

I find this analogy harder to understand. What am I hiring the mathematician to do in this example?

Research mathematics.

Do you get paid to do research or is there a deliverable at the end?

Yes, you get paid to do research and there are theorems delivered. Just like software projects, some never get delivered and you don't know when if they're not trivial.

Unless the contractor is willing to put in writing a "not to exceed" price, I've never put any faith in build estimates. I'd expect a professional to be able to give a rough estimate based on experience and scope, as well as clear communication as the project progresses. Rough estimate meaning accurate withing something like 20-30%, not a detailed breakdown by ever project and material expense.

I try to do the same in software projects. Estimating projects by hours is impossible, fibonnaci numbers are a meaningless abstraction, and spending time each sprint to discuss how it went, what the next sprint plan is and estimate every task is a waste of time.

What I can say is whether a task looks like something that could be done in an afternoon, a few days, a few weeks, or multiple months. Accuracy there comes with experience, but no one gets better by chopping the calendar year into 2 week intervals and pouring a ton of process all over it.

Constructions remains a terrible analogy for software development, as it always has been.

Would you agree to pay for any service where not even an estimate of the price could be given? I guess healthcare is the only example I can think of where anyone consents to that.

Estimates you get are what the estimator thinks you will pay (mostly) not how much it costs them.

Prices in the real world are barely linked to costs. Budget risks are bundled in markets with high variance.

Even to the extent that is true it doesn’t change my argument at all.

Maybe I don't see the relevance of your question then.

Software developers are not negotiating fixed price contracts with their project managers every two weeks. Just how toxic such a situation would be should be obvious. Managers need to understand the context of the job and determine if they're satisfied with the productivity of their employees.

Agile is a development process not a contract pricing strategy. If anything proponents of "Agile" would be more hesitant to quote you a firm fixed price contract than "Waterfall" teams.

They don’t have to hire you every two weeks but they are paying for you and do have to decide how to allocate your time and plan various projects with interlocking dependencies. How can they do that without even a rough idea of how many people it takes for how long to accomplish anything? You are, in effect, still asking them to write you a blank check to accomplish something when they might want to change gears if apprised of how difficult it is.

> How can they do that without even a rough idea of how many people it takes for how long to accomplish anything?

This is not exclusive to scrum.

If you go way back up in this thread the reason given for Scrum being bad is it features estimation, which is useless because it's inaccurate, so telling me that systems other than Scrum feature estimation is not a rebuttal.

This is not really a discussion in good faith.

> the reason given for Scrum being bad is it features estimation

This seems like a strawman and not at all what I was picking up from further up the thread.

---

https://news.ycombinator.com/newsguidelines.html

> Please respond to the strongest plausible interpretation of what someone says, not a weaker one that's easier to criticize. Assume good faith.

Can you tell me how I was supposed to interpret “it is impossible to do good estimation” as a criticism of Scrum, then?

Research. We’re researching cures to cancer, nuclear fusion, space flight, etc. with no idea what the total cost of ownership will be.

Software dev can resemble research on a smaller scale. The more interesting or complex your requirements and environment, the closer it resembles research.

The original point of agile was to lean into this fact and get out of planning and predicting. Scrum culture has corrupted this goal.

Yeah it turns out if your object is having working software to use to make money you’re not that interested in the mysteries of theory.

Contractors charge you based upon the value they provide you, not their costs and labor. A time estimate is reasonable to expect, though.

Depends. Being billed by the hour is far from unheard of.

Is padding really cheating? I'd describe that as accounting for unforeseen setbacks and correcting for overenthusiastic optimism.

Padding estimates is fine. But not when you report actual worked time, which was what we did to make management happy with the burn down charts straightness.

If you don't report actual time for the task, the excercise is useless.

E.g. shift work time from a slower than estimated task to a faster, or "wait" if the task was done too quickly.

Imo, padding estimates is not cheating. It is just doing estimation right. Teams that do not pad estimates literally always underestimate amount of time needed.

> I wonder if the Scrum Master knew that in the end "get better" is "starting to cheat".

I was a trained Scrum Master and I knew this very well.

What's a trained "scrum master"? I thought the certs don't even have exams.

Totally with you. But since I'm currently preparing to get certified for Scrum, I'd like to point out that all those things you mentioned above aren't really part of Scrum at all...

All the estimation stuff is only for your team, not for outside consumption. If you release it and care what people say about it, then that I don't think that's the methodology's fault.

For the purposes of understanding the way people act, it is important to focus on what they believe to be the truth, not what the truth is.

Software development is incredibly opaque by default (heck, even we don't know how far along we are, most of the time) so anything that improves that will be perceived as improved productivity.

But even if it's not, sometimes progress reporting (however rough) is needed to synchronise with other parts of the organisation. It just needs to be put into a form that is useful (e.g. for agile projects "percent of plan delivered" is not a useful metric) and how it's going to be used should be explained to those producing it. Heck, optimal is if the people making software and the people they need to coordinate with can get together and jointly agree on what type of reporting is actually meaningful for both parties.

Almost always, we're discussing vanity metrics though.

Having predictability and observability is key to a business though, as higher level decision need to be made based on progress of the lower level teams.

In my experience, if the business has a higher level decision that depends on the progress of a lower level team, the only working approach is for the manager in charge of that decision to sit down with a person in the lower level team and discuss the state of things.

A metric compresses a very rich and nuanced opportunity into a false dichotomy.

Yes, predictability is better for business, but business also needs to accept that there are limits to the amount of predictability you can achieve in software development, and trying to force too much process is only going to predictably increase delivery time. In my experience, working with high level estimates which you keep updating from time to time is the best compromise.

There's no limit to predictability achievable in software development per se. You can have perfectly predictable software development -- if you know exactly what it is you're going to build.

The trouble is -- as with any product development -- we don't know exactly what we are going to build because it depends on fickle market sentiments, new technology, etc. That is what sets the upper limit on predictability, and that can be controlled by high level decisions. (Unfortunately, increased predictability usually means decreased profitability.)

> You can have perfectly predictable software development -- if you know exactly what it is you're going to build.

That's not enough - you can have pretty good predictability if you know exactly what you're going to build, and if you already built the same kind of thing with the same technologies/tools that you're going to use this time. Which is very often not the case: business very often wants new things that others don't already have, or the technologies/tools from previous times are now outdated (or believed so...).

We're saying the same thing. If we haven't built it (or something very like it) before, then we cannot possibly know exactly what it is we are building, because reality has a surprising amount of detail.

The only way to increase predictability is to pad estimates to the point of meaningless, and management won't accept that. Predictability creates crunch that creates bad choices that waste time and push delivery of working product out further.

> business also needs to accept that there are limits to the amount of predictability you can achieve in software development

Scrum is based around this idea, so adopting it (or adopting it better) should be a sign they understand it. If they start saying "oh points are basically time" then you're probably in trouble.

It’s sadly mostly a sign that they don’t understand it. Most scrum these days is bastardized.

But it has made the PA Consultings of this world a lot of money doing "agile transformations".

The problem is even scrum doesn't give the predictability and observability better than kanban. It's extremely hard to predict what we need to do in next 2 weeks and what we can achieve in next 2 weeks. At my current company, half, if not more, of the tickets come in mid-sprint.

So even though the current company is using scrum, in my team I treat it as kanban with story point limited, meaning I start with a certain amount of story points, then add / remove as the sprint is going.

I have seen a very predictable scrum, but the tradeoffs with productivity were comical. In this very large corporation, most developers could do most of the tasks in their 2 week sprints in 3 days of actual work. But they don't know if they are going to get 3 days of actual work, or some other team is going to keep master broken for a week. Therefore, your typical sprint involves mostly fictional standup updates, as to make sure that, when things go more than a little too well, the shameful levels of sandbagging aren't visible in jira or in git.

If you ask me, that level of predictability is a poor tradeoff, but hey, it's the same kind of organization that decides that SAFe scrum is a serious methodology.

SAfE is definitely a bad idea, but keeping master broken should be a "automated tests guard master" retro action.

These type of problems usually are not "actionable" with big legacy apps, poor coverage, etc.

Someone who's not a technical junior needs to make it very clear that breakages will keep happening and support staff will need increasing if no one has the time to figure out a test harness or similar for the software in question. If people are literally blocked because someone else has broken master then they should be working on a test harness right now, in fact. That would actually be useful.

If the sprint commitment gets bounced in favor of stuff coming in mid-sprint, they in itself might be useful information to someone who’s interested.

But the reality is you cannot hope for management to realize it, and for a good reason. If reprioritize a new feature can bring more revenue compared to original plan, or if a better flow is now available due to other team's completed task, or if a severe bug is discovered someday, it's just logical to reprioritize.

That’s not the point though. The point is to have an answer when someone asks why the original thing didn’t get done.

Things changing as a complete 180 mid sprint every single sprint doesn't mean Kanban is more suited as a process. It means your company is not using any process but rather is just a chaotic "who screamed the loudest most recently".

If you do Kanban right you have to have predictability through tasks of roughly equal size. If you will you can think of Kanban as Scrum where all tasks have to either be sized 2 or 3, else they don't make it into a sprint.

New items get added to the end of the backlog by default and stakeholders know when they can expect their request to be done because you know your velocity and queue length.

Putting every single request that comes in at the top of your Kanban backlog is orthogonal and bad.

Scrum is t really designed for an ops team. It's for product dev teams that need to organize and plan their work.

This is for product dev team though, not ops. Don't get me wrong, it's easy to plan works that take less than 7 work days or more than 14 work days, assuming the sprint is 10 work days.

Planning one that's near to 9-11 work days is the hard part.

I think I'd pick any team, not just software, telling me when something will exist over them saying they're more efficient. Efficient isn't even a metric I'd understand in most cases, e.g. a plumber telling me the house will be done as efficiently as possible but I won't know when any particular room will be unavailable so I can't plan around that info.

But isn't the problem exactly that, that oftentimes we cannot know in advance how long it will take to implement X?

I think your parent is trying to say that you won't hire the plumber that only tells you he will be efficient doing his job. But you will hire the plumber that tells you "if I don't find surprises behind the wall, this is a 2 hour job". And then he opens up the wall and finds old corroded iron piping he has to trace down to where it attaches to the main line and replace it all or else you won't get your new bathroom done at all.

And that job takes more than 2 hours. You could also have said "well if that's the case can you poke some exploratory holes in the drywall please so I can get a better estimate" (aka a "spike").

I've seen many people complain about reviews and retrospectives in those threads... But they don't seem like a bad thing to me. The problem is if the sprint is too short. But if the review and retro are done e.g. once every month or so, it can be a good way to see what the other teams have been doing and get an overall picture of your software. And the retro can be a good opportunity to talk about any problems that you encountered, and maybe trigger a solution, or at least just vent about it.

The problem is nothing comes out of it. We run retros and there are action items and they go into a black hole.

The higher ups do it to follow the process and not to fix the actual problems.

It gets tiring after a while of time wasting.

I do not want to talk about these problems again and again and again. I would like to see some improvements.

First few times it works as a psychohygiene, but then it just becomes annoying. So teams stops talking about actual deep issues on those meetings and they are are creating an illusion of happiness.

I don't see retrospectives being that much of a time-sink, it's a 30min/1hr meeting every 2 weeks. Even when I was on a kanban team they still had a fortnightly retrospective, it's useful to have a checkup occasionally.

Every time someone hates Scrum they always complain about 2 week sprints, which are an insane choice (should be 4 weeks), that shows they aren't doing Scrum, they are micromanaging with "Scrum" as the excuse.

Yes, I don't know where the 2 week sprint thing came from, but everyone uses it as a default. I've tried to get it to 3 or 4 weeks but always get resistance. The main reason I think is the business wants their features NOW.

Going longer than two weeks for a sprint just makes the lies happen at different place. There are approximately 0 teams that can accurately state all the work they will need to do four weeks in advance, even two is a stretch. Planning and retro per sprint become a burden though, on less than two week sprints.

I currently work at a place that does 1 week sprints. It's bad.

This is just doing scrum badly... management break it by insisting the metrics etc are used as a reporting mechanism, they just cannot get away from "intensive control mode". The metrics are supposed to be for the team to use internally.

But I do agree with the post - Kanban is way way better and you can include the scrum continuous improvement elements as well on a regular cycle.

> The metrics are supposed to be for the team to use internally.

You've already pointed out that this is basically unheard of but I'm struggling to think of situations where scrum metrics have provided benefits that outweighed the cost of taking, and exposing them.

My experience has been that most development teams intuitively recognise problems that might be revealed by these metrics. Is this not often the case?

This is where a decent scrum master or agile coach is valuable - fighting off the misuse of the metrics by external (to the team) management.

The thing is with metrics is that they are hard to argue with, whereas intuition is a debatable opinion. Perhaps not everyone in the team agrees. Perhaps it's about showing interfering management or dependent teams where the issues lie. Perhaps the team doesn't realise how long a particular stage in their workflow is holding things up - I mean they know that stage is a problem but have they realised it's actually their biggest blocker to finishing work?

Also depending on what you use to generate metrics - something like ActionableAgile that use Monte Carlo simulations against a few weeks worth of activities can show a team what their cycle time is, what items are in danger of blowing that and how long it's likely to finish just their current backlog (for example).

As you say, in their worst case they tell teams what they already know and then again that's the value of a good SM or AC - finding out why nothing is being done about it (whilst beating away interfering managers).

>The time taken to do team task estimation, update jira tickets and have retrospectives is time spent not programming.

Agree with everything _expect_ retros.

I think the value of the retros is proportional to how senior the team is and to how seasoned managers are. But for me retros are extremely high value _if_ you have:

- Teams that can look at problems head on and be civil addressing things without making it personal.

- Managers that have a 'clear roadblocks' mindset and have a service-providing mindset towards the team.

In this scenario you can really have high value retros, with continuous adjustments to workflow, processes, design, without continuously repeating the same mistakes or falling in the same pitfalls.

I found that retros tend to devolve into gripe sessions when the team isn't able to change its environment. Best to keep them focused on things they can actually change, and just to let them fix what they need instead of talking about it.

Also, after an initial stabilisation period, teams need fewer and fewer changes. Talking about it every sprint gets really pointless and takes time away from the things they're good at and they're motivated to do.

Proposing retro board be available 24/7 and retros be skipped if board is empty is good use of retro time. ;)

This sounds amazing.

But I do wonder if it just encourages people not to bring up real problems so that they can skip a meeting.

I think having the board up at all times is a great idea though. Just have to have some way to figure out "is it empty because things are fine or is it empty because no one cares anymore".

I've worked on a team that had amazing retros: lots of difficult discussions that resulted in change. We also made sure to discuss positive things too to ensure they keep happening. I think a lot of people miss this about retro.

I also worked on a team with terrible retros. The "good" column would always be extremely long and was only full of platitudes, nothing of actual substance that was brought forward into the next week. If anything difficult came up, someone would say, "Ok, let's book a meeting to talk about this later". It was an extreme misunderstanding of the value of retros. Though everyone else seemed to enjoy them so that's arguably valuable? I dunno.

Anyway, yes, lots has been said on this topic in the past. SCRUM is just Agile for stakeholders. There is the whole "SCRUM But" joke but I actually think a bunch of things in SCRUM are valuable BUT if something isn't working out, don't do it! I get the impression that lots of companies just do all the rituals "because SCRUM" and don't actually understand why they are doing them. Case in point, I was at a company that would always spend time story-pointing but no one ever looked at them. Not the teams and not the stakeholders.

> Especially if nobody can actually quantitatively measure the loss of efficiency.

Yet ironically they care and tout about their ability to measuring efficiency.

An easy way to boost efficiency: hide inefficiency out from view!

> most management teams would prefer their employees to be predictable and observable (ie, under control) than be efficient.

we're in this exact phase - sacrificing efficiency, team morale and independence to make the boards look cleaner to "raise the bar" per se.

We're a small efficient team in a massive org. Manager does a great job of not making stupid decisions, values people's time and is clear about the metrics the team gets evaluated on.

somewhere along the way he's, missed the reality that clean user stories and tasks, complete with points down to hours and acceptance criteria can still be completely f$#king wrong compared to the actual work that needs to be done. Not because the people are idiots but because thats how most software work is. You find out when you actually start working on it.

But if you mandate that you need a well cut plan before code gets written, you mostly get well written $hit.

We just embarked on this journey which I can mostly predict the outcome of.

sad, true.

But velocity of code written is not the same as velocity of value delivered.

In Scrum, estimation meetings usually result in follow-ups with stakeholders that can (and often do) radically change the stories themselves. Totally different code winds up getting delivered that increases actual value delivered, even if "lines of code written" slows.

That's the whole point of agile, to deliver value rather than code.

To be honest I have never seen this materialize. Usually you get some input from product management, the devs estimate it and then do it. I have never seen feedback from estimation to requirements.

Isn't that because the product manager is gathering requirements from other orgs/users?

> I have never seen feedback from estimation to requirements.

Perhaps you work with perfect pms! jokes aside, usually all it takes is an estimation of 8 or 13 and something changes real fast.

Yea, they tell you that they don't believe your estimates and stop asking for them before setting the deadline.

Then that's not agile.

The entire point of agile is that a PM can't do that. Large estimates force a PM to go back to stakeholders and revise the desired features to something that engineers have consensus that should be deliverable within the next sprint given their historical velocity.

If you're not doing that, then you're not even in any conversation about agile/scrum.

I'm almost afraid to ask but what unit of time does that "8 or 13" correspond to?

nah it's all good. it's just the "estimation value" which is technically arbitrary, but a common practice is in a 2-week sprint, 1x eng 1x sprint is ~5 points.

By saying 8pts the team is effectively saying it's probably a 2 sprint job and individual tickets are not supposed to be 2 sprints long meaning there's complexity that either needs to be broken apart or on the rarer case, team agrees the ticket is fine as-is then it'll take 2 sprints.

Anything 13 or greater is saying this ticket is so big we can't even begin to accurately estimate it - PM take it away from us! It's fun to see 21 or 34 pts... it's all a joke at that point.

Is that common? I thought it varied depending on the team, but usually that 1 pt is the shortest meaningful piece of work. Where I work now, 5 pt is not especially much. We have total story points delivered in a sprint around 120.

As mentioned, it's technically arbitrary, so you just need to get used to how your org does it. There's no right or wrong as long as your org agrees on the value of those points... sort of like bitcoin, ha ha (cries in BTC).

You didn't say how long a sprint is nor how large your team is, which makes me suspect that you don't handle measurements well in general.

Thanks. My teams have always estimated in hours (though at times these hours were called points) so I was a bit frightened to hear that an estimation of 13 hours would be considered bad! I guess if 13 means 26 person-days I get why people would be nervous – even I would suggest breaking it down into smaller pieces, if possible!

The main point of points is that they are not supposed to be equivalent to x amount of time.

They're supposed to represent a measure of complexity.

How much time that then takes depends on who does the work, the order in which tickets are implemented, how much distraction there is, luck (do you encounter any unforeseen problems), and so on.

They're then used to see how many issues will fit in a sprint, which is a measure of time. So everybody ends up treating them as representing time anyway...

That’s the theory but it doesn’t help managers so they still convert it back to time somehow.

Scrum was never for managers. If a manager is involved in predictions, it's not scrum. Scrum is about delivering the best you can each month, with client/management setting priorities and then appreciating what they get, instead of trying to steer the car from the boot.

Sure, I get what scrum is. "Scrum" in the real world isn't that though - at least 80% of the common case (check the other comments).

Theoretically it's arbitrary numbers. Then a factor specifically calculated for your team gets applied to it to turn it into hours or days.

But in reality it's ideal hours or ideal days.

The 8 and 13 come from the fibonacci sequence.

The differences I've observed between successful-and-unsuccessful, Scrum-and-Kanban have been dominated by people over process (yes, I know).

1. Does the team have the right people, with the right skill sets, wearing the right hats? (e.g. BAs or PMs doing those actual jobs)

2. Does the team have self-motivated, high-performance people?

I have yet to see any process that can overcome "No and no."

Large tech org's knee-jerk response to failures is to increase the formalism of their agile frameworks, but that's just a bandaid over gangrene.

If they think the solution to bad people is more process, they've already lost.

Barry Boehm sort of summarised this fairly well in Balancing Agile and Discipline, although I'm sure he would disagree with my characterisation of it:

- If you have unpredictably changing requirements, and a small-ish non-life-critical product to build, and a large fraction of good people on the team, you should use an agile process.

- If you have unchanging or predictably changing requirements, and a large fraction of not-so good people on the team, you should use a plan-driven process.

But what if you have unpredictably changing requirements and a large fraction of not-so good people on the team? No process can save you now.

Yeah, but scrum can overcome yes-yes by taking a bunch of skilled and motivated people and forcing them into an ineffective process. That is exactly what happened in my last team.

So those skilled and motivated people are estimating piecemeal tickets, too micromanaged to be able to fix actual issues they clearly see around them. It is forced helplessness You can't overcome bad process and scrum is a bad process.

Scrum advocates always end up blaming the people on team. Even if that exact same team was performant and scrum literally killed 70% of what was good in it.

Why do you need an explicit meeting for that? Just talk to each other as you uncover new information.

I did scrum once and we were literally always sprinting. The daily standup consisted of trying to think of excuses why the multiweek task wasn't completed (like they expected) and one dude who "zereo'd his inbox" every day.

That the iteration unit of scrum/agile is called a sprint is a huuuuge pet peeve of mine. Sprinting is definitionally an unsustainable pace.

I know, I know, it's just a label applied to the cycle time of the process but labels matter and I think it subtly and subconsciously poisons the whole thing. Especially when managers and PMs start making sprint cycles into hard deadlines.

>making sprint cycles into hard deadlines

One of the tipoffs that you are working under fake agile not real agile. I have the same problem with using the word "sprint" as well, but I think the true issue is that most orgs claim to be "agile" when they are actually doing some variety of waterfall with agile verbiage thrown in. The best test for fake agile is if you can't cancel the daily standup, even for a couple of days, via the retro.

who is "they" here?

I think one key issue here is that Scrum without Extreme Programming and rigorous iteration can become a shallow process. Often, products that don't undergo much iteration are broken into arbitrary two-week windows under the guise of iteration.

However, Scrum doesn't make much sense if you don't continuously iterate. Another symptom of this is people measuring velocity instead of value created. To properly implement Scrum, you actually need to measure the impact of the work completed in the past two weeks. Unfortunately, most teams don't do this, instead they focus on measuring velocity since it's easier and within their control. It's worth noting that it's completely fine for teams not to constantly iterate and change direction (including high-performing teams), and in those cases, Scrum simply isn't the best tool for the job imo.

I must admit that I personally prefer Kanban for almost all workloads.

If I am being generous, Scrum is for service teams, which can benefit from some of Scrum to temper unreasonable requests of senior stakeholders by providing a social contract on what is going to be worked on. More autonomous teams don't need it.

I’ve always considered Kanban’s lack of sprints to be well suited to service teams where individual requests are not naturally tied to each other and there is no benefit of delaying delivery into sprints.

Everybody wants their ticket serviced ASAP. Scrum helps manage that expectation. If a sprint is underway, new requests have to wait for the next sprint unless an agreement is reached to drop an existing ticket.

Cycle time on a board gets you that as well.

This provides more visibility and granularity, increasing confidence and satisfaction of customers.

How? How is pulling 10 points of work into every two week sprint "more visible" or "granular" than pulling anything as it comes up at a velocity of 5 points per week? I'm not even being contrarian, I truly don't understand how sprints could be better than knocking down a work queue.

Scrum informs the customer that their ticket will be processed in the next sprint or not. It gives visibility into the future. A Kanban backlog, which is unordered, only tells them if their ticket is being worked on now.

Putting a ticket into a sprint is the same as putting it into a queued stage of kanban for purposes of reporting, although the reported number will differ (“this sprint” vs mean cycle time with percentile bounds.) Both methods can have unordered backlogs where something can sit indefinitely.

(Many orgs are understandably nervous to automatically report a simple number as an estimate; in those cases, you could translate cycle time into a date range estimate so long as you’re not also expected to report “we’ve started” etc. since those won’t necessarily line up.)

It provides less granularity and visibility, but it provides regular, well-defined touch points.

OTOH, nothing stops you from having biweekly reviews with customers in Kanban, or delivery goals on the same cycle that guide decisions of which work items to pull in and whether to allocate more effort or defer ones that run into unexpected complexity. There’s no reason to (and plenty of reason not to) build a work-should-end and then new-work-items-should-start cycle around that; continuous flow makes more sense.

A kanban with periodic commitments to the next batch of tickets to be worked on is functionally scrum to me.

Even in Scrum, a Sprint Goal is not a batch of tickets, and for kanban the period re-evaluation of goals/priorities can be even less like that. And, of course, a review can be whatever there is to review.

What I am saying is that, insofar as cyclical touch points are a valuable customer-interaction feature of Scrum (and even when doing “proper Agile” with daily interaction with the customer as part of development, which is more an exception than the rule in most “Agile” places I’ve seen, the fact that “the customer” is usually an organization and the ideal daily interaction is individuals at the working level, not whole-team-to-whole-team level, those periodic touchpoints are useful) you can have them in Kanban while maintaining continuous flow as opposed to sprint-oriented flow in the development team.

What's the difference with prioritizing tickets in a Kanban queue?

In the end it's the work of the PM in both cases.

People with enough power in the org will insert their ticket in your precious sprint anyway.

If you're going to constantly groom your backlog to maintain priority order that is fine, but that's more work than maintaining a partial order. In fact, scrum is even less work than a partial sort; it just says "we're going to work on your ticket in sprint X" without being more specific.

It would be amusing but I've never been told to wait until the next sprint when contacting customer support.

Customer support is one kind of a service. I was thinking of something like a platform team, which creates complex tooling for other teams. I don't know if you were just joking, but I thought I'd clarify.

> Every team I've worked on that has switched from Kanban to Scrum has slowed down and never regained the previous velocity. Further, many of the promised benefits of Scrum (things like better insight and predictability about delivery rates) never materialized.

This has been my experience. I've seen more than once management teams happier with numbers and estimates that weren't met than actually getting software out quicker at an unanticipated rate.

They'd rather have estimates that they could yell about than revenue generating software through (presumably) happy customers. <shrug>

I have the software engineering uncertainty principle. The more you try to measure and estimate and predict software velocity and delivery the more you slow it down. I think this is probably true of any largely creative and problem solving task, but compounds because most of the uncertainty derives from dependencies requiring those dependencies to likewise measure and slow down. The more complex and interconnected an effort is the more scrum hurts it.

This sounds a lot like the coastline paradox. The more precisely you try to measure a coastline, the harder it gets due to its fractal nature.

Software estimation, similarly, is fractal in nature - you can always drill down deeper to measure but it gets increasingly complex and at some point you have to ask, is it worth it being "accurate"? Or do we just do it? Org charts require the former while developers desire the latter.

I think that analogy is broken. Measuring a coastline more precisely doesn't just become more complex (measuring precisely often does), but actually increases the measured length towards infinity.

Unless you wanted to say that the same is true for software estimation, e.g. due to the measurements taking up more and more time.

Yes, I meant the time taken estimating. The act of measuring estimated hours becomes more complex because the closer you look, the more you see, you could do it forever and have to stop somewhere.

But maybe instead of infinity, it's better to say estimation can take longer than the work itself which has been the case a few times for me.

As a Product Owner I am biased, but sympathetic. The ceremonies and oversight certainly can slow down velocity. But there are many benefits, and they are not immediately apparent to developers.

Alignment is so important, and it's rare that I've found a team not using scrum which is working harmoniously. In reality, some members of the team aren't pulling their weight and it's causing animosity. Or they're working at odds and not communicating the pieces they're developing. A huge one for me is stakeholder alignment. Without scrum it's awfully common for developers to build things the stakeholder doesn't want. Scrum forces regular check-in and demonstration which otherwise rarely happens organically.

A big part of scrum is accountability. As I touched on, when people aren't pulling their weight, it hurts everyone. Unfortunately developers are rarely extroverts, and they often don't have the skills or desire to have tough conversations with each other. Sometimes it's just agreeing on what they find acceptable behaviour and work. Sometimes it's adapting to different ways of work, or neurological issues with a team member. You might be surprised to learn that a lot of developers are on the spectrum. Scrum forces these conversations to the fore and provides a tested framework for conflict resolution.

We also gain transparency. This is really important so that all the other supporting business functions can operate. Sales can communicate with customers about important updates and new features. Marketing can plan campaigns. Support can prepare. Finance can ensure adequate budget for new infrastructure and FTEs. Sure it's annoying, but this planning is essential for a business. It just doesn't happen organically. Scrum forces developers to work to some kind of schedule, offering short-term (but flexible) estimates on what can be delivered, when.

In a perfect world, none of this is a problem, and all of it happens organically. I've just never seen that happen. The sacrifice in velocity is worth the increase in value output to the stakeholders.

You make it all sound like a factory and blame developers for going rogue.

That’s not how it works. It’s as though developers are dumb and can only execute if you tell them to do exactly as needed. Rather where’s the leadership and direction? Perhaps that’s not clear or the developers don’t even agree with what’s going on. You statement is so 1-sided.

If someone is not performing you shouldn’t need scrum to work that out otherwise you have bigger problems.

I’d argue alignment is useless as most of the time developers are told to implement useless features. Perhaps with some guidance and direction what the developers come up with is better than product.

It’s sad but product is like a theory machine that’s often impractical.

So what would you prefer? Developers without scrum delivering in 4 months or with scrum and taking a year? Even if they do go off for a few months on their own it’s more than worth it.

The problems aren’t accountability or alignment. If people aren’t following a plan, that is if there is 1 then it’s a leadership problem.

It's not about blame. Developers are paid to develop. They're not paid to care about the interlocking parts, so many of them don't. It's not an indictment. It's just what it is. They have a different set of skills.

> Rather where’s the leadership and direction?

We're right here, implementing scrum for the reasons I listed.

> If someone is not performing you shouldn’t need scrum to work that out otherwise you have bigger problems.

I have found that poor performance is often not because an employee is "bad." It's because the team dynamic is not working. Maybe their skills are poorly utilised. Maybe the team isn't make accommodations for their neurodivergence. Maybe they don't understand how to integrate well into the team. Maybe they don't feel confident to bother the senior devs, and maybe the senior devs have told them to fuck off. I've seen all of this and more.

> I’d argue alignment is useless as most of the time developers are told to implement useless features.

Sure, there's no point in any of the work you do if you're being told to develop things that no one wants. My baseline assumption here is that the business has need of your work. If it doesn't, you should brush up no your CV.

> So what would you prefer? Developers without scrum delivering in 4 months or with scrum and taking a year?

If the four months gives me something no one wants, I'll take the year.

> The problems aren’t accountability or alignment. If people aren’t following a plan, that is if there is 1 then it’s a leadership problem.

That's the whole discussion: how best to follow the plan. I don't think it's as easy as criticising developers for "not following the plan" if we don't provide a strong foundation in which to do so. Cue scrum.

> It's not about blame. Developers are paid to develop. They're not paid to care about the interlocking parts, so many of them don't. It's not an indictment. It's just what it is. They have a different set of skills.

That's the problem. That's not how it used to work and we've lost that. Developers are a lot more than develop. If you really think you need to pay someone 200-500k in better places to just "develop"; there's the problem.

Software exceeded because developers innovated and did a lot more than that. Shrinking them to just robots is where the problem starts and you can hire copy/paste "developers" for a lot less.

> I have found that poor performance is often not because an employee is "bad."

My point being and as you've actually explained - it still has nothing to do with scrum.

> Sure, there's no point in any of the work you do if you're being told to develop things that no one wants. My baseline assumption here is that the business has need of your work. If it doesn't, you should brush up no your CV.

The business has need for work - it doesn't make it a useful feature. What the client wants and what gets trickled down after 10 layers is a different story.

> If the four months gives me something no one wants, I'll take the year.

How do you keep concluding no 1 wants it?

> That's the whole discussion: how best to follow the plan. I don't think it's as easy as criticising developers for "not following the plan" if we don't provide a strong foundation in which to do so. Cue scrum.

Point being scrum doesn't provide this foundation. Read the comments. You lose long term planning and try to squeeze everything in 2 week compartments = find quick wins and hack everything so it fits. It's a disaster. What happens as other have explained is the estimates get padded. People do less work. People are unhappy and you're just left with the illusion of "success".

US and in particular SF didn't succeed on this but on elevating developers to innovate. Please don't kill it.

Great comment. If you are enforcing due dates, you are doing it wrong, and stacking up debt and creating bad quality. It's about transparency. As a developer I never loved transparency, because being imperfect, I would sometimes make mistakes. As a manager, I cannot see how anything can be done correctly without transparency. It's not about the developer, it's about the quality analyst, the dev/ops, the UX designer, the customer, the documentation, the salesperson, the stakeholder, the investor, the business analyst, the quality analyst, the configuration analyst, etc.

Franky, scrum teams I worked in were pretty much worst in all the points you list, except higher management feeling of control. Especially in alignment between developers point. The cooperation is never really good in scrum, it is sorta kinda passable at best. Interpersonal relationship are either horrible or passive to non existence.

> Unfortunately developers are rarely extroverts, and they often don't have the skills or desire to have tough conversations with each other.

I mean, what are you exactly talking about here? Because developers do criticize each other all the time, both in code review and outside of it. If they have trust, they talk plenty. If you do not see developers communicating, it is because of how you lead a process.

> Sometimes it's adapting to different ways of work, or neurological issues with a team member

Scrum is so inflexible, that it literally prevents accommodations for issues like this. And that is not even speaking about the fact literally this should be job of people management. This is literally what leaderships should do, because they have actual power to change the things.

> I mean, what are you exactly talking about here? Because developers do criticise each other all the time, both in code review and outside of it. If they have trust, they talk plenty. If you do not see developers communicating, it is because of how you lead a process.

It's not just communication which is needed. It's effective communication. For example, criticism without structure and consideration comes across as unkind and destructive. This is the piece which I rarely see working well without a framework. It doesn't have to be scrum. I just see scrum solving this and many other problems really well.

> Scrum is so inflexible, that it literally prevents accommodations for issues like this. And that is not even speaking about the fact literally this should be job of people management. This is literally what leaderships should do, because they have actual power to change the things.

Scrum doesn't have to be inflexible. It should be tailored to the needs of the team. The catch is that changes should be agreed by all, rather than one member going rogue. "Rockstars" hate scrum.

As for the "job of people management," if you're punting the responsibility of collaborative team dynamic to your leaders, be prepared for them to lead you. With scrum.

> It's not just communication which is needed. It's effective communication. For example, criticism without structure and consideration comes across as unkind and destructive. This is the piece which I rarely see working well without a framework. It doesn't have to be scrum. I just see scrum solving this and many other problems really well.

Scrum does not help with effective communication at all. Its only tools for feedback are code review and retrospective. Its tools for teaching are code review, demos and planning sessions. There is literally no place in it for private feedback or some kind of learning plan or a weaker developer having tasks adjusted so that he can catch up (getting simpler ones, or only frontend ones till he learns that), literally nothing. And with public feedback, it provides zero guidance on how to do it anyway.

Instead, scrum prevents effective, safe and compassionate communication. It provides rituals, that is it.

> The catch is that changes should be agreed by all, rather than one member going rogue. "Rockstars" hate scrum.

Neither of these is true. Scrum is inflexible and the moment you change the process, you are not doing scrum and you will be forced to go back to scrum. Second, you will need to specify what you mean by rock starts. If you mean toxic personalities, they do well in scrum. If you like to control other people, scrum provides quite a lot of opportunity for that.

What it does not provide is opportunity of people to use full extend of their capabilities. People who are able to perform well and able to get along with others, you will definitely do better in processes that allows you to perform and get along with others. If rocks start here means a positive, a capable non toxic person with good social skills, yeah, those tend not to like scrum.

> There is literally no place in it for private feedback or some kind of learning plan or a weaker developer having tasks adjusted so that he can catch up (getting simpler ones, or only frontend ones till he learns that), literally nothing... Instead, scrum prevents effective, safe and compassionate communication. It provides rituals, that is it.

Sure, scrum is a team tool, not a personal development plan tool. The latter is best handled with one's manager. Note that I am not claiming scrum is an everything tool. It won't solve world hunger either. How on earth does scrum "prevent effective, safe, and compassionate communication"?? It just sounds like you're throwing accusations at the wall now to see what sticks.

It sounds like we've had vastly different experiences. I'm sorry to hear yours have been so unpleasant.

You started by saying that scrum helps team alignment, communication and dealing with weaker developers. That introverted developers need something like that to communicate, because they are avoiding tough discussions. You was literally talking about developers.

When I said that developers do tough part regularly in code reviews, you said that effective communication is more and scrum provides that more.

When I said that scrum does not provide "the more" and makes it harder, you said that scrum actually should not do any of that, manager should. And oh, scrum has scrum master and no manager, so no I guess no one is doing it.

-------

In a non scrum process, seniors do frequently take actively care about Juniors or own development. They can do it in systematic manner. They can actually work together on a lighly larger units of work with them. They can split work in a way that makes sense between the actual two people in question rather then based on what someone else prescribed.

Yes but raw velocity is not the only thing that matters. For some projects it is, but for many the accountability of Scrum + the grouping helps with dependency management across an organization.

Scrum does not provide accountability. It creates the illusion of accountability while creating artificial touch points that effectively become the only time anyone thinks about what's going on. At least that's how I've seen it operate in almost every instance I've ever worked with it.

Of course, the counter to that is that we're not doing scrum right. The question in my mind then is if I haven't seen a single team do Scrum correctly there's something wrong that makes the methodology so difficult it can't be applied ...

> It creates the illusion of accountability while creating artificial touch points

I'm surprised at the conclusion because this statement can be said of any framework. It's up to the people to actually make it accountable. Doesn't matter if it's Scrum/Kanban or another one. If your org treats accountability as "an illusion" then it's doomed to fail regardless.

> The question in my mind then is if I haven't seen a single team do Scrum correctly there's something wrong that makes the methodology so difficult it can't be applied ...

This I 100% agree with. I've come to look at these frameworks (kanban, scrum etc) as I look at the Bible... no church gets it right and never will. It's not possible.

> This I 100% agree with. I've come to look at these frameworks (kanban, scrum etc) as I look at the Bible... no church gets it right and never will. It's not possible.

It's interesting that you use this analogy. I've always compared Scrum to Communism or faith healing: If it doesn't work for you, you either didn't implement it correctly or you didn't believe in it enough.

Right, exactly. In other words, the claims it makes are unfalsifiable, because if they don't come to fruition then clearly there must be some other factor in play.

> If your org treats accountability as "an illusion" then it's doomed to fail regardless.

That was a reply to "...but for many the accountability of Scrum..." in the parent comment. There's an idea that Scrum creates accountability by making it possible to measure how well a team is meeting their commitments. It really doesn't. The metrics that Scrum exposes are little more than semi-random numbers. You're asked as a team to "commit to completing" some mostly arbitrary total of these numbers that has been determined to be your teams "capacity".

The entire premise of this kind of estimation is fallacious on face. It completely ignores the skill level, overall capabilities, and specializations of your developers and effectively equates them to an common minimum of mediocrity. Worse, it pre-supposes that your team fully understands all of the places that a particular task can go sideways which is almost never the case.

About the only way I can see it working is a situation where you know exactly what needs to be done, step by step, from or near the very beginning of a project. Otherwise, all you're doing with Scrum is forcing the team to make decisions on a Sprinted cadence rather than at natural break points along the completion of a project. This creates artificial delays, particularly when other teams are also working on sprinted cadences because you're likely to be requesting things that won't make it into some other teams sprint. Creating at least a sprint long delay before your team can complete their work, and well, breaking your sprint goals, etc..

Sigh ... Hence the accountability and predictability that's supposed to come out of Scrum is illusory at best and usually self deception.

I understand better, thanks for the explanation.

To me, what you're looking for doesn't exist. Ignoring Scrum, the question is "how do we know our engineers are effective?"

You know Scrum's attempt to answer that. Regardless, no matter what methodology you pick - it's bad. But, you have to answer it. Otherwise engineering is a black box without a way to peer in.

I know many engineers would prefer it that way, but that's just not realistic.

In the end the whole thing has to be an agreement between people.

> Of course, the counter to that is that we're not doing scrum right.

That’s almost always the excuse in my experience. It’s not that it doesn’t work, it’s just no one has ever done it correctly.

It’s not that no 1 has done it correctly. It’s that no 1 wants to even do scrum. Most management do pretend scrum. It’s like hype driven development. You just get on the train without caring where it goes.

Thanks for confirming that Scrum is really for flogging.

I've seen Kanban work well on smaller scales, and Scrum work well on larger scales.

I cannot for the life of me work in the churn and development pace of a Scrum team, so Kanban (and the culture around it) is best fit for me.

I think it also depends upon the type and culture of people working in the team as well. Some teams work really, really well with the predictable cadence, others do not.

It's a case by case kind of situation, I think.

That said I highly prefer Kanban personally for an number of reasons.

The commitment to sprints was literally the first thing that got dropped in our company. It's so nonsensical to create completely arbitrary deadlines without any real urgency.

We now have long sprints (~1 months) for reviews and retrospectives. Which are usually well received. You get to see what all the other teams have been doing, and you also get a formal chance to talk about any problems.

Sprints and timeboxing more generally is not about enforcing deadlines. That's such a common misconception and I wish it would die.

Timeboxing is about committing only a small amount of time and money at a time, so you can choose to double down on winners and stop investing in losers, rather than suddenly finding yourself having sunk 3 months of time into something that turns out wasn't that good after all.

The question is not "How much can we definitely complete in two weeks?"; it's "What things are promising enough that we are willing to dump two weeks into them, with no promise of ever making a profit?"

If one month counts as a small amount of time and money for your organisation, then you're doing it right!

It's not a misconception when it's what many organizations are actually doing. Any that implement SAFe, for instance.

“The process is the punishment”

Is Scrum supposed to increase velocity? I always view these processes as a consistency enhancer. "What can we accurately promise 6 months out" vs. "how can we get the most done possible?" This is important because the big risk is that you do 80% of 10 projects, rather than 100% of 1 project, especially if you have a team and not just a couple of individuals.

Lots of stuff pushes organizations in the direction of doing 80% of 10 separate projects, and it's a killer. This is good reading in this domain: https://apenwarr.ca/log/20171213

The only way better insight would happen is if the devs behaved like product managers/owners. We don’t want it.

I can actually see predictability improving, but mostly because we will ship whatever at the end of the sprint and let any issues come back as bugs later. We always ship on time at one Scrum job, but the quality is very low.

> Every team I've worked on that has switched from Kanban to Scrum has slowed down and never regained the previous velocity.

As an engineer on a team using scrum, this is my favorite part.

What you're describing has been my experience as well across multiple teams and workplaces.

Reply on news.ycombinator.com