I much prefer Kanban to Scrum. It gets straight to the point which is "what is the next most important thing to do", and let's management/stakeholders worry about what's next while engineers focus on the current top of their heap.
Where Scrum wiggles its way into relevance is schedule. Most businesses need to be able to commit to some deadline with customers or coordinating teams, and scrum lets managers convince themselves that they can project 3-6 months of work into sprints.
The reality of course is that the requirements and deadlines are constantly moving and never match what was predicted, but you need _some_ prediction to coordinate large projects. So scrum just ends up being a hack to generate time pressure on the component tasks.
What's the right solution? So far in my life it comes down to Kanban and focus for engineers, plus an experienced leader that can guess reasonably well, pad for uncertainty, and renegotiate requirements to make that guess come true.
Let's say a project is expected to take 4 weeks to complete. Then, it is no longer a Scrum project. It is a waterfall project that is pretending to be a Scrum project.
With Scrum, everyone commits to working on something that will be done within the release cycle (usually 1 week), then re-evaluating based on feedback. This means asking for smaller things more often.
Trouble is that most people don't know how to ask for and build by starting lean and staying lean. They get ahead of themselves (and the team) by assuming more than they should.
Scrum is iterative and incremental. While you plan a sprint, you loosely plan an increment and using the estimates and velocity, project where you will land.
It can be useful to know you're not going to make the 6 month project 3 months in. So you can readjust expectations or abandon the project entirely.
People will listen if you have evidence and the team on your side. Arguably this all depends on your project, culture and product.
> While you plan a sprint, you loosely plan an increment and using the estimates and velocity, project where you will land.
That sentence contains four verbs: plan, plan, estimate, and project. If your sprint were a single week, planning two things, estimating all the things, and "projecting" the sum of all the foregoing adds up to... Quite a lot.
You'll spend a large portion of your time doing these... fundamentally non-agile things.
Scrum is basically Waterfall, packaged as a lot of mini-waterfalls and sold as "non-Waterfall".
You can't run a marathon as an endless bunch of sprints; a marathon is fundamentally different from a sprint.
I don't know why you're being downvoted, this is correct. How you make schedules and roadmaps in a scrum world is you track some conversion between difficulty as estimated by each developer to the observed time it takes that developer to complete. Then you write up some cards that you think encapsulate the work you want, have the devs groom them by splitting, recombining, and rating their difficulty. Then you total up the time of the cards, add some buffer, and report that as your estimated completion date.
Then you run the board in priority order like any other backlog tracking how additions, removals, or changes in priority affect the completion date. At all times the work gets done when it gets done, and the devs never have to think about more than the current sprint and the next deliverable. Anything not in the current sprint is subject to change.
Because all of this quickly moph to useless ceremony. Managing a project and doing it are orthogonal. But there’s a relationship between the two that, if managed well, leads to a successfull completion. And that relationship is communication.
At each step of the doing, managing should have feedback so that it’s know how expectations are going. Then decisions are taken that influences further doing. There is no need for all the splitting and grooming.
A project can have a deadline (soft or hard) or not. It can depends on other projects and other projects can depend on it. A project can be planned, cancelled or paused. And their duration can vary. Then you assign the project to a team (can be adhoc). The team then decides how to get it done.
I mean this is absolutely true but the goal of this flow is to take very little dev time to enable the project managers to asynchronously (meaning not bothering the devs because the report can be derived entirely from the board state) give project status updates
and updated milestone estimates to the higher ups, and get out ahead of potential issues and blockers (like dependencies on external teams like design).
No company is going to give a project to a team of devs with a deadline and then let them fuck about with no observability into the team's work until the deadline. This is the "team" deciding how to get work done, the person conducting the ceremony should be the direct people/work manager for the team.
The role of the project manager is to provide the observability. I strongly believe there’s no metrics collected at the team level that maters in terms of the business objectives other than progression. Something may be classified at hard, but once it’s got done once, replicating it is easy (assuming resources are available).
Inside the team, it’s another world and that would simply depends on the teams. Maybe it’s a senior with a few juniors and the former is just handing down detailed tasks to the latter leaving the toughest issues for himself. Maybe it’s a collection of experts and it’s a chaotic collection of tiny tasks that everyone takes at random. The project manager just needs to interact with them, measure “progression”, ensuring communication across teams, and updating everyone about priorities.
Handing down the process from high has a high chance of harming the teams.
> the goal of this flow is to take very little dev time to enable the project managers to asynchronously (meaning not bothering the devs because the report can be derived entirely from the board state)
1) Like the ideal theoretical Scrum. (I've never actually seen that in practice.)
2) Like a lot of converting, estimating, splitting, recombining, and rating. (So, that's a full-time "Professional Scrum Master" position, then? What happened to "Agile teams manage themselves; 'scrum master' is at most a rotating part-time task"?)
Yes. All projects essentially follow the same cycle: planning, estimation, execution and QA, delivery. Then, you get some feedback and start all over again.
What makes agile / scrum different from other projects is the constrained timeline. It's 1 week to delivery. Then, you get feedback and plan all over again. The major drawback to this approach is that some projects (including many software projects) are impossible to fit into a short schedule. The big benefit is, when Scrum is possible, the rapid iteration allows for products and services that are truly tailored to the user's / company's needs today, and not their needs six months ago.
The constrained timeline tends to cause a lot of "policy determines mechanism" behaviour though.
I recall having a code-review conversation with a co-worker that ended with him saying roughly "I can see your case for (minor change that dovetails with the change he was working on) but it's already the second Thursday of the sprint."
I've also seen the organization complaining "we want 90-110% predictability of points delivered". I know the intent might be to encourage people to get more accurate estimates, but there are upper bounds on estimate quality, especially for tasks where it's "30 minutes of coding, and between 1 and 62 days of negotiating details with a third party to get signoff."
The takeaway I get is that Scrum basically says the most important thing is to produce a predictable quantity of work, not necessarily that the work is good or fits the actual need. It reeks of the sort of metric Wall Street would love-- I can see someone saying "Story Points/Quarter Line is going up!" ebulliently.
> not necessarily that the work is good or fits the actual need
Producing work that fits the need should be the goal even if it means delivering fewer points of work during a sprint. Of course, like you said, the focus is often the other way around because the policy sucks.
Many projects have a deadline, but managers still enjoy pretending that they are doing Scrum, because it makes them sound enlightened.
"You need to get this project done in 6 weeks, but because we are agile, you can choose which parts you implement during the first 3 weeks, and which parts during the second 3 weeks. Also, I am not really sure about the specification, and some important parts may change halfway, but that's okay because you guys are agile, right?"
Basically, agile was supposed to mean "project deadlines are unpredictable, let's just focus on the tasks we are currently doing (Kanban) or let's focus on one increment at a time (Scrum)", but instead it means "you are responsible for meeting the deadline, but I am not giving you the full specification at the beginning, and instead will just tell you the requirements at random moments when they come to my mind".
EDIT:
Some parts of this article are just triggering to read.
> Cons of Scrum: Resistance to Change Mid-Sprint: Scrum's framework can be rigid within a sprint, and any changes occurring within the sprint could disrupt the team's flow.
Translated to plain English: Some companies change their mind about the product so often that they are literally unable to plan even for the following 2 or 3 weeks.
> Dependence on Stand-Ups and Meetings: Scrum can be meeting-heavy which could potentially lower productivity if not managed correctly.
Stand-up done properly takes 5 minutes. What other heavy meetings are we talking about? The retrospective and planning that happen once in 3 weeks? Any meeting on top of that is a part of your company culture, not Scrum.
> Not Ideal For Solo Workers: If the team is too small or primarily consists of independent workers, Scrum’s benefits may be less noticeable.
Even as a solo worker, to be told what needs to be done during the following 3 weeks, and then to be left alone during those 3 weeks, would probably be a huge improvement for many.
Within project management, there are predictive, adaptive, and hybrid approaches to structuring a project. Predictive is waterfall, adaptive is agile, and hybrid is a mix.
Yes, everything has cost, timeline, and quality requirements, but the way they are represented or discussed vary a fair bit.
> Where Scrum wiggles its way into relevance is schedule.
I use both ... Kanban for operations/IT/Support, Scrum for product development.
> So scrum just ends up being a hack to generate time pressure on the component tasks.
Yes, but also it let's you figure you are off track early in the project. Too many people let themselves be fooled into thinking that "we went off the rails for a few weeks but we're back on track now" without some kind of process to force you to acknowledge the problem.
Scrum is good for delivering small incremental results in a chaotic environments, and is popular because it naturally provides a tunable paper trail for mediocre managers to cover their asses with. But if you are trying to anything ambitious from either a product or engineering perspective then scrum will absolutely kill you, first by sucking the life out of your best engineers until they leave, and then obscuring any important ideas or real progress under a sea of administrivia.
In most placed I‘ve been, Scrum was basically an excuse to not having a clue, not having a plan, not being able to plan and not being able to execute a plan.
> is popular because it naturally provides a tunable paper trail for mediocre managers to cover their asses
Honestly you're giving too much credit to mediocre managers. There's no intent behind adopting scrum. Mediocre managers adopt it because that's how you deliver, right? We're Agile and Agile = sprints. Also I'm too scared to not have precise dates when my management is asking for them, and these sprints are very practical to ask devs to provide high confidence estimates and dates so that we can know what will exactly happen in the next 6 months (I've heard of real professionals who can even plan for a year!). Change is scary!
As someone with 14+ years in the California tech scene, they're both fairly terrible for large pushes unless you have a stellar product team that can pull all of the small scoped work together into a larger effort.
Generally, there is a reason enterprises use standard Waterfall and the like; they're not looking for agility and quick-response, they're building large scale applications and iterating upon them.
(I'm a startup kinda person and prefer that environment, just pointing out the merits of more glacial enterprise style development cycles/pipelines)
It slightly sets my teeth on edge to see the work items in Kanban referred to as “tasks”. The goal isn’t only to minimise wasteful multi-tasking locally, but to see deliverables flow through to the point of customer impact as smoothly as possible.
For me, the Zen of Kanban in product development is to work the board from right to left, working backwards from a "done" that means "someone's need was met" [1], stickies staying on the board until the learning is accounted for. You just don't get those senses of impact and learning if you think in tasks, and when tasks are managed at an unnecessarily fine granularity, I would consider it dysfunctional.
For what it's worth, I'm the author of Kanban from the Inside (celebrating its tenth anniversary in September) and Right to Left: The digital leader's guide to Lean and Agile (2019).
Edit: In case I am suspected of being anti Scrum, the reverse is true. Scrum done well can be truly great. Moreover, Scrum and Kanban are highly complementary to each other – they not only work in different ways, they do different things. As the article eventually acknowledges, there is no either/or here.
Scrum is developed as a solution to quick requirement changes and adaptability of development (agile), but I find that 2 weeks sprint planning and execution is actually the opposite.
If the requirement come during a sprint that'll change the scope, I don't find scrum can accommodate that. At best scenario cards are swapped with the new requirement. However at that point, scrum planning become useless, even to the point as being a hindrance.
So I treat my scrum board as Kanban board with two weeks checkpoint to measure velocity due to company rule. Honestly I prefer Kanban with periodical, flexible retro / planning.
> Scrum is developed as a solution to quick requirement changes and adaptability of development (agile), but I find that 2 weeks sprint planning and execution is actually the opposite.
It is a solution against quick changes. The only benefit of Scrum that I see is that if you have a client, PM or CEO who comes up with new ideas all the time and wants them implemented now, Scrum allows you to tell that the sprint has been planned and the new ideas should be taken to next sprint planning.
Exactly this. It's XP with all the edgy stuff that scared pointy-haired bosses stripped out. XP was in part an effort to empower engineers to make decisions and be creative.. in exchange for rapid delivery.
I have mixed feelings about my time with XP. Some of the lessons from there have gone deep down into my psyche. In many ways it struck a chord with me because it fit in many ways with my somewhat ... ADHD ... working habits ... because it kept the horizon short and made it always explicit what was to be done immediately and, most importantly why and made it clear what the outcome had to be -- clearly defined user stories, feature-level granularity.
On the other hand, it felt a bit cultish, and the intensity of constantly talking about and naval gazing about process was frustrating.
But so much of what people accept now as standard practices -- that I guess came for many people via SCRUM -- had their origin there. Daily standups, short sprints, etc. I just think SCRUM has mostly lost what that was really about.
In the end no process can substitute for just small teams of motivated creative people solving problems they want to solve. Unfortunately most projects/teams/companies are not that.
In my experience as a dev... Kanban is a useful tool that helps teams organise work, break it down, be flexible. It helps the whole team to see what needs doing, identify dependencies and where to help each other out. Scrum OTOH looks similar on the surface, but is a form of micromanagement and becomes a system to be gamed. Project Managers become more concerned with velocity and burndown charts and whether specific stories were done in specific sprints or within the specific story points, than whether actual useful productive work is happening that moves the organisation forward. In the version of Kanban I've been in, you can chuck in the occcasional tech debt story into the so-called "sprint" (basically the 2 weeks between planning meetings) and no-one minds. Thus something that's slowing you down can be fixed. Whereas in Scrum, you'd have to haggle with the project manager to be "allowed" to do something like halve the build time in CI or something.
Fair point :) Well actually in my experience they were called a "Delivery Manager" or "Scrum Master" but behaved like a Project Manager, if you see what I mean. And as for Sprints in Kanban, yeah, well Jira kinda works like that and it seems helpful to have some bi-weekly ceremonies and review stuff while only having to do "ideally most of the stories that were asked for" because the ones that were put into sprint are important. In other words, truly Agile (or so it seems to me ;) ) , without being fundamentalist.
> And as for Sprints in Kanban, yeah, well Jira kinda works like that
I don't think it has to. It can do that, since it's built for both Scrum and Kanban. But you don't have to use the Scrum facilities; if your workplace does, that's because someone there wants it to, and therefore has set up sprints and stuff in Jira.
Scrum is good in those cases where it was created so zero trust environment (consulting, horrible PM, etc) and when you have multiple stakeholders. Usually prefer kanban but sometimes you need a pretty rigid process.
you don't have to have a million useless meeting, most of the things can be prepared before and it won't waste the time of everyone.
from a developer perspective, sure, kanban is the king, nobody bugs you... but on a business you need predictibility, and even more than that: predictibility across teams, for which sprint is better at. in a well run company, the managers are not the enemies of developers, they work together to make the entire process better. there are many teams involved in a project, not only development... think about legal, accounting, warehouses, etc.
also, sprints help you avoid keeping unreleased code, which has a very high cost.
i would add that you should pick one or another depending of your type of business. for example, we use scrum, but before black friday we partially switch to kanban because we don't know all we have to do in advance (there's much more to do than we can), we just know the resources available and we need do switch/move/reprioritize faster. each has it's own strength.
>on a business you need predictibility, and even more than that: predictibility across teams, for which sprint is better at.
It isnt. Not really. It gives the illusion of predictability.
Businesses do crave predictability but when a problem space is naturally chaotic it's unrealistic to assume that you're going to get it just by switching development methodologies.
The issue with scrum is that every 2 weeks you are supposed to decide next steps based on customer feedback, not a "business roadmap." Business thinks in terms of quarters, not 2 weeks.
Thus - how does one get predictability out of a process that is designed to be able to change direction within a small increment of time based on unknown customer feedback? I believe the answer is you don't. Business predictability is therefore an issue.
It’s more of a collection of projects than a sequences of sprint. I think the project perspectives (the reality) is more beneficial to the mental health of the devs (which are makers). But managers (bad ones?) love the routine of the sprints, which are then imposed on the teams. At the end, they have all these numbers (story points, issues count, velocity,…) to say that it’s the fault of the devs that nothing has got done.
on a business you need predictibility, and even more than that: predictibility across teams, for which sprint is better at. in a well run company, the managers are not the enemies of developers, they work together to make the entire process better. there are many teams involved in a project, not only development... think about legal, accounting, warehouses, etc.
Yeah you'd think after several decades of software development that curmudgeon-y developers would finally realize that writing software for a living is a team sport but nope, we're still having the same complaints of "wHy cAnT i JuSt WrItE cOdE iN PeAcE?" every time the discussion comes up. If you want to code with 0 distractions, do it on your own time.
Zero distractions is a nice thought, but I’ll settle for fewer.
My main issue with Scrum is that it’s designed to boil often complex tasks down into tiny pieces, such that anyone can pick them up and do them. The administrative and mental overhead with slicing tasks up (and holding meetings to do so) is significant, and frustrating. In a high-performing team where you have specialists, let people do what they’re good at. If someone doesn’t know Terraform, jumping into a complicated task involving it isn’t a great idea; instead, have them take on things they can do, and occasionally shadow the expert doing it to pick some knowledge up.
I’m also a big believer in gating off chunks of your day explicitly for learning. Your manager has to be onboard with this obviously, but dedicating an hour to increase your knowledge pays dividends over time (now there are two TF experts, etc.)
I'm not sure if you're confusing Scrum with Kanban. In Scrum, the team can (and should) absolutely assign tasks based on skills of individual members. There is no requirement that everyone can do everything.
I can barely read the title of this article without feeling an almost irresistible urge to say something nasty about scrum. Yet I'm not entirely sure why.
I don't think it's due to any specific requirement of scrum. Actually planning work in small increments, catching up with your team regularly, looking back and reviewing how things went, etc etc are mostly obviously good things.
I think it's the mistaken idea that a project manager can learn how to manage a team of software developers by learning scrum which I really dislike. I think that a good manager would do all of the core things scrum recommends more or less instinctively and wouldn't need an explicit process or framework to tell them how. Whereas someone who has learnt the scrum process but doesn't know how to code ends up creating a kind of ritualistic performance of management which is incredibly ineffective.
Often it feels like people believe they following scrum methods will let you run a team well without an expensive experienced manager, but this is not the case.
Few things are as soul sucking and demotivating as scrum. It seems to always devolve into something hostile to productivity and creativity, resulting in low morale.
Yes. I hate it with a passion. Pointless meetings, planning that doesn’t matter and endless timesinks. The only devs I can imagine liking it are the ones that don’t want to take responsibility of the product backlog nor want to think about feature implementation. They just want micromanaged tiny tasks that tell then what to do next, a life void of responsibility.
Managing a team of software developers by fitting them into a project management process is certainly not "Agile". Yet, yeah - I would agree that is what happens.. The distinction between agile development and agile project management I think is often lost. The article starts with viewing "Agile" as a project management process first and only. The fact it was originally always intended [1] to be a development process and not a project management process is seemingly lost.
[1] Per interviews with Uncle Bob & Martin Fowler, Ward Cunningham, and other signatories of the agile manifesto [2]. I can try to dig up the specific interviews and quotes if requested.
23 yoe here working on lots of big projects across several industries. Scrum is the worst thing thats ever happened to the software industry. So much time wasted instead of getting work done. Micromanagement tool that benefits noone. Thankfully my current team switched to kanban about 1.5 years ago and we are no longer constrained and delivering feature after feature and new products. Scrum was a dark, dark period for all of us for about 10 years. Whoever came up with it should be shot, burnt, covered in acid, quartered, and tossed into a pit of hungry tiger sharks. It is literally the biggest roadblock to success we have ever seen. Once we switched away from it , it was an enlightenment to everyone and management was happy that we were delivering at a rate double to triple than we were when we had used scrum. No more effen story points and useless meetings anymore hallelujah.
I've been on 5 or 6 different teams that used what they called scrum. I've never seem it work well, either it quickly devolves into an exercise in going through the motions or it's used as a micromanagement exercise on a team with little trust.
I have seen it occasionally help promote better communication within the team, like earlier calling out dependencies or having team members ask for help earlier. Communication is a different challenge though, scrum is too oppressive when the problem to solve really is just better, and more frequent, communication on a team.
I’ve seen it used well in a small (3-4 team) dev shop.
But its value was almost entirely in managing clients, not developers, and it required absolute buy-in from the whole org, owners down.
If our clients had been above us in the org chart, it would have fallen apart, or at best just slowed things down while making everybody more stressed out.
It can be great that way. And it’s generally useful when the objectives of the teams are not the consulting business, but the client. Meet every two weeks to discuss the project and get feedback on what’s been done. Often, it’s not the devs doing the meeting.
But scrum inside a business is pretty much a nightmare scenario.
Scrum is to protect the team. The team just works at their cadence, and the velocity will help the team not commit too many points for the next sprint. The communication is the same with Kaban; I didn't see any difference.
This article is the what, but it is missing the why. I'm supremely biased against scrum, so basically ignore what I am saying if you're a fan of it. Fundamentally, Kanban is pull-based, and Scrum is push-based. That's the difference.
Scrum spends time determining how long things will take, and then attempts push it into a schedule via story pointing and other ceremony where people pretend they're not guessing how long thing will take by using points and t-shirt sizes and anything other than time to guess how much they can get done in some arbitrary amount of time. Then devs do what they were going to do anyway, and everyone slaps each other on the back because they're measuring the success they're having. It's a dream for people who like to count things and build check lists and check them off. Its success has little to do with the process and much to do with the team's ability to gather requirements and do their job. It's ideal for contract gigs where it's as important to track how much time it takes you to do things as it is to actually do things.
In Kanban you put what you want to do in a list, and pull the things from the list in order as you complete them. If customers need things quicker, you change the order of things in the list while communicating to them what will slip and what will accelerate. They take as long as they take (because that's how the world works, yes, even in scrum), but with 100% less ceremony and pointless coordination. Kanban is about constantly managing constraints and eliminating waste. You don't need to strictly measure how long things are taking. You pay attention when things don't move off the board, and modify resourcing in whatever way will get things unstuck. It's less fun because you don't get to pretend you know how long something will take, but it's more fun because you get to be an adult professional instead of a servant to the processes of people who don't actually build things.
This is somewhat tongue-in-cheek, but in my career I've never seen switching to pull-based patterns make things worse, and I've often seen them make things better, including morale. It doesn't seem like it will work, but in practice there are so many efficiencies gained in pull-based processes that it usually ends up being faster and feeling better while doing it.
If you want to learn about scrum you are better off learning about XP which is a much superior engineering-centric methodology that Scrum takes heavy influence from.
Scrum can be useful as a way to get a team (and its leaders) going, build habits around releasing small batches/iterations of value but it is not particularly scale-able and puts a ceiling on the performance of a team. For leadership its a good way to get them to start loosening the reigns by having the right conversations.
The board part of Kanban is just one basic component. What gets skipped over are the EXPLICIT POLICIES that are refined over time i.e. what constitutes being in a column; the measurement of throughput (which is covered in the article); and a very high focus on continuous improvement (which includes the columns AND rows of the board, associated policies, and WIP limits)
Scrum gets a lot of hate because it's been commercialized and bastardized by people half-assedly doing it. It has a time and place. If you use a saw as a hammer you're not gonna have a good time.
A system that devolves when it comes in contact with reality,is not its idealized version bastardized. Its what it results in reproducible built after built in society. Nobody cares if the idea is pure.What matters is that the idea can not handle edge cases like the mgmt-dev relations becoming antagonistic.
I have seen both good and bad implementations of Scrum. Or rather, I have seen Scrum, and I have also seen people doing classical management with some extra rituals on top of that and calling it "Scrum". Yes, the latter is basically the industry standard these days. I have worked at over dozen companies, and I have seen the actual Scrum only once or twice.
There is no system that survives a company culture that takes some of its keywords and ignores everything else. Without Scrum, companies would have the same endless meetings and micromanagement, but they would call it "Kanban" or "XP" or something else instead.
As I see it, the basic problems are the following:
1) Companies want to set deadlines, no matter how many times you tell them it's unrealistic, no matter how many times their plans have failed. They also like to pretend to be agile, but it will always be "agile with project deadlines". If they say "Scrum" it means "Scrum with project deadlines". If they say "Kanban" it means "Kanban with project deadlines". You are supposed to role-play adapting to the situation, but also in exactly 7 months, 2 weeks, 3 days, 5 hours, 21 minutes, 6 seconds, and 374 milliseconds you are expected to deliver a product that contains this list of features (plus all new features and changes that will get added during the development), no matter what. The fact that this never happened before should not stop you from believing that this time it will. You will probably do a lot of overtime towards the end, and fail to meet the deadline anyway.
2) There are many managers in big companies, and to keep their jobs, they need to invent busywork for themselves. That's why you get the endless meetings, constant changes of plans, etc. If you do "Scrum" it means "Scrum with lots of extra meetings". If you do "Kanban" it means "Kanban with lots of extra meetings". The managers need to be seen as important, how would they achieve that if they just gave you the specification and left you alone? How would they justify why the company needs to employ more managers than software developers? Your daily standups were not supposed to take one hour; they were supposed to be very short, literally while people "stand up" to prevent them from starting long debates. Your manager was not supposed to be there at the daily standup. Heck, you were not even supposed to have a manager in Scrum! But, you know, your manager was there before the company decided to go "agile", and he is not going to fire himself just to make the company happy. And your manager's manager knows that his prestige is measured by how many people and how deep hierarchy he manages, so he is not going to fire him either. But all those managers need to be seen managing, and that's why you have all those meetings. The only meeting over 5 minutes long that is actually required by Scrum is the retrospective -- and there is an 80% chance that your company decided to skip this one "because it is a waste of time".
Simple - Kanban when implemented properly in teams works brilliantly, Scrum when implemented properly in teams works "ok" and then tends towards Kanban as the team strives to modify it to work better. Solution - always start with Kanban
In my experience shit managers have a really hard time understanding and appreciating the effectiveness of WIP Limits and it creates pressure on teams to break them, at which point Kanban snaps in terms of both predictability and delivery.
I never understood the obsession with this kind of thing. I guess it’s important to project managers and the like, but as a software developer? Just give me a list of prioritised tasks. You want me to be in a stand up saying what I did yesterday, what I’ll do today and what are the blockers? Fine, I’ll do that as long as the whole thing doesn’t take longer than 15 mins and you let me focus aftwewards.
Meanwhile, I have never understood positions like this. What exactly does ideal team work look like to you? Do you collaborate with your teammates or do you all go off and work on completely isolated tasks? Do you only share knowledge after the fact through code reviews or do you manage to spontaneously talk about how to accomplish big things before the tasks are assigned? Do you routinely communicate with your users or representatives thereof or do they spontaneously show up and let you know about the actual problems they have and how things are going? Is the application you are building so simple that you are the only person working on it otherwise why is a ratio of 1:31 an effective ratio of collaboration for you?
From my perspective, well functioning teams communicate with each frequently. What's the daily, short term (spring), long term plan? Why did that last plan go well/wrong and what should we do differently? Routine meetings have a habit of becoming rote, but it is difficult to ensure such conversations are spontaneously happening between more than a couple of people. I don't want my colleagues to be surprised when they review my implementation, so we need to discuss it before I do it and vice versa. Discussing those things ahead of times also allows us to plan and prioritize more effectively. It also helps us align and build a better understanding of what we are doing.
I think people are obsessed with this kind of thing because people quest for a silver bullet, but individual teams working on disparate products and problems will find different strategies more effective and require a different balance of communication. Meanwhile, most organizations will push a chosen silver bullet in the name of consistency instead of enabling teams to truly self organize.
> What exactly does ideal team work look like to you?
Certainly not something defined/constrained by the PM methodology du jour.
I can and do reach my teammates frequently just like they do with me. This doesn’t preclude the occasional meeting or even the daily stand up, as I said. But in the end I want to know what I have to work on and who I have to reach if I need help or get blocked, and more importantly, be given the focus time to do it.
This. And I’ll be amenable to a team meeting to reflect and exchange on how the team have been doing. And even those demo meetings when a project got done. Or sharing knowledge and doing postmortems. I just don’t want the daily standups and the ritual retros. I never wait for these to share issues and provide updates.
I don’t think anyone actually listens to anything said in a standup. 99% just does not affect you in any way. If we have an issue we need help with we just send a message on teams or get on a call. The standup is pure ritual
The role of a modern Software developer is changing and Scrum is accommodating that fact. If you just want a task list, start coding and be left alone, that's fine, then you should look out for teams who don't do modern/agile software development. I've had my fair share of such developer types in my career and i would have just wished that they didn't have signed the work contract as they pretty much knew beforehand that they dislike agile but kept that for themselves until after the fact.
'agile' can mean anything from a slightly reductive but generally useful process to a mind numbing waste of time where no one is really allowed to do anything at all except talk about the work they're ostensibly supposed to be doing. if hiring companies were more clear, we could steer well clear of the latter. but they all say 'oh, yeah, we just have a lightweight agile process, not really a big deal, we're trying to do it right, not like those other terrible people'.
everyone whose been in the industry knows how to deal with the former. look, if you need daily status from me that i'm not just going to volunteer anyways, fine, its not a huge overhead. if you me to track my work with tickets, not gonna kill me. if you want me to meet every two weeks to make some plans, i can do that.
thats not what people have a problem with. not being able to actually make plans because we're supposed to come up with our own sprint goals is. spending 1 week out of every two 'planning' is. aurguing about the proper number of story points for a given task is. incessantly arguing about how we can cut up the work so it it nicely fits into 3-4 stories per sprint or whatever management wants is. at some point the management narrative completely overwhelms the actual work at hand.
omg i forgot some of the even bigger ones. expecting me to squeeze in all the other parts of my job like mentoring new hires or meeting with product or responding to issues in prod without messing up your sprint schedule. or undermining my ability to make any plans longer than a sprint because that contradicts your desire to tell simple stories and interchange workers.
That perception that scrum is really distinguished from kanban in that makes it easy to generate estimates.
…and easy to make, totally wrong estimates, are exactly what people pretending to do agile can use to do their (doomed) waterfall design and release plans.
That’s not agile. It’s stupid.
If anyone ever tells you that you need to swap from kanban to scrum so that you can get good estimates, you’re basically doomed to a future of dark scrum.
I'm an overpaid consultant and I think scrum is easier to sell because it can be appealing to management as a selling point per se. Personally I strongly prefer kanban though.
One of the worst experiences of my career was having a terrible SAFe scrum master and their management team try to implement Kanban for my development team.
It somehow wound up being even more tedious and micromanaged than SAFe. I know that's the function the management, but it worries me when I hear someone think some new buzzwords will suddenly enforce careful planning and mutual respect.
I researched this like a decade ago and my conclusion at the time was that Kanban and Scrum kind of work the opposite way. Kanban is a "pull" approach where you have some kind of big goal you need (e.g. a car at toyota) and then all the dependencies (car parts and orders etc.) are pulled along with it into the pipeline (or todo list).
Scrum is "push" where small items are pushed into the pipeline (backlog) hoping the outcome is what is needed.
For an individual "worker" it's not that much of a difference, they have to work on the tasks anyways. The project might have different outcome / duration though.
I find that people sometimes enjoy getting lost in the minutia of processes. After all, it is a lot easier than actually solving problems and shifts responsibility to artificial things which employees tend to love.
I just asked ChatGPT "Can you please tell me the difference in Kanban and Scrum in 2 paragraphs?" It gave me a better answer:
Kanban and Scrum are both popular Agile frameworks used to manage and improve work processes, but they have distinct differences in their approaches and practices. Kanban, originating from the Toyota Production System, focuses on visualizing work, limiting work in progress (WIP), and improving flow. It uses a continuous flow model, meaning tasks are continuously added and moved through stages such as "To Do," "In Progress," and "Done." Kanban emphasizes flexibility, allowing teams to pull work as capacity permits rather than adhering to fixed iterations. Its core principles include visualizing the workflow, managing flow, making process policies explicit, implementing feedback loops, and evolving collaboratively.
On the other hand, Scrum is a structured framework that uses fixed-length iterations called sprints, typically lasting two to four weeks. It defines specific roles such as the Scrum Master, Product Owner, and Development Team, and ceremonies like Sprint Planning, Daily Stand-ups, Sprint Reviews, and Retrospectives. Scrum emphasizes delivering a potentially shippable product increment at the end of each sprint. It promotes regular inspection and adaptation through its iterative cycles, aiming for continuous improvement and fast delivery of valuable product features. While Scrum prescribes a clear set of roles, events, and artifacts, Kanban is more flexible, allowing for the integration of its practices with other existing processes without requiring significant changes to the workflow structure.
This article is a pile of crap and no one should take it seriously.
> These methods often rely on cross-functional teams, where individuals with diverse skills work together to achieve project goals.
That is absolutely wrong. Scrum treats all developers as homogeneous. Any developer should be able to take on any story, and story points don’t change based on who is doing the story. There is nothing “cross-functional” about scrum, it is literally the opposite of that.
This article is jam packed with so many cliches that are popular with business writing that you would be forgiven in thinking that an LLM wrote it, things like “popular choice”, “making roles and responsibilities clear”, “high-quality work”, “ super adaptable”, “get excellent results”, “intuitive workflow”, “fast-paced nature”, “ finish high-quality projects”
> Our tool's "Sprint" feature allows work to be displayed on sprint boards
Ah, there it is, they’re selling something. But what are they selling?
> 'Earned Value Management' could be employed. It's a systematic project management process used to find variances in projects based on the comparison of work performed and work planned.
Look at the word “systematic”, they’re advertising that scrum teams can be compared to each other, despite the fact that the scrum guide says scrum teams cannot be compared to one another.
Leiga is selling project management software, but what they’re really selling is complacency to project managers. What this software will allow your boss to do is, instead of talk to you about your project, they can look at how many points you closed out in the last two weeks and then decide to throw you a pizza party or fire you. They’re selling socially acceptable complacency. They say to project managers, instead of doing your job, you can stay ignorant with our metrics, scale, and not work hard at all. That is a very compelling value proposition.
> They say to project managers, instead of doing your job, you can stay ignorant with our metrics, scale, and not work hard at all. That is a very compelling value proposition.
I think you accurately portrayed any agile process I've ever dealt with. It was all about the public dashboard with stats that compared teams and closing tickets and reporting time in a pace to make the burndown chart smooth. Superficial and artifical metrics.
I am so glad the place where I work now have the traditional 'plan abit then do stuff' process. We use Jira, but it is fine. It is just a mediocre tool which get the blame for the management's failure.
I see lots of comments about how awful Scrum is. In the comments it appears they are from people working on projects directly for their employer. Scrum's greatest value is for teams that are not directly employed. For example a contractor or consultancy. It's value is to align both parties to work towards providing the most value without having to deal with the up front cost and negotiation of fixed bid projects (and the buffer that is almost universally baked in to the price). Yes, it can be abused by the consultancy to continue to bleed the customer but if used in good faith usable software or value (able learnings/knowledge) is delivered at the end of the sprint. Then the customer can make a better informed decision on whether to continue on and/or what to work on for the next sprint (because they believe it will deliver the most value now).
Using Scrum and sprints to break a larger and fully committed project into small chunks can and will slow progress down due to the increased overhead and time consumed by sprint rituals. Use kanban for that instead.
Many different definitions might just as well add mine.
Kanban is a method and Scrum is a process.
In a way that Kanban isn’t per se defined in time. It’s about how work is pulled (work in progress limits, just in time work prioritization) and presented (famous work board).
Scrum on the other hand is a time bound process. It creates cycles, sprints and ceremony. Kanban can be part of this process or not.
To provide simpler analogy - Kanban is a cake baking recipe and scrum is cake distribution process.
Kanban: See tasks that need to be done, do them and drag them to done.
“Scrum”, has turned into a ridiculous mess of meetings and estimation when we’re always bad at estimating. Then there’s the attachment to the “two-week” sprint and velocity blah blah blah.
If you are exploring Kannan vs scrum, you’ve already failed before you even started.
First, what you are trying to do? Is it a big ambitious multi year project or even mid size which has a lot of modules? Then first you need to assemble a core team - PM, PO, Architect, Sr Engineer - and get the core components built to some extent or laid out clearly, before trying to find a suitable development strategy. In scrum, you should be ‘only’ integrating components and not developing, just like the assembly line.
A method is a way to structure so "processed" or industrial activity. It may use some tools or none. When it uses tools, these tools are more specified by their inputs/outputs (so how they contribute to the achievement of the goal) that to how they operate.
More specifically:
- Kanban can be used outside of the SCRUM methodology. For example, nothing forbid to use Kanban in a Waterfall IT project during the implementation phase to track tasks progress
- SCRUM may use Kanban or some other equivalent tools to organise and track the differents tasks
However, both are historically associated (even if I guess that Kanban came from Toyota and the automotive industry, using lean and not "agile" or SCRUM)
One of the things I don't understand about the HN crowd is how adamant the typical HN'er is about having good commit messages, and follow a strict merging paradigm, such as peer reviewed pull requests, with lot's of room for discussing minute details of rebasing versus merging with or without squashing.
But when it comes to a shared to-do list across a team, then that is apparently the worst thing to ever happen to a project.
I think it is pretty nice to have a place where we can all see what needs to be done, and how far along we are, and I think it is a pretty good idea to regularly review what in the to-do list we want to focus one. I don't think the core of scrum or kanban is bad, but I do think it drowns in managers who want to visualize and predict progress above actually pushing for progress.
There are several ways in which it's bad. Forcing all the work to fit into sprints, for instance.
What if the natural way to divide the work results in some chunks that probably don't fit? Normally you'd just do them and it's be fine, but "we're doing Scrum" so now they have to be divided further and the parts have to be developed separately, even if that makes no sense.
Also Scrum assumes things -- that the product owner is very competent, that dev teams are self managing, that the business is interested in updates in the same frequency as the sprint -- that aren't necessarily true.
And everything that goes wrong is blamed on Scrum not being done exactly to the letter. So nothing else is fixed and everybody is more and more focused on doing Scrum ceremonies precisely right even if that was never their intention.
>There are several ways in which it's bad. Forcing all the work to fit into sprints, for instance.
That's misusing it. The sprints are just forcing regular meetings to assess progress and make changes if necessary. There's no reason to absolutely force everything to get done in 2 weeks. If something doesn't get finished in a sprint, discuss what happened in the biweekly meeting and if any changes need to be made, and then move it to the next sprint.
I believe the SCRUM rejection comes from the direct experience of working in a team that uses it, and eventually realizing that all of the meetings and concepts because an end in itself. SCRUM usually degrades to more discussions about story points than about what is being built.
I think this is just an example of the fact that any tool can be misused or used poorly. I used scrum at my last employer, and it worked quite well. But we didn't use it stupidly; it was just a tool to keep track of what we were working on, and plan what we were going to work on next, that's all.
Sure, we had some discussions about story points, but they were quick. When we had to assign story points to a task, we'd all use story point playing cards (they have the typical Fibonacci sequence story points printed on them: 1, 2, 3, 5, 8, 13, 20) and turn them over at the same time to basically vote on the points. If there were any large disagreements (one person voting 1 while everyone else votes 8 for instance), we'd stop and discuss why that person thought it would be so much more or less effort. Usually, 30 seconds of discussion would clear up the disagreement and we'd move on to the next task. The whole meeting would last less than 1 hour, and was held every 2 weeks. And I think it had a secondary benefit: it got us all in the room together to just talk to each other as team, instead of just sitting in front of our computers and not talking to anyone, which was our usual activity. Social interaction is good for people.
If someone votes 1 while the others votes 8, he’s either too optimistic or an expert on that subject. The points themselves don’t matter, because things are either hard or easy, and that usually depends on the person doing it. No committee can decide that. And they will either get done or cancelled any way. The only things that really matter is their current priority. And that’s the business decision (influenced by several factors, including the advices of the devs). The points assignments are thus useless and you’re spending 1 hour every two weeks on it. But if it makes everyone happy…
And as for talking as a team, we can just do it without any other excuse than discussing the project and the methodologies.
The points assignment wasn't useless; it was just for tracking relative difficulty. Some tasks were trivial, only taking a couple of hours, so they got a "1", while other tasks were projected to take 2 weeks, so those got an "13". The idea was to pick a bunch of tasks that were basically do-able within the 2-week sprint, and ignore the rest, so while 1 dev might take on a 13-point task and nothing else, another dev might take a bunch of 1s and 5s. And yes, the priority had to be factored in too, which was influenced by both customer requests and dev input (i.e., "this is super easy and I can have it done today" or "this is difficult and will take a month").
>And as for talking as a team, we can just do it without any other excuse than discussing the project and the methodologies.
You can, but no one actually does it in practice. Individual team members might chat together from time to time, but putting everyone in one room together forces them to interact with all their other team members and talk about real work-related stuff, instead of just hanging out with their one buddy and talking about something irrelevant.
> But when it comes to a shared to-do list across a team
That would be Kanban.
> then that is apparently the worst thing to ever happen to a project.
Naah: The worst thing to happen to a project is all the rituals, ceremonies, processes, meetings, estimations, deadlines... That it also contains a shared to-do list isn't enough of a saving grace, seeing as how you could have the shared list without all the other bumf.
It’s a shared to-do list with a biweekly meeting to review and cleanup the to-do list, a biweekly meeting to select items to be worked on in the next biweekly period, and a biweekly meeting to discuss how the last biweekly period went. And a daily update meeting.
Exactly this. When I used it, that's exactly how it was, and honestly it was great compared to the utterly chaotic and disorganized method of organizing work I've seen in other workplaces.
It seems like all the people who absolutely hate it worked in dysfunctional places that completely misused the tool, or treated it like some kind of religion.
> how adamant the typical HN'er is about having good commit messages, and follow a strict merging paradigm, such as peer reviewed pull requests
That’s communication, and sometimes a protocol helps nicely in getting the relevant information out of the medium. Especially when the communication is async as everyone knows roundtrips is bad.
> with lot's of room for discussing minute details of rebasing versus merging with or without squashing
That’s geeky time out of work. When doing it, we know that we’re not working.
> a shared to-do list across a team
The shared list is not the issue. It’s what happens to the items inside it. Scrum make us work more on the item organization than what it’s worth. Then they get arranged into something that doesn’t really matter (sprint), and then we are judged on that. While we just want to get things done.
Both are a hot mess in practice. I could imagine a scenario where this ‘flexibility’ in not knowing what you’re building ahead of time may be valuable but I’ve never lived one. I’d rather think it through?
I like modified Kanban boards, both when startup is in reactive mode, and as an alternate view of a really good Gantt model when I'm doing serious planning for less-reactive hitting of deadlines and synchronization points.
But if I were an agency doing hourly billing of clients who didn't know what they wanted, I would like Scrum. "C'mon, give us a straight answer to our questions, we're locking you into that for another 300 billable hours. Then you can pull other answers out of your behind in a week. We'll call it participatory design, or interactive, or something, and pretend it's that it's because this is the most efficient way to solve hard problems, or to be flexible at the superfast speed of business. But really it's because you are bad at what you do, and just pretending, so we decided you'll pay my firm 300 uninterrupted billable hours per week as your penance. I'm thinking of scaling up my team, so that we can bill-- uh, execute, faster."
Ehm, it's the opposite: kanban was the ancient Toyoda system to produce mechanical parts in Toyota factories. Scrum is a way to adapt such model to the commercial IT.
Both are used by nazi ignorant management who fails to comprehend the difference between a factory that mass produce already designed and tested parts vs the production of software.
You know, today we talk about nazi and fascist because their model is back. Simply. Some fails to recognize it, as fails to recognize it's economical and philosophical origin, so think the others are crazy. Happen frequently.
The tendency to exaggerate small things is also a normal part of this process, because our society start to fracture, things became tough and so anything is seen as a giant thing.
It's not different anyway than the various plethora of managers who attend "schools of management" learning essentially a kind of religion and apply it in their life as a religion, failing to see that. We have on the records stuff like some real estate C-levels hospitalized due to feet burns because at a team building events they have marched on a carpet of hot coals [1] and others in the Nederland who get hospitalized for serious concussions because they have play to drop themselves in the arms of their colleagues... What do you classify such hilarious extreme episodes? They are rare of course, but not so rare, and even without certain outcomes they show a certain approach.
Well, kxfx whom you replied to was the OP in this thread. And according to their other top-level comment[1], that seems to have been pretty much exactly what they were talking about. (Yeah, a bit far-fetched IMO too.)
Get a group of competent developers, say about five in a team. Trust them. Let them work with the stakeholders to figure out what needs building, and let them build it.
I propose to erase the development in Silicon Valley Mode and ALL the modern IT.
I propose to came back and makes modern a classic OS-as-a-single-application, like Smalltalk workstations or LispM ones, where desktop computing and end-users programming are at the center so ANYTHING simple is damn simple, anything complex is doable and we do not reinvent the wheel every time because in modern systems there is no possible substantial integration so any apps try to be an "everything app" and anyone pull a gazillion of third party dependencies because there is little time and no common base.
This will be a long journey we have to live anyway because current infa are nearby a self-explosion point, as is the current social order but before we did less hard it will be.
I've become convinced that the first widespread software methodology is still the best one: PRIDE (Profitable Information by Design).
You probably haven't heard of PRIDE. It's on the verge of being lost to time. But the principles behind it have driven successful software projects for about 70 years now. It was originally released in 1971 by Milt Bryce through his company, Milt Bryce & Associates, based on Milt's experience leading major software projects dating back to UNIVAC in the 50s. Milt's son, Tim Bryce, continued to market the PRIDE methodology and materials until recently.
The thing about PRIDE is how comprehensive it is. It encompasses business analysis, business process design, database design, and software design and development; and every artifact from single requirements to code changes is given a tracking number (decades before JIRA or Git, and these numbers were at first tracked on paper!). It's not really focused on developing software but the design and construction of business systems. Computers are only a part of the overall puzzle, and programmers have a tendency to fixate on just that part and not see the big picture. What PRIDE provides is a framework for understanding the business as a whole, the information needs of the various business systems, and how to design procedures to be executed (by human or computer) to fulfill those needs. It starts with a comprehensive systems analysis phase (undertaken by systems analysts -- not programmers -- which profession has also been nearly lost to time) followed by an in-depth design phase. A common vocabulary is developed so that the business people and programmers can communicate in plain English. The database is also designed based on this vocabulary; in fact Milt Bryce was also the inventor of the concept of a "data dictionary". Then the software is designed, its design thoroughly documented, and then it's implemented by the programmers.
Compared to Scrum and Kanban, it's very waterfall-like and involves a lot of big design up front. That's a feature, not a bug. The solution to not knowing what your requirements are is to figure that bit out first and make sure the programmers have very clear goals before they write a single line of code -- not to put programmers in the driver's seat and have them make guesses at an implementation until the stakeholders say "yeah! That's it!" That means bringing systems analysts in and having them identify the systems, what data they consume, and what data to produce.
I think that PRIDE-like methodologies are going to be the future of software development, especially in this post-ZIRP era where the money is attracted to profitability, not the latest Silicon Valley fad. I've never been on a Scrum team that delivered on time or under budget. What's needed is more thought up front, and more discipline and accountability built into the process.
Where Scrum wiggles its way into relevance is schedule. Most businesses need to be able to commit to some deadline with customers or coordinating teams, and scrum lets managers convince themselves that they can project 3-6 months of work into sprints.
The reality of course is that the requirements and deadlines are constantly moving and never match what was predicted, but you need _some_ prediction to coordinate large projects. So scrum just ends up being a hack to generate time pressure on the component tasks.
What's the right solution? So far in my life it comes down to Kanban and focus for engineers, plus an experienced leader that can guess reasonably well, pad for uncertainty, and renegotiate requirements to make that guess come true.