Agile vs Kanban: Which is Better? • Dave Farley • GOTO 2022

We’re so pleased to announce that we’ve teamed up with Dave Farley, author of “Continuous Delivery” and frequent GOTO Conferences speaker, for a monthly video series featuring ideas about continuous delivery, DevOps, test-driven development, BDD, software engineering and software development in general.
Find plenty more from Dave on his Continuous Delivery KZbin channel: / @continuousdelivery
Dave Farley - Continuous Delivery & DevOps Pioneer, Award-winning Author, Founder & Director of Continuous Delivery Ltd.
ABSTRACT
Which is better Agile or Kanban? Actually, it's not quite that simple. Agile development and Lean, where Kanban comes from, are both related approaches to software development. Agile project management guides us to work in chunks, called Scrum Sprints or Iterations, Kanban also aims to work in smaller steps. So what is agile, what is Kanban? What is a Kanban board and how does it work? Is it Kanban vs Scrum, Agile vs Kanban or something else? What are the similarities and what are the differences? What things should we focus on to do the best job that we can?
In this episode, Dave Farley explores both of these ideas and explains the benefits, and drawbacks of each. If our aim is the Continuous Delivery of valuable software into the hands of our users, what is the best way to organise our work to achieve that?
CD TRAINING COURSES
If you want to learn Continuous Delivery and DevOps skills, check out Dave Farley's courses
bit.ly/DFTraining
RECOMMENDED BOOKS
You can grab Dave Farley's new book 'Continuous Delivery Pipelines' here:
leanpub.com/cd...
David Farley • Modern Software Engineering • amzn.to/3GI468M
Dave Farley & Jez Humble • Continuous Delivery • amzn.to/3ocIHwd
/ gotocon
/ goto-
/ gotoconferences
#GOTOxDaveFarley #Programming #Agile #Kanban #Lean #AgileDevelopment #CD #ContinuousIntegration #DevOps #DaveFarley #GOTO #GOTOcon #ContinuousDelivery
DAVE'S LINKS
www.continuous...
/ davefarley77
www.davefarley.net
Looking for a unique learning experience?
Attend the next GOTO conference near you! Get your ticket at gotopia.tech
SUBSCRIBE TO OUR CHANNEL - new videos posted almost daily.
www.youtube.co...

[@timgwallis]

I’m 0:05 seconds in and this is a year old, but I must scream that KABAN IS AGILE!!! Dang does this video title trigger me…. Agile is a philosophical approach to work delivery that can be summed in: -Iterative & incremental delivery of small batches of customer value -Tight inspect & adapt feedback loops for learning Scrum is ONE framework for actualizing this philosophy. Kanban is another. And there are indeed and infinite # of ways to actualize the philosophy; some are just more defined than others.

[@farjumper]

The video is weirdly titled. "Vegies vs Tomatos, which are better". Did author mean Scrum vs Kanban?

[@tamashbeen6610]

Snake oil being sold.

[@psingh007]

Agile is an umbrella term that also covers Kanban and other techniques and methodologies.

[@mwildam]

That is funny, my favorite way of working evolved over the years is pretty much the same as your favorite way. And as I do follow your channel only since a year or so, I can say that I came to the same conclusion independently. I see that as an even stronger confirmation, that I am doing it right.

[@damaddinm88]

Cherry picking from both. I love it :). And I think our team is already doing that. Thanks for the nice video :) !

[@michaelslattery3050]

Cherry picking FTW. I've never been comfortable with how scrum sprints tend to end. It's often messy and stressful. On my last team we used KanBan with a retrospective/planning meeting every 2 weeks, almost identical to Dave's spin on it. Afterwards, we went out for a long casual team lunch.

[@rkd80]

I really like the refinement/grooming aspect of scrum, even if I tell my devs to ignore the value of the points and focus on discussion. How does refinement work in Kanban? Can anyone point me to a good example?

[@denfete8321]

I think you wrong. You're talking about Agile just like it would be Scrum. Agile is a mindset not a framework base on 4 values and 12 principals.

[@LukePuplett]

Agile teams don't have to track velocity or estimate anything or work in iterations of fixed scoped work. They can do what they like as long as the team lives by the values of the manifesto, which are very plain. The easiest way to envision an agile team is a team that's never worked in an office, perhaps two children building an app for the first time, doing whatever makes the most sense, getting feedback from a user or a parent perhaps, and then running back to their bedroom to work on it some more. Agile teams work how you'd work if you worked alone! Because when you work alone, you just do what works.

[@vivekparmar7576]

In theory, I get what you're saying, but you need to be able to measure velocity or 'progress' in some way, so that you can have a relatively accurate prediction of the overall timeline. Also, if you don't track velocity, how do you track performance? Do you use another metric?

[@LukePuplett]

@@vivekparmar7576 Software makes progress by being useful to its users and valuable to a business or ecosystem. The things you need to measure are in the software's ability to drive outcomes. Is your product helping? In any creative or deep work, there is no such thing as productivity and nothing to measure. Consider someone who sits around all week but comes up with an idea that makes 10M a year in revenue. Or someone who simply has different but crucial life experiences that matter for the product you're building? What number or chart is going to help you? There's also no point in estimating work, estimates are always wrong, but simply, if something is worth doing over another thing, then it's worth doing. No numbers are needed. Again, imagine working alone. Would you estimate a backlog? No. You'd use your expertise to know if you need to do something, whatever it is. All this tracking and velocity nonsense is for non-technical people to remain in control of the people with the skills. Those days are over. Look at how the CEOs of the biggest companies are highly technical people now. Obsessing over internal measures, being inward focused, is also a sure sign you're too far from the customer. It's why big old enterprises esp. in traditional services sectors are the most toxic. If you're really close, you'll obsess over solving users' problems and delighting them and not measuring each other.

[@tombaldwin107]

@@vivekparmar7576 "Working Software is the primary measure of progress", "Working Software over Comprehensive Documentation", "Business people and Developers must work together daily", "...Face-to-face conversation" etc Where does any of that mention Metrics or Dashboards or Velocity or Sprints or Throughput or Cycle Time or Lead Time or Takt Time or User Stories or Features?... Nowhere If the customer is not happy with it and it's not working, your software has no value. Valuable software is what matters. Now, a common Scrum 'beginner mistake' is to confuse the Sprint Goal with the Sprint Backlog... Remember, the customer really couldn't care less how many User Stories you broke the work down into or how many Story Points you rated it at, all they care about is if the software works and how Valuable it is.

[@LukePuplett]

@@tombaldwin107 👏

[@vivekparmar7576]

​@@tombaldwin107 I agree that software has to be usable, which is why we focus on engineering excellence to create the product right. My question wasn't about the philosophy or the what/why about making software, but rather the how. The video is talking about which process/methodology is better - and if we are trying to choose something that's "better", it is because we are looking for an improvement in a specific area. My question is simply on how to measure that improvement. Regarding your comment on sprint goal/backlog, I was looking at it from an even higher level in being able to measure performance at some level - what is it? I understand that the customer doesn't care about user stories etc. etc. - but the customer does care about timely delivery of software. That's where my question was coming from.

[@jeanjasinczuk7543]

The video should be more accurately call Scrum vs Kansan. The main wrong trend on Scrum is that sprints can become a mini waterfall iteration. The sprint planning sets in stone what should be done, even though that the time one know the least about what to do. There are reluctance to drop/replace user story when in the middle of the sprint they can become irrelevant. There is an assumption that the sprint should predict the amount of work needed for a user story and the team "commits" to it. Some user story are revealed to be a lot more complex than anticipated. And to avoid that, the workaround is to create an analysis/write spec user story in one sprint and implement in the next sprint.. and the full test suite for the sprint after. At that point.. waterfall just came back!

[@radekcrlik5060]

Wow, big plus for the Serenity T-shirt :D

[@psingh007]

Kanban is a signal of available capacity to pull in work from the backlog.

[@LukePuplett]

Agile is not a set of practices. This is a false dichotomy. An agile team might choose kanban, because they are self organising. Agile is a set of values, not practices. Nothing about agile is a set way, in fact is agile is the absence of set ways. That's why it's such a failure; it's nebulous and hard to grasp for process and control obsessed corporate workers.

[@adambickford8720]

In practice it is, at least at any "enterprise" I've ever worked at over 20 years. You must do all the ceremonies, etc. even if it's nonsense. We constantly make elaborate plans as demanded by our company, yet 'pivot' usually within a day or 2. They tell us we can do kanban, as long as we can predict our deliverables for the next 3 months lol!

[@LukePuplett]

​@@adambickford8720 I agree, Adam. It's been the same in all the teams I've worked in, bar one, and the time I worked alone! I've even been guilty of bringing in practices that I thought were agile, before I knew any better. Any ideas I brought in were weaponise as better tools of micromanagement. 99% of corporations are a lost cause, and that 1% is mostly in California. Even new start-ups are run by the same people who just repeat what they know. Anyway, I think it's really important to call out faux agile and the myths of what agile is, if our craft ever stands a chance. I also think it's important we starve non-technical Victorian workhouse companies of vital software talent and hurry along their demise.

[@dilietol]

Scrum is a set of practies, Agile is a set of values. In the video he should use the word scrum instead of agile.

[@tombaldwin107]

I was going to say much the same, @Luke. I know this presentation is trying to be helpful, but videos like this often do more harm than good. Misinterpretations and misunderstandings are presented as hard&fast rules. Seems to confuse Scrum with Agile; Kanban with Lean, etc. The only stipulation (from the 12 principles) is that Agile requires a team; Kanban - either Ohno’s or Anderson's - does not. Agile makes no reference to iterations or ceremonies or working practices

[@LukePuplett]

@@tombaldwin107 Thanks Tom. Completely agree and you're right to acknowledge that the presentation means well. I can come off as rude quite often :-/

[@hudsonxperiences7953]

Choosing scrum or kanban without considering the team's level of maturity and autonomy doesn't work. Kanban is good for known types of tasks, such as work in manufacturing, but when it's applied to software development it will require more estimation and planning because the tasks are not repeated. If you want to have predictable delivery when using Kanban then you need to fix the cycle time, say 2 weeks. When you have time limitations the developers need to carefully analyze and estimate the work they can accomplish. If there are too much unknown stuff, Kanban NEVER works for sure. If the team works in a complex software where different sets of features needed to be released at different times, kanban doesn't give you a good view of team progress. It's not to mention that it's difficult for each member to align their work with others and know which branch should they commit the code to. The only scenario in software that kanban work is not software development but software maintenance.

[@mwildam]

I cannot see a clear seam between software development and software maintenance. But I agree with you, that the team's level of autonomy has a big influence. But the same applies for Scrum way. If many need help from others, this also affects the effective performance. But what stops you from asking the others for help if you are working the canban way? I see estimates going so completely wrong, especially when you face new challenges and I cannot see how any length of cycle time can be better than just looking on the item progress in the backlog.