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.
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".
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.
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?
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.
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.
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.
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.
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.
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.
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.
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".
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.
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.
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.
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.
>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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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).
> 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.
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.
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.
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.
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.
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 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.
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").
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.
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.
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.
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.
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).
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...
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
> 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.
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.
> 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.
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.
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!
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.
The underlying triangle here: Out of time, scope, and quality, you can pick two to specify but you can't constrain all three.
Scrum specifies fixed time and quality ("definition of done"), with scope as the flexible variable, as tasks get pushed out of each sprint.
Kanban specifies fixed scope and quality, letting time be the floating factor for each task.
Waterfall specifies fixed time and scope, with the inevitable result that quality has to give way.
There are some applications that Scrum does fit better than Kanban, notably anything tied to a real world calendar, say a scheduled live event or a school year or holiday or other seasonal concern. But yes, most businesses don't need to be time-boxed with Scrum anywhere near as much as they think they do, particularly given how much of that time is always consumed by organizational friction around the time-boxing negotiations.
(What happens if you do try to constrain and specify all three? We call that a death march. Actually, time invisibly flexes as workers cram in effort at a higher pace, until they burn out and then you're back to quality implicitly or time explicitly giving way unless you reduce scope.)
> Waterfall specifies fixed time and scope, with the inevitable result that quality has to give way.
Not really. I’ve worked on waterfall projects and they generally produced much much better quality than any scrum team I’ve been on ever. The dirty little secret is it’s faster too but if you have incompetent management/engineers the risk of not shipping anything at all goes up dramatically
I think often the supposed failings of waterfall is actually the failings of large scale software development, which crop up even with agile methods (especially with stuff like SAFe).
My experience with small-scale waterfall is one of getting essentially a spreadsheet of requirements, implementing to spec, fixing a small number of bugs during QA, and then going into production on time and with exceptional quality.
There's a project I did that went from zero lines of code to production in two months, that had literally bugs discovered in a decade of operation. Made entirely possible through waterfall-style development. If you know exactly what to build, development goes fast. There is not a chance in the world that would have happened if we'd been discovering new requirements along the way.
That said, it also puts a lot more demand on well thought out requirements. The people who put together the specs were world class, smart, professional and solid engineers. Extremely particular where it mattered yet with very little bike shedding.
My experience is that developing against fixed requirements is fast and produces exceptionally high quality code. So many bugs and so much technical debt is from having to rewrite the same thing over and over because the requirements aren't set when development starts.
>My experience is that developing against fixed requirements is fast and produces exceptionally high quality code. So many bugs and so much technical debt is from having to rewrite the same thing over and over because the requirements aren't set when development starts.
I think that's why Agile was invented: for situations where requirements are not fixed. If you have fixed requirements, I don't see why you'd need Agile development in the first place, though some parts of it might be useful for just keeping everyone on track.
In a recent job, we used Scrum and it generally worked well, but we didn't have the luxury of fixed requirements. The customer needed new features on a regular basis (features which they could not have foreseen the need for beforehand), and we'd regularly give them deliveries of the version of the product we had, which they'd immediately put into use. A waterfall model would never have worked there.
I've had similar experiences with waterfall; projects running on time, over multiple years, on which the end users never reported so much as a single bug.
As you say, it demands really good requirements, which can only come from high-quality customers. Most customers are not high quality. They are low quality. They are bad. They don't know what they want and don't know how to express themselves. As you suggest, a really good requirements person can tease these details out of them, but in my experience a great many companies don't even realise how bad and incompetent a lot of their own customers are.
> Not really. I’ve worked on waterfall projects and they generally produced much much better quality than any scrum team I’ve been on ever. The dirty little secret is it’s faster too but if you have incompetent management/engineers the risk of not shipping anything at all goes up dramatically
This is WILDLY different to my experiences. Waterfall projects always drag out months and even years past their expected delivery. The requirements documents become bloated wish lists. Prioritisation is impossible because no one will accept cutting even the really fluffy stuff. Waterfall requires dedicated project managers who spend their whole day arguing with everyone. I admit that the quality is often higher, but that should be expected when it takes three times longer to deliver. Scrum/Agile forces teams to focus on the core value proposition, and not all the nice-to-haves. You believe this is only an issue with incompetent management, but if so, I've never seen what you consider to be competent management.
I think the better solution here is not to buy into any framework as though it's a religion. Waterfall dominated projects for decades, and it has lots of issues. Agile is dominating current ways of work, and it has lots of issues. We should be using the right tool for the job, and even then, only the parts which make sense for our product and team and culture.
My pet hate is that Scrum has somehow been dubbed as Agile, when a rigid system of meetings and planning techniques is the antithesis of agile development, which was conceived of to push back on exactly that.
I've only ever seen waterfall work with a large enough team and we'll understood problem space. That said, the two teams I was on where both of those existed it was much more productive that even the best run scrum teams I've been on.
Actually the most effective strategy I've seen is Kanban, but with a fixed release deadline.
Inevitably there are some essential tickets and some nice-to-have tickets.
For the nice-to-haves it's a case of progress or die.
Think of it as time constrained Kanban with semi-fixed scope.
The dropped tickets may carry over to a later release (if there is one), or just die forever (make it easy to cull bullshit).
P.S. From this perspective, the first thing to die is the time wasting sprint rituals that Scrum layers on top of Kanban.
No that's not scrum, as any "scrum master" will tell you ... scrum imposes it's own artificial cadence.
This is kanban ... just culminating in a release event anything from weeks to months in the future (driven by time factors independent of dev management i.e. actually having to produce something as a business). I mean nobody can seriously be proposing no time bound on kanban (please clear the board this decade?)
If you're behind schedule pausing for a ridiculous high school level show and tell will only delay you more ... and if you're ahead of schedule, just keep doing what you're doing right.
What kanban provides is visibility, how much you're getting done. Scrum sacrifices momentum for theatre.
Yes, a professor I had called it "cinnamon bun," and it's been a thing since at least the early 90s. Waterfall doesn't have to be end-to-end.
In my experience it's better to have more than a 2 week cycle though. I've seen it at 3 months and 6 months, both worked fine. Even if waterfall is end-to-end, it should still be broken up into phases for sanity checks.
Beware blanket statements! I work with sound in games and have multiple times tried to do Kanban, both from an internal team and an outsourcing team, because of basically the same reasons mentioned in the article - it's agile and task based, and seems like a good fit to be a "factory" for sound assets.
However games are iterative by several orders of magnitude more than traditional tech (I've also been CTO at a more traditional design/consulting firm) and constantly evolving and audio team, both internal or external, end up tightly embedded over the course of 2-3 year long projects, and Kanban ALWAYS breaks down because the edges of tasks are fuzzier than you expect.
Scrum (real scrum, not the surface level dogmatism that passes for it in many places) does work better in this situation. I find myself saying this often "The best tool is the simplest one that does what you need it to". I really do prefer Kanban! It's far simpler. For projects that have clear needs and stakeholders it's great. For "factory" type set ups that provide tools to other internal stakeholders it also works great. But for places where the technical requirements are fuzzy the added complexity of Scrum is helpful, since it focuses on OUTCOMES rather than MEANS/tasks.
Don't be afraid to try different approaches for different sprints/releases and tweak formulas. You can normalize estimation by keeping it consistent while also changing methodologies. But just because Scrum is overused and misunderstood doesn't mean it's useless.
This is the real comment here. I've worked in all three, scrum, kanban and waterfall, and I know from personal experience that they all have their shortcomings and it really depends on what you are trying to deliver and how well your team responds. We've moved from waterfall to scrum to kanban and back and the one standout is clarity of minimum requirements and boy is that hard to get from the relevant people. If you don't get that then stick with waterfall because then no one is responsible!
Yeah, I didn't mention in my earlier comment but I've found that scrum does work better with larger teams because it adds ownership into the process. You can define ownership with Kanban (or any process) but it's not integrated into how it operates without some hacking.
edit I sometimes find myself in the position of apologist for Scrum, which is weird because I'm not that crazy about it, I'd almost always prefer to use something less heavyweight. But people are so quick to throw out the baby with the bathwater - there are a lot of great concepts in scrum, and it's quite interesting to see how all the parts interact when it's actually working.
I think they mean it from a softer perspective - Scrum encourages more time ensuring all the team and tasks are clearly directed towards an outcome for that sprint.
Just putting outcomes as cards on a kanban board will not have that same effect in all instances, as it's more about the soft points of engagement and teamwork driving towards that common goal.
Thank you for your answer. Actually it’s perfectly doable, just put an outcome swimlane in your kanban, with a rule that says there can only be one card in the « doing » column.
I’m starting to realize that most people don’t know how customizable Kanban is. You can put as many columns and swimlanes as you want, and then implement constraints in the system with rules around how cards move on the board.
I actually do agree with you that kanban is very flexible - and I have used plenty of additional swimlanes - for my original example we tried using "concepting" stage, multiple iterations, "mix" swimlanes for individual sound effects. These aren't "outcome" swimlanes, because I found that tracking an outcome becomes overly complex tracking subdependencies of the tasks of that outcome. At that point, Scrum becomes better at handling that complexity.
Which is why I always come back to "the best tool is the simplest that meets your need" - starting at Kanban is good, then you can add complexity. If that complexity starts to "outgrow" kanban (though it's a bit like comparing apples and oranges - it's not like scrum is just a more complex kanban, so I'm oversimplifying here) then you want to consider switching to another technique.
It's great that kanban has worked for all your projects and you haven't needed to use scrum!
Thank you for explaining, and it’s great that Scrum is working for you and your team! However, I have to admit I still don’t get it. How is Scrum better at handling outcomes? Are you talking about the sprint goal rallying all the team around a specific outcome, within a specific time frame? I gotta admit I am very suspicious of this way of working because it gets unsustainable pretty quickly, but I would like you to elaborate if you have the time.
Yeah scrum, or any process really, sucks when it's used like spyware. I've been lucky enough to be part of teams in companies that don't treat their employees like the enemy. So doing scrum the every day work aspect happens at the local level. What I like about scrum is being able to talk to other teams about higher level things while keeping the day to day tasks just within our team. It's similar in programming to the TDD approach of making a public interface and testing against the functionality, while the implementation details are kept internally.
Doing reports I find people care less about the day-to-day work and more about when it gets done, and this is where scrum in theory works well but breaks down in reality. In practice is estimation works when team members are kept consistent, because over time you can track historically "t-shirt size" complexity of task as estimated by the team translates to "x number of man-hours". However in game design we get a lot of major team shakeups pretty regularly with teams changing across different milestones. It's hard to fight against the instinct of "Oh this thing needs our a-team players for this release"
I appreciate the article but I worry that Scrum implemented too rigidly is the reason why it gets a bad reputation.
A lot of the arguments being made are really difficult to generalize and say "this works for every org!". One example:
> When that happens, instead of designing features by committee, which demands a significant amount of back-and-forth discussions, decisions happen locally, and thus are easier to make.
This works really well when the engineers themselves have all the knowledge+ability to tackle the problem. Smaller startups are perfect! and teams that are pure technical. But once a key portion of the requirements lives outside the team, this is no longer effective because then you're building without that feedback.
The danger is trying to measure things purely on developer velocity. I'm not saying kanban is wrong or scrum is wrong, just do what's best for your org by building what's important to your business.
"This works really well when the engineers themselves have all the knowledge+ability to tackle the problem."
This reminds me of a similar situation almost a decade ago where someone watched a talk on how GitHub uses GitHub to build GitHub. The people who watched the talk all tried to convince me that we should adopt similar process that puts less emphasis on PMs. However, this worked for GitHub because their engineers had such a strong similarity to their customer base. For us that wasn't the case at all and we typically needed PMs to have lots of customer conversations and explain to us how customers used our product because we were building Enterprise software for people whose day-to-day we didn't understand easily.
Scrum has prescriptive method of who is supposed to gather requirements, the meeting for requirements gathering, estimation for "understanding of requirements", and demo... well for demo'ing the feature back to "the powers that be".
Kanban doesn't prescribe any stakeholder methodology. It's not that it's not important, it's just up to the organization.
This is definitely a point of contention in Scrum because "oh this is so slow", "there are too many stakeholders", "why do we have to do it this way".
I'm at the belief - some way is better than no way. If you don't like Scrum, cool! Go build your own, but if you don't mind it, Scrum is good-enough^tm.
> This demand for estimations leads to unproductive and unnecessary estimation meetings. These meetings are unproductive because they cause developers to spend time debating whether something is worth two or three story points instead of actually writing code. They’re also unnecessary because if you feed the system with more work as soon as software comes out, estimations don’t matter.
Only if all tasks are of equal priority, which is rare. Otherwise you need some (very basic) cost estimation in order to prioritize.
> Retrospective sessions are also fundamental for a team to continuously improve the way it works. The problem with these sessions in Scrum is that they either happen too early or late. Although it’s good for teams to discuss their practices and look for ways to improve them, it may not be necessary to hold a retrospective session if everything is going fantastically well. Conversely, it may be harmful to wait for two or more weeks to discuss systemic problems impacting the current pieces of work or the overall goal the team is working towards.
> In Kanban, there’s nothing preventing teams from scheduling regular meetings. Yet, teams have the flexibility to schedule meetings whenever they’re necessary.
But unfortunately this means they also have the flexibility to not hold a meeting when it's necessary.
I don't think this article is exactly wrong - Scrum is to a certain extent a crutch, just as any process is to a certain extent a crutch - but I think it overestimates the average manager/team. In my experience teams that pick Kanban over Scrum tend to have issues with stalled, overly-large, and poorly-prioritised tasks (e.g. an undesirable task can sit indefinitely in the "ready for work" column which is usually not what you want), too little process refinement (in particular, retrospectives end up being rare) and take too long to recognise issues.
Scrum is prescriptive and restrictive, but it's like that because it works. After all, if your team was perfect you wouldn't need Kanban either. Just do the right thing and don't do the wrong thing bro.
> They’re also unnecessary because if you feed the system with more work as soon as software comes out, estimations don’t matter.
The question is: estimations don't matter to who? As much as I'd like a constant stream of quality features to be good enough, in reality senior managers and clients want to know what they're getting for their money, and when they'll get it (at least roughly). If your software is doing something important, it's likely that people will be depending on it and when a new feature ships can have a significant impact on how they work, and in turn, what they can deliver.
> As much as I'd like a constant stream of quality features to be good enough, in reality senior managers and clients want to know what they're getting for their money, and when they'll get it (at least roughly).
IME most of the time they need to get over it. The reality is that estimating in that kind of detail would be expensive and not worth the effort.
However what they do reasonably need is the ability to prioritise feature A over feature B and they need a vague comparison of costs in order to do that (like, is feature B going to be 3x as much work as feature A?). Scrum provides that at minimum cost.
It depends what you are working on, how you ship and how three rest of the company works. I work on Enterprise software that's not SaaS. We ship every 9-12 months. If we do it more frequently it just annoys our slow-moving costumers and increases our support burden because there are now more versions in support that might need patches. Our sales and marketing teams need to know when we ship. Sometimes costumers mighy need to adjust their own release schedules to when our next release is out. If one team needs longer for a critical feature, we need to know as early as possible so that we can discuss cutting scope, pushing the release out, cutting the feature, etc.
Yep, or if you are working on a project to build a control system for a new factory which is going live in 18 months, it's pretty reasonable for your management team to want to know that you have confidence you can build the control system within a year.
If not, they will probably want to cut the scope or put other risk mitigation in place.
Thanks. I found it annoying that the author never says what kanban is. By leading the title with scrum, you can argue that it’s for those familiar with it. But then the article neglects to describe the alternative it claims is better.
It’s akin to saying, “You don’t need yoga; just do twiddlebop right,” and never saying what twiddlebop is.
It’s also rife with meaningless declarations, like the one about “pushing decisions to the edge of the team.” WTF is that supposed to mean?
"When applied correctly, good project management ends up better for everyone."
With good project management you can make any process work, be it waterfall, scrum, kanban or others. All dysfunction comes from people perpetuating processes that don't work. That's what agile was about originally.
> All dysfunction comes from people perpetuating processes that don't work. That's what agile was about originally.
Agile is far worse than anything I experienced earlier. It was pushed as some sort of dogma where you are a cranky non-teamplayer person for arguing it is a bad idea. A counter-revolutionary blocking utopia.
Giving non-programmers insight into every small tasks is a big mistake.
I hope you are correct. Finding companies with good project management has so far been quite elusive though. In my career I've had about eight project managers so far, six of which were in a scrum environment. Without exception the scrum PMs have not been effective at all.
I don't doubt that effective scrum management is theoretically possible, but based on personal experience and also by reading through the rest of this thread it seems that scrum is too difficult to do correctly for the vast majority of project managers.
haha, we started by following the scrum rules,
some folks didn't think it is the way to go, sadly not everyone spoke out,
because PM/PO thought it is useful from their perspective...
fortunately, over time, no sub team continued the way, it has mutated back to the kanban style more or less...
I am probably missing something but is kanban even the correct metaphor for creative work(like software development).
Kanban is a back pressure mechanism that can get your factory logistics system running smoothly. However the logistics of creative work is very different than the logistics of assembly work. There are almost no parts needed, why is a backpressure system for part delivery even useful?
It's about limiting the amount stuff under construction.
You got a list of shit that needs to get done. You have 5 people in the team.
On the Kanban board you can see how long each item has been in each column and you can see who's working on it.
You can also limit the amount of items each person can be working on simultaneously. It should be exactly one or you're multitasking, which isn't good for anything.
You have a single task you work on, when it's done you move it forward. If you get stuck you move it backward and comment on it why it's stuck and pick a new one.
It's not, it's one of those cases where IT took some vague ideas related to a concept (e.g. visualizing/minimizing WIP and having a continuous flow) and decided that those meant we're doing the same thing.
See also "lean manufacturing/software development" and obviously "software engineering".
Is “doing Kanban” just having tasks on a board without any sort of sprint structure? I feel like it’s a bit of a false equivalence. While I won’t ever defend all the cruft that comes with Scrum, the article seems like a bit of a straw man.
"kanban" is all about maximizing flow of completed tasks, and minimizing/limiting work in progress.
Someone is either working on a task, or idle. A task is either being worked on (making progress), or it's not being worked on. -- A task will get completed quicker if you can minimize the amount of time it's "in progress" but not being worked on.
If you have 5 workers and 15 tasks in progress, 10 of those tasks won't be making progress.
Often, a task may be blocked by requiring some action from someone else. (e.g. PR review, or more resources, or blocked on some other task).
The 'kanban board' is about visualizing work in progress. -- By visualising the work in progress, it's easier to identify bottlenecks & inefficiencies.
So if I follow well, the interest is in having all different types of 'blocking stages' in the pipeline so that you can identify the points that slow down your process. With the right tool, and provided the tasks are accurately tracked, you get good statistics pointing to where you should optimize the workflow.
However, it's not so simple to read. In some cases tasks were blocked because of a superficial or nonexistent analysis, which required to get more information. Which is a clear break of the flow, since it has to be paused for the time before the meeting can happen. But sometimes, the analysis can be fairly bad and very time-consuming on the other department, making the broken flow more efficient than the flowy one if you account for the whole team and not only developer time.
Which seems to me that it's a good idea to optimize for flow only after you have enough consistency in the process, but still a powerful tool.
I also don't fully understand what "doing Kanban" means - like you, I see Kanban as a type of board rather than a method of going through said board (maybe because of a lack of understanding of process & an over-indulgence in Trello's marketing).
That being said, I would say that having a Kanban board without any sprint structure (or any attached micromeetings) would skyrocket my productivity. The two-week sprint thing is meaningless to me - in my org tickets overflow from one sprint to the next all the time, tickets get added mid-sprint, it's an utterly meaningless distinction.
This is exactly how I feel. Then we talk about 'complexity points', explicitly not time, but then say only X of them fit into a two week fixed time window. So then overflow them (or pull new work in) as required as you say anyway, it's pointless?
Whatever the management benefit supposedly is, seems like it could be achieved with declaring current (not 'sprint'^) goals, and a filter for tickets done/progressed in a given date range?
(^Even the language is depressing: sprint, ticket, points, standup, sit down, keep moving, ...)
> in my org tickets overflow from one sprint to the next all the time, tickets get added mid-sprint
That's not Scrum then. You don't add stuff mid-sprint, that's the whole point. Unless the world is literally on fire, you don't touch the sprint content.
What's your scrum master doing when you get stuff added? It's their job to prevent it.
And if work overflows, you need to spend time grooming the tasks to manageable chunks and adjust the team velocity. You can always pick up more tasks if you run out of stuff to do.
Why do you need a "scrum master" to prevent that? Linux kernel seems to be doing just fine without them.
The real solution is of course not to have any "sprints" at all. A manageable chunk of work is a 3 to 6 month project.
Non-tech enterprise treat software engineers as children and create bad software. FAANG and adjacent companies treat software engineers more as professionals and create better software.
Linux kernel is more like Kanban than an Agile project, you can't really compare it to a project with an actual client who pays money to receive features in a timeframe. Stuff gets done when it's done and the BFDLs decide when the feature gets into the actual kernel.
Waterfall-style projects had 3 to 6 month timeframes of delivery and we all know how that goes. The result is always either out of date due to changing requirements or not what the customer wanted because there is no way to change course after the project specification was locked.
...or you spend so much time doing an exact specification that the Agile team has already delivered 3 incremental versions.
I don't see what use a "scrum master" is. That sounds like a small task for the software engineer or their real manager. There is nothing showing that heavy agile actually leads to features being developed earlier. In my experience it's the opposite as you build up heavy tech debt by micro-managing and optimizing for a 2 week return instead of the long term.
Waterfall were 1 to 2 year projects with heavy up-front administration. 3 to 6 months is well-balanced and that's what the "elite" companies and research groups tend to use. Two weeks is the current fad at non-tech enterprise.
In my experience on a scrum team, the scrummaster was basically a coach. They helped deal with external issues as the other responder said, so the manager (team leader) didn't waste his time with that and could use his time dealing with team members and doing engineering work too. In my case, the scrummaster had this role for a bunch of parallel teams, not just one, so it was a full-time job for him. The org structure seemed to work very well for the type of work we were doing.
If the "scrum master" stopped booking meetings that should have been an e-mail, the engineers would deal with those issues with time to spare. What issues really? I don't even see how a technically weak "scrum master" could deal with any real issue in a software product.
Yea, pretty often scrum masters are hired coaches that are let go when the team knows how to self-manage - or like you said - they coach multiple teams at the same time.
What qualifications does a "scrum master" have that a software engineer does not have when it comes to creating a self-managing team? The "scrum" pamphlet can be read on a lunch break and I don't think the certs even have exams.
In my experience, there's a couple: 1. The scrum master actually has a personality that facilitates talking to people both inside and outside the team, getting people to participate in meetings, etc. The software engineers do not. 2. The scrum master has time to spend on dealing with external stakeholders, coordinating between teams, etc. The team members have better things to do with their time, like write software.
Engineers communicate just fine at FAANG. I don't see why they need an agile helper in non-tech enterprise. Lawyers don't need agile, and doctors don't. There is no reason why engineers would.
The team members are too busy with agile meetings to write software. That's a more common problem.
Maybe giving the tech lead a technical secretary is a better idea if you have a lot of administration to be done.
Obviously you have some kind of axe to grind and haven't worked in a place that uses the scrum process decently. We never spent much time in agile meetings.
No, that is not obvious, more than you making money from corporate agile, which few software engineers seem to actually like. Too many meetings is one of the most common criticisms.
The task of the Scrum Master is to make themselves redundant. They just make sure the team follows the structure they agreed on + runs interference for external issues.
After the team is mature enough, one of them can take the SM duties in addition to other tasks because the actual process runs without extra management.
That's not a rule in Scrum that I'm aware of. It's an aspiration for sure since an injection implies some sort of emergency or unanticipated work. Ideally you avoid those sort of things. But if they happen it's not an issue to inject something. Constantly doing so usually means something has broken down in planning and/or quality is so bad the team is going from fire to fire.
See that's the main problem with strict scrum. Why can't you add things to the sprint mid sprint? Sometimes things come up that you didn't think of.
There's really no point being that strict. I think two week meetings/sprints are good for keeping focus and as an opportunity to agree short term priorities. But the point is to get work done, not to precisely obey scrum rules.
If the "you" is the team, go ahead. Add anything you want, as long as you deliver what you promised in the beginning of the sprint.
If the "you" is an external person asking for a "quick job", then the default answer is "talk to the scrum master" whose default answer will be "No.". Then they can start discussing if it is so urgent and important that it can't wait 1-10 business days for the next sprint and/or small enough not to disrupt other work.
The rules are there to protect the team. If the team is willing to take ad-hoc work, nothing in the agile rules says they can't do so. The point is that nobody outside of the team can force them to take on extra work mid-sprint and disrupt their planned work.
So if we finish all of our tickets early (which is often the case because measuring complexity is impossible to do up front), we're just supposed to sit around until the sprint ends?
A scrum master? Man, I thought my team was bloated with process but the fact that role exists elsewhere means I should probably be more grateful.
Kanban is about organizing the work to be done and periodically revisiting the board to understand the work done and what’s next (which involves reprioritizing, pivoting, etc.)
Some people might debate on how active a kanban board should be.
That sounds identical to how companies I've worked for "do agile". A kanban board. Every two weeks you revisit the board, see what got done, prioritise what to do next (usually by dragging it from the "backlog" to "todo" column).
Could be much worse in practice. You could have retrospects every two weeks, daily standups, messages every day from your nontechnical manager asking you for estimate markers on each of the tasks, breaking down tasks further, renaming tasks they don’t understand but other engineers do, etc.
That's the whole trick with "doing Kanban". You don't need special magic methods to do your work- just pick up a ticket and do the work, repeat forever.
I’ve fortunately never had to do Scrum other than an internship where I had no idea what was actually going on. We do almost exactly what you describe. We just take tasks off the board and we don’t have sprints.
I get that, that’s what I do with my team, but I’ve never heard that referred to as “doing Kanban”. Maybe I’m just being pedantic, but writing an article to say “you don’t need Scrum, just pull tasks off the board” completely misses the point of why teams use Scrum.
Scrum is pushing stuff into a sprint. Kanban is pulling the highest priority stuff through - it's done when it's done.
Metrics/Analytics can be calculated when your done based on actual information, as opposed to the beginning when you're guessing, and likely to be held to your estimates.
For us, visibility isn’t an issue. I would say estimations are by far the biggest struggle we have in “doing Kanban”. Luckily, they’re not super important for us and I usually bubble up a very rough estimate in monthly reports to management, but in an org where they matter more, I can absolutely see why Scrum gets adopted the way it does.
Why do you estimate when using a kanban? You might look at an item and break it down for simplicity. You also might go in with a goal of 'one card per member per day' or something similar. But nothing should be fixed to an estimate. If something is delayed, it should show up stuck in a lane. Respond as needed.
Because work is deadline driven by whoever is paying the teams' salaries. If you can't accurately estimate when you can get it done, you break it down until you can you get replaced by someone who can.
Kanban means constrained capacity. You decide on an upper bound on how many things are allowed to be in progress at any one time and if you need to start work on something new you finish things that are in flight to provide headroom to do that. The board is just a device to ensure good communication so everyone in the team has shared state.
I think you where sold on "scrum is all you need"lie.
Kanban isn't there to dictate process, but as a tool to correctly and truthfully inspect your process.
E.g. we recently used length of UAT column to prove that we need more business people doing testing in next few weeks as we close to feature release and more tests take form of exploratory testing.
Scrum isn't blind to benefits of such inspections either! So doing simplified Kanban board is frequent.
If you're doing reactive work, an oversimplified explanation of Kanban is to just put pending jobs on the board sorted by priority and that's about it. Doing proactive work means you can choose what goes on the board and that's where the nuance could happen.
In my previous job we used it and I liked it, but I haven't used Scrum before so I can't comment as to how effective it could be.
I’m not a huge scrum defender - I’ve seen it done right and wrong. Same with Kanban. The only real problems I have with Kanban is that without those annoying team planning/documentation meetings, work will get duplicated, done hastily, done with no discussion or thought toward testing, architecture, maintainability. And that’s not exclusively true of Kanban. But I feel like the lack of organization can turn it from less of a “flow state agile” and more into an insane command economy/death march/spaghetti factory. I usually feel Scrum teams are happier, more close-knit and aware of the impacts of teammates work, and more excited about “doing agile right” than in Kanban - which often feels very siloed and “heads down”. Different strokes, I guess.
> without those annoying team planning/documentation meetings, work will get duplicated, done hastily, done with no discussion or thought toward testing, architecture, maintainability
I don't see why that is necessarily the case. It certainly didn't happen on the Kanban teams I've led. Maintaining the backlog and reviewing the work in progress is just as important in Kanban as in any other process.
Those same problems still happen in Scrum and it's very hard to get out of duplication hell once the backlog gets sufficiently large. I personally think Scrum is theoretically great if done right and with smart people, but that is rarely the case.
Duplication hell is the current bane of my existence - I think we would agree that it’s more of an inter-team coordination issue than it is the type of thing that you and the four other people on your team can fix with Kanban/Scrum. But I do feel like Scrum is better at the very least at stopping this from happening because that longer ramp up time from “customer wants X” gives people a chance to say “wait so and so already did that for their turn”
I've heard over and over from managers that scrum is better at anticipating delivery dates. Even when the dates are consistently missed. They'd rather slow teams down with process so they can have a date to give their stakeholders, regardless of its accuracy.
Managing the confidence of your benefactors is a big deal in business, I'd say you can make a career out of it alone, no other skills required. So in a sense you could say that Scrum is the businessman's brainbaby to handle engineering types.
You can calculate the team velocity pretty easily in Scrum (amount of story points completed per sprint) and from that you can estimate what gets done in what time.
BUT it needs the exact same team to be together on the same codebase. You add or remove people, the velocity changes. You change projects, velocity changes.
People also need to be honest when estimating tasks, don't be a 10x cowboy and say something is a half-day task when you know it'll take two days.
It's always better to pick too few tasks for a sprint than it is to take too many. You can always grab more stuff off the project backlog if the sprint backlog runs out mid-sprint.
In Kanban you multiply cycle time by tasks and do some modeling on that value. Only difference is that in SCRUM whole team does produce raw value upfront of work, while in Kanban manager computes raw value downward of work.
Raw value here refers to lack of statistical analysis.
People trying to shoehorn scrum into their startup is the problem - not scrum itself
It is specifically designed for interfacing with project-external stakeholders.
It works well for “project teams” in a large org for whom the project isn’t the primary business focus. e.g. an internal tool to assist with problem X, or a development project for an external entity.
There is no other use case for which scrum is a good fit - and it’s those mismatched experiences that always result in scrum hate.
I think people just got caught up in the cool name and the certifications and blah.
That sounds sensible. Soo... How do you get your managers to this insight? In my company each team uses scrum and I think no one is really happy with it. Mine certainly isn't. I'm not even talking about the engineers: at least from my point of view everyone involved suffers from it. But I have the impression we lack responsibility for such decisions. Oh well, I think I'm just venting now :)
Scrum is meant to protect the team from changing requirements mid-work and it's a good way to work when you have a "client" that requires "features" to a product.
There is a well-defined standard process for them to add things to the backlog and there is a written down definition in which state items in the backlog have to be in so that they get picked up for the next sprint. If the team works with just one client/product, the client can prioritise the backlog.
During the sprint they can't give any input or request "just this one quick feature". The work is locked during the sprint. If they REALLY want something, the Agile Manifesto says to drop and delete all ongoing work and start a new sprint from scratch. Exactly zero clients have agreed to that - they really weren't in that much of a hurry with the feature.
After the sprint the client gets a demo of what the team achieved. An actual demo with the actual product. Not a powerpoint presentation of an ideal state or a video done in a demo environment. At this point the client can provide feedback and new features and we GOTO 10.
Usually a single member needs to be defined as a firefighter who takes on bugs and production issues that can't wait for the next sprint, but we don't tell that to the client. If there is no urgent work, they work on the sprint tasks as normal.
--
Kanban on the other hand works if the tasks have no dependencies with each other, like building maintenance or IT/DevOps type stuff.
"Install new laptop for Karen with standard package" doesn't require a sprint, anyone on the team can do it. Or "Set up AWS account with ECS for team B"
> Scrum is meant to protect the team from changing requirements mid-work
Do I need this protection? Why cannot I protect myself? Do I want this type of protection? Especially if it comes with all the negative downsides of Scrum.
Scrum is based on the imho often wrong assumption that a team needs "protection" of some sort. If your team consists of 16 year old youngsters only this might be true and this type of protection might be useful.
All this "protect the team from changing requirements mid-work" is nonsensical anyway, because no _really_ valuable work is done in 2 weeks. If the requirements _really_ changes you have to throw away the code for the old requirement. You can throw away 2 weeks of coding or 2 days. I'm pissed off more by 2 weeks of dead code. If the requirements adopts a bit its better to adopt early. And change in focus and priorities (which is _not_ a changing requirement): I'm happy to do so if I'm convinced it's for the good of the company and I'm happy to say "Sorry, this will have to wait until I'm done with what I'm currently doing. Please come back next Tuesday.".
Yes, you need the protection. You shouldn't be protecting yourself because it takes time from your work.
Or do you enjoy explaining how project priorities work at length for the fifth time in two weeks? Do you enjoy sales just "quickly popping by" your desk to request "a small tiny feature I promised the client we'll have done by end of week".
This is why in Agile we have the Scrum Master who fields all requests like that and tells Marketdrone A to fight Marketdrone B on whose task is more important, because team only has enough time to complete either task on the next sprint. Every time someone tries to interfere with the team's work they firmly direct the person to the SM. In a few actual cases the team's SM has physically removed the over-eager middle manager out of the team's space with their "few quick requests and improvements".
I'd really want to know what kind of tasks can't be completed in two weeks in your opinion.
The tasks in a sprint aren't "build a house from scratch" -level, you split them until they're in manageable chunks of time. In a single sprint you might have the task of clearing the plot from any trees and laying down the markers for the house's base.
Then the client comes in and approves the direction or asks you to make the bathroom a bit bigger or move the house 5 meters to the east - which is still easy because the "house" is just stakes in the ground with string connecting them.
And again you pick 2 weeks of work you know your team can finish and the client checks that everything looks good. etc etc.
It really isn't complicated. I think the majority of HN has only been subjected to cargo-cult Agile or some kind of Agile-ish system where you just use the terms, but none of the actual processes.
+1 in my experience most people that criticize scrum simply have a bad experience with a half baked implementation of scrum.
If it's implemented well it's fantastic. You get to focus on the important stuff during the sprint. Issues tend to get caught early on because experienced team members chime in during planning poker. The whole team takes responsibility for the sprint together. This leads to lots of knowledge sharing and collaboration within the team.
Once the team velocity is predictable it also becomes much easier to ask for x amount of time per week for refactoring work as the impact to project timelines can be easily quantified.
You lost me there. This is the fundamental problem with Scrum; this type of paternalism where "programmer" is a synonym for "idiotic code monkey", borderline autistic who isn't capable of dealing with demand from the outside. And all programmers are the same, all organisations are the same and all type of development work is the same. Everywhere. If only we would be doing "Agile" right.
The protection in Scrum is "opt out". By default the process says that you're protected.
If the team feels that they don't need it or want it, they can drop it and just hang an "extra work and ad-hoc requests welcome" sign on their team area :)
Most teams I've worked with want to focus on the agreed work just among the team for the assigned sprint length and not have to deal with ad-hoc requests.
> Scrum is meant to protect the team from changing requirements mid-work
But this will happen from time to time. People writing tickets or even devs when checking the tickets don't read the related code. So you have a big and important source of uncertainty. Some things are technically constrained.
That's what the backlog grooming and planning sessions are for. The devs who will be doing the work estimate the work.
If stuff looks really vague, do a "planning" or "discovery" task on the issue first, where you dig through and maybe even prototype what you need to do.
But yes, requirements can change during a spring, but it should be very very rare and not a regular event.
> As I mentioned before, sprint planning meetings are unproductive because they lead to “designing by committee” and focus on getting estimations right, which is not only a waste of time, but also impossible to do in a stochastic process such as software development.
This sentence alone reveals an incorrect understanding of scrum.
First, scrum does not "focus on getting estimations right". In fact, if you search through the scrum guide [0], you will not find any mention of estimates whatsoever.
Second, the purpose of a planning meeting is to identify what next to work on in order to add the most value to the product. Therefore, the meeting involves the product owner, who has the clearest understanding of the business value of the product at any given point, and the developers, who have the clearest understanding of what's going underneath the hood of the product. Their conversation informs both the developers of what's most valuable, and the product owner of what's doable.
Third, in the planning meeting developers, who are actually going to be doing the work, have an opportunity to decide how they are going to split the work, how they are going to collaborate on it, and whether there are any unsolved dependencies preventing them from taking the work into the next iteration.
How this can be dismissed as a waste of time is beyond me.
"Scrum shortens planning horizons by limiting batch-sizes to two week sprints. . . Still, because Scrum is a push-based system, it still requires you to do some form of estimation . . . This demand for estimations leads to unproductive and unnecessary estimation meetings."
I actually prefer Kanban over Scrum, but none of this matches my experience at all.
1) People plan multiple sprints ahead in Scrum. Not necessarily the full sequence of tasks, but things like telling a stakeholder which sprint their task will be in.
2) Many people are in a situation that's inherently push-based and requires estimates. Scrum is just a way to achieve that. The author gets snarky in the first paragraph about choosing Scrum vs having it chosen for you, but really . . . most people know full well that Scrum was chosen for them, and that it was chosen for planning purposes. And that they do tasks because other people need them done, not because they had some free time. Heck, the whole project usually exists to serve the needs of others, not the joy of working fast.
3) Even in Kanban, we'll usually have basically the same grooming meeting. That's because the meat of that meeting is sharing information and thoughts about what the upcoming tasks involve and discussing whether and how to break them down into sub-tasks.
To get a known stable known velocity, so many things have to go right.
The most disruptive thing sabotaging this, all other things being positive, is typically manager turnover when they each have their own differing ideas on how, and whether, and what, to adhere to.
Hold your advice; doing anything about it is not at the pay grade of anyone who will be with the company for more than another six months. Unless… you leave the company. That is the one effective action you can take.
There are different problems, depending on your role
1. Communication and Funding - Does your VP know how they are spending money? How is that money allocated? This is why you have agile-fall or SAFE.
2. Planning - Can you deliver the solution your architect drew on the napkin? Does the PM know enough to schedule things.
3. Work handling in the team. This is the one that I think people most want to talk about, and anything that works for the team will work. You don't need anything fancy.
Some benefits of Scrum over Kanban:
* Scrum is less flexible. It is easier to force everybody into a fixed process. Kanban can easily become cowboy development especially with junior devs on the team.
* Scrum comes with clear short term goals. Kanban may hide the important milestones.
With that said. I think the drawbacks of scrum are just too many. It is inflexible. You have to sit in meetings to solve Scrum-problems instead of real problems.
Retrospectives are just magic though when you work with people that are great at agile software development. Ad hoc talks during daily work can never replace that. The velocity one can achieve by constantly improving and challenging the software developing process during dedicated sessions is just ridiculous. But it also have to do with having the right people. 2 hours of people whining about test environments will not accomplish anything.
Edit: Btw, problems with test environments is usually down to poor architecture and hard to solve. Design for testing too...
If you ask different parts of your company if Scrum or Kanban is better, you'll get WILDLY different answers from different parts of the business. The CEO has very different needs and wants than the on-the-ground code monkey. We have to take all of that into account before saying we "don't need" Scrum. Yes, okay, you don't NEED scrum, but maybe it's the best tool for the job, given the collective requirements of the business.
Judging by the perspective shared in this article, I'd say it's coming from a Team Lead / Lead Programmer role at a small company, where Kanban works great. Once you grow beyond a certain size, almost everyone switches to Scrum. Why? Because it reduces friction with other parts of the business, which want - nay - NEED to slice time up into manageable, trackable chunks. And this goes all the way to the CEO and investors. You may not like it, but it's a very real constraint on your choice here.
Kanban is great for systems with predictable output. If the work units remain mostly the same, you can greatly increase flow efficiency and velocity using kanban. It's basically waterfall meets JIT delivery (which is why it worked so well for Toyota).
Scrum is for less predictable work, where many/most of the requirements and/or challenges are not well known or defined yet, or are likely to change as new information becomes available. For this kind of work, you need a constant feedback mechanism so that the captain can adjust course as needed while traversing uncharted waters.
I currently work in a team that builds code that accesses poorly or completely undocumented systems, and is seeking a market fit for new products. In both of these cases, agility is far more important than velocity, so scrum is the right approach. In previous places, the work my team did was very predictable, so kanban was the right approach.
Note: There's nothing wrong with having both in the same company. Team has predictable work? Kanban. Else scrum.
Genuine question: How does Scrum help with less predictable work?
From my experience, the opposite is true: New things are discovered during sprints, but at that point it's already too late because that work item has already been estimated in the sprint planning (most of the time incorrectly). Also the arbitrary sprint deadlines don't help either.
When new information exposes issues with the current piece of work in a sprint, you discuss it, and then change whatever part of the plan no longer makes sense given the new information.
Will it mess up the numbers? Absolutely, but only for that piece. And as a result of the change of plans being entered into the current sprint (with something perhaps bumped to make room, or maybe the work itself bumped to a later sprint to give more time to plan for the new challenges) you already have a new estimate. And you have a paper trail of what happened and how you dealt with it.
Your velocity goes down and you lose some predictability, but your agility goes up because you can adjust instantly to new challenges. None of these tools are a panacea; you have to thoughtfully decide which trade-offs will offer the greatest benefit for your particular project.
The "deadlines" shouldn't be thought of as hard deadlines. They're estimates of what you expect to have done at the end of some arbitrary period. Your accuracy in this should be measured statistically over time. If it turns out that you're consistently under or over, you adjust how you estimate. Ideally you want your estimates to average out to break-even over the course of a year. The point isn't to be able to determine exactly how much work you'll do, but rather to determine with a high degree of confidence (80%? 90%?) when the work will be done, with the understanding that it's not guaranteed (i.e. it's a point statistic). It's a planning tool, not a performance measure (the moment you treat it as a performance measure, it becomes useless due to the cobra effect).
Flexibility is good. I agree with that approach. But then I fail to see the benefit in scrum in the first place. The other things you mentioned (measuring all these metrics) does not seem helpful to me at all.
When you can measure metrics with some reliability, your executive team can use those metrics to plan out releases (e.g. "the new Fizzbuzz feature is expected in Q3"). That allows your marketing team, budgeting team, and deal flow team to plan around it (with the understanding that it is statistically reliable, not necessarily individually reliable).
If your development situation has high enough stability that kanban will be the best fit, you'll get much more reliable metrics for planning, but less flexibility when something unexpected happens.
If your development situation has enough uncertainty that scrum is the better fit, you'll have less reliable metrics for planning, but a lot of flexibility to deal with the unexpected (which you expect to encounter with some frequency, otherwise you'd be using kanban).
Cutting edge technologies and startups are usually better suited to scrum because they need the flexibility to pivot when needed. Well established technologies (like Oracle DB or MS Office or Ubuntu or Jira or a CRUD app) are likely better suited to kanban because they'll benefit from the streamlining at the cost of flexibility they don't need anyway.
Have you tried to just track time on board / time on column on each task on Kanban board?
You just need to keep track of time to trigger those discussions.
You can technically do everything with both tools, but each is optimized for a particular situation. They're so closely related that many people think of them as competing alternatives rather than as situational alternatives.
Start with the "Why". Why would you use Scrum? I'm with Simon Wardley [1]. Agile, Lean and waterfall are not the same thing and are not exchangeable.
Agile is for building new things, it's optimized for learning and navigating in a space you don't know about (say before/around PMF) - though most people do Scrum wrong, E.g with the roadmap-anti-pattern.
Lean is for optimizing a product, after PMF, E.g. when Scaling.
Waterfall and Six Sigma is when you do the same thing over an over again and you have a lot of knowledge in the space, when you outsource commodity development,
E.g. customizing a CRM.
Kanban and scrum are solving different problems. Kanban focuses on the flow of work through the team. Scrum is a framework with the bare essentials to deliver value to the customer. Most scrum teams use kanban to control the flow of work through their team. They're separate processes.
What the article is saying is that bad scrum is much worse than no scrum - which is so so true. But good scrum is waaaay better than no scrum. Combine it with effective Kanban (eg. controlling WIP) and you're on your way to a very productive team.
Heavy assumption in the comments that sprints "are" 2 weeks.
I've found scrum works best with 1 week sprints. It forces ceremonies to be short.
But at thr end of the day the only important parts of Scrum are ensuring the standups are run ruthlessly short, no fat, and that the Retro produces actions that are actually done.
Because if you are running proper retros after 6 months "your" Scrum won't look like anyone else's Scrum as it will be customised to your work and team.
Last 10 months we were running Agile Scrum, for rebuilding legacy app. It's an understatement to say we wasted so much time, and PO had so much trouble running that.
The experience i have with scrum is similar to what the procrustean bed suggests. Funny thing -to me - is that usain bolt did not use scrum to win, neither did federer. You can’t go to the moon with scrum. But I do see value in it as long as I drop 80% of what it proposes. Scrum is just a passion killer. We shoud use the ideas from the No Estimates and Accelerate books
You don't need Kanban, you just need to do Scrum right.
It seems most people who are complaining about Scrum, are really complaining about the lousy implementation of it in their company. Which tends to be the result of lousy management.
With lousy management, any process will be a pain. Doing Kanban with a manager behind your desk asking why your feature is not ready yet isn't a pleasure either.
There also seems to be some misunderstanding about speed of development and Scrum; some posters are complaining that Scrum slows them down. Yes it does! And this is on purpose. Scrum focusses on delivering business value, not on delivering lines of code that possibly nobody needs.
So there are moments in the development process when feedback is gathered from stake holders. This is important, because it gives them an opportunity to adjust what's being built, or even switch to a more important feature altogether.
The downside is that this takes time. But the upside is that you will have far greater chance of delivering something that is actually needed.
It is too vague. Compare to the ten commandments. Half of them are repeating detailed versions of "don't mess with your neighbour" to make things clear.
The Agile manifesto should have been written in a similar style ...
Scrum needs surprising effort from coworkers to understand the system as well unlike common kanban that has existed for eternity. Meanwhile at some stages the stuff just becomes mythical and people stop to implement but rather improvise.
It doesn't matter what methodology is used. The most heavily weighted factor by far is whether the product owner and managers understand the implementation details well enough to keep estimates accurate and mitigate scope creep.
As someone who runs a software agency, kanban sounds like nonsense.
If you don’t know exactly what you’re doing, for whom, by when, you fail to meet expectations by delivering the wrong thing by the wrong time.
There is design & estimation, planning, development, and evaluation phases. End of story. It doesn’t matter what you call those phases. If you don’t do design and estimation, you have no idea what you’re building or any metric for success. If you don’t do planning you have no schedule for delivering it.
“I’ll do this feature as defined by a two sentence ticket whenever I complete it” is incompetent and reckless. It’s idiotic. I’ve seen many companies operate this way, and they are constantly delivering the wrong thing by the wrong time (particularly VC-backed startups).
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.