[HN Gopher] Kanban vs. Scrum: What's the difference?
___________________________________________________________________
Kanban vs. Scrum: What's the difference?
Author : Bryan_YU
Score : 49 points
Date : 2024-07-04 09:36 UTC (13 hours ago)
(HTM) web link (www.leiga.com)
(TXT) w3m dump (www.leiga.com)
| pestatije wrote:
| scrum: old buzzword...kanban? whatever, new buzzword in the
| making
| andreiursan wrote:
| buzzwords and view/board settings in Jira
| naravara wrote:
| I think kanban boards are actually older.
| Feeble wrote:
| Kanban predates scrum
| kkfx wrote:
| 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.
| bitwize wrote:
| What do you propose instead, if the standard ways are used by
| Nazis?
| kkfx wrote:
| 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.
| Scarblac wrote:
| 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.
| BiteCode_dev wrote:
| When people say words are losing all meaning, this is what
| they mean.
|
| 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.
| kkfx wrote:
| 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.
|
| [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
| BiteCode_dev wrote:
| I don't think op was referring in any way to
| pangermanism.
| totallywrong wrote:
| The difference is that Kanban won't require a million useless
| meetings and will actually help you plan and get stuff done.
| antupis wrote:
| 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.
| zuppy wrote:
| 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.
| pydry wrote:
| >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.
| JasserInicide wrote:
| _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.
| sgarland wrote:
| 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.)
| Ensorceled wrote:
| The worst place I every worked as far as useless meetings went
| was a Kanban shop.
|
| You can do bad things with any process, just some make it
| easier to the the bad things.
| wodenokoto wrote:
| 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.
| whimsicalism wrote:
| scrum is much more than "a shared to do list". organizations
| that self-identify as adopting "scrum" are the most
| dysfunctional i have ever worked at
| pydry wrote:
| I dont remember anybody ever objecting to a shared to do list.
| bluepizza wrote:
| 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.
| yungporko wrote:
| if it were just a shared to-do list, that would literally be
| kanban
| wodenokoto wrote:
| It's a shared to-do list with a biweekly meeting on the list,
| and a daily update on if things are on track or someone needs
| help.
| Scarblac wrote:
| 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.
| skydhash wrote:
| From what I've seen, Kanban has: - No ritual
| meetings - No sprint (aka fake deadlines) - No story
| points (aka useless productivity proxy)
| whimsicalism wrote:
| kanban boards - useful, easy to understand, help coordinate work
|
| scrum - awful, mismanagement, micromanagement, useless meetings,
| overpaid consultants
| v7n wrote:
| 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.
| haunter wrote:
| I just leave the "I want to run an agile project" video here
| https://youtu.be/4u5N00ApR_k
| FrankSansC wrote:
| There's also Scrumban :
| https://en.wikipedia.org/wiki/Scrumban?wprov=sfla1
| fendy3002 wrote:
| 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.
| pydry wrote:
| It was designed as training wheels for agile but it ended up
| creating a performative form of cargo cult agile.
|
| It doesnt work but it's pretty amenable to charging consulting
| fees.
| cmrdporcupine wrote:
| 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.
|
| Scrum is just... ritual.
| oriolid wrote:
| > 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.
| largbae wrote:
| 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.
| Ensorceled wrote:
| > 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.
| givemeethekeys wrote:
| Scrum starts at the management level.
|
| 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.
| Spivak wrote:
| 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.
| elzbardico wrote:
| Scrum is a set of prescriptions. Kanban is more of a phylosophy
| of production management.
|
| Scrum is Jack Welch.
|
| Kanban is Demming.
| darreninthenet wrote:
| 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
| Xenoamorphous wrote:
| 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.
| siva7 wrote:
| > Just give me a list of prioritised tasks.
|
| 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.
| BlackFly wrote:
| 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.
| Xenoamorphous wrote:
| > 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.
| inSenCite wrote:
| 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.
| osigurdson wrote:
| >> which has really changed how people work
|
| Citation needed
| olivierduval wrote:
| I always thought that Kanban is a tool and SCRUM is a method.
| Scarblac wrote:
| What's the difference?
| nprateem wrote:
| The difference is when you use kanban someone suggests switching
| to scrum, and vice versa.
| _heimdall wrote:
| 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.
| vundercind wrote:
| 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.
| asplake wrote:
| 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.
|
| [1] agendashift.com/done
| katzenversteher wrote:
| 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.
| wokwokwok wrote:
| It makes me laugh.
|
| 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!
| osigurdson wrote:
| 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.
| vegetablepotpie wrote:
| 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.
| bitwize wrote:
| 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.
|
| 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
| jmartin2683 wrote:
| 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?
| fancyfredbot wrote:
| 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.
| xedrac wrote:
| 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.
| kriiuuu wrote:
| 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.
| nickd2001 wrote:
| 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.
| dasil003 wrote:
| 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.
| mikedelfino wrote:
| Do you mean kanban is a better fit for what you're describing
| or something else entirely?
| deaddodo wrote:
| 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)
| kanbankaren wrote:
| Can I talk to your manager, please?
| neilv wrote:
| 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."
| Smeevy wrote:
| 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.
| cholantesh wrote:
| Quite like the difference between metal and visual kei, "Kanban
| is good, that's it!"
| mandeepj wrote:
| 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.
| smashedtoatoms wrote:
| 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.
| yobid20 wrote:
| 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.
| xlii wrote:
| 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.
___________________________________________________________________
(page generated 2024-07-04 23:02 UTC)