Kanban vs. Scrum: What's the difference?
leiga.com
leiga.com
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.
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.
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.
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.
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.
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.
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.
Yeah, sure. The Kanban board.
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, everything has cost, timeline, and quality requirements, but the way they are represented or discussed vary a fair bit.
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.
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.
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.
"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.
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.
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.
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)
Ok, let’s make that „all places“.
And Agile in general.
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!
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.
[1] agendashift.com/done
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.
It doesnt work but it's pretty amenable to charging consulting fees.
Scrum is just... ritual.
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.
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.
If you have a project manager in Scrum, you're not doing Scrum.
If you have sprints in Kanban, you're not doing Kanban.
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.
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.
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.
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.
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.)
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.
You can do bad things with any process, just some make it easier to the the bad things.
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.
[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.
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.
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.
But scrum inside a business is pretty much a nightmare scenario.
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.
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.
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".
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.
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.
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.
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.
You know what’s true in this article?
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.
Run!
scrum - awful, mismanagement, micromanagement, useless meetings, overpaid consultants
- No ritual meetings
- No sprint (aka fake deadlines)
- No story points (aka useless productivity proxy)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.
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.
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.
> 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.
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.
Almost harder to forgive not thinking that an LLM wrote it...
Scrum is Jack Welch.
Kanban is Demming.
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.
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.
“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.
It’s usually always frustrating.
I prefer Kanban.
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)
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.
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.
And as for talking as a team, we can just do it without any other excuse than discussing the project and the methodologies.
>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.
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.
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.
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.
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.
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.
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."
Citation needed
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.
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.
10 years ago, I was complaining people used amazing, friend, hilarious and other superlatives to talk about mildly better ordinary things.
Today I see people throw in fascist and nazi like darts at a pub night.
The noise/signal ratio is really getting terrible.
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.
[1] https://www.pmi.it/professioni/strategie-e-tecniche/196632/a... sorry, I can't find the news in English. It happen years ago in Italy
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.
The current PRIDE book, PRIDE Methodologies for IRM: https://www.amazon.com/PRIDE-Methodologies-IRM-Tim-Bryce/dp/...
Tim Bryce's PRIDE web site: http://www.phmainstreet.com/mba/mbapride.htm
Old vid of Milt Bryce explaining PRIDE and ASDM (a suite of project management tools based on PRIDE written in COBOL): https://www.youtube.com/watch?v=SoidPevZ7zs