Is AGILE Better Than KANBAN?

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?
-------------------------------------------------------------------------------------
📚 BOOKS:
📖 Dave’s NEW BOOK "Modern Software Engineering" is now available on
Amazon ➡️ amzn.to/3DwdwT3
In this book, Dave brings together his ideas and proven techniques to describe a durable, coherent and foundational approach to effective software development, for programmers, managers and technical leads, at all levels of experience.
📖 "Continuous Delivery Pipelines" by Dave Farley
paperback ➡️ amzn.to/3gIULlA
ebook version ➡️ leanpub.com/cd-pipelines
📖 The original, award-winning "Continuous Delivery" book by Dave Farley and Jez Humble
➡️ amzn.to/2WxRYmx
-------------------------------------------------------------------------------------
Also from Dave:
🎓 CD TRAINING COURSES
If you want to learn Continuous Delivery and DevOps skills, check out Dave Farley's courses
➡️ bit.ly/DFTraining
📧 JOIN CD MAIL LIST 📧
Keep up to date with the latest discussions, free "How To..." guides, events and online courses. ➡️ bit.ly/MailListCD
-------------------------------------------------------------------------------------
🔗 LINKS:
Agile Manifesto ➡️ us02web.zoom.us/j/83511828541
Kanban Explained ➡️ en.wikipedia.org/wiki/Kanban_...)
-------------------------------------------------------------------------------------
CHANNEL SPONSORS:
Equal Experts is a product software development consultancy with a network of over 1,000 experienced technology consultants globally. They increase the pace of innovation by using modern software engineering practices that embrace Continuous Delivery, Security, and Operability from the outset ➡️ bit.ly/3ASy8n0
Harness helps engineers and developers simplify and scale CI/CD, Feature Flags and Cloud Cost Management with an AI-powered platform for software delivery. ➡️ bit.ly/3Cfx3qI
Octopus are the makers of Octopus Deploy the single place for your team to manage releases, automate deployments, and automate the runbooks that keep your software operating. ➡️ octopus.com/
SpecFlow Behavior Driven Development for .NET SpecFlow helps teams bind automation to feature files and share the resulting examples as Living Documentation across the team and stakeholders. ➡️ go.specflow.org/dave_farley

[@KyleMaxwell]

I feel like we're saying "Agile" here when we mean "Scrum" - Scrum is just one method (albeit likely the most popular) to work in an agile fashion.

[@errrzarrr]

Most of the "Agile manifesto" oroginal signers agree Scrum is not Agile.

[@grenvthompson]

@@errrzarrr i think that misses the point. They likely agree that most teams that profess to be doing scrum are not agile.... which is different than saying the process isn't, if it's done well the team can be agile. It's not unlike any process really, except Scrum is easy to do badly.

[@michaelrstover]

I like to call it Scrum-Jira, because the combo of those two things makes for a development process that seems to be all about separating me, the developer, from the bigger picture. Everything is a tiny disconnected chunk, and mentally escaping that box and seeing more wholistic view of my code is actually difficult. The result is my work becomes about "iteratively" jamming in new lines of code here and there without much regard to architecture.

[@jrf9735]

@@michaelrstover How would one solve that problem?

[@michaelrstover]

@@jrf9735Sometimes when I'm working in a sprint, I'm also perusing the backlog, and I will find stories that relate to where I happen to be in the code, and I'll just pull them in and be working them too. I should be able to do that. Helps me get back to a more whole conception of the project and the code. It also helps to stop trying always to break jiras down to smaller and smaller sizes. Let them be big. I'm still going to code incrementally, but I don't need my small steps pre-planned.

[@davidboeger6766]

There's absolutely no pacing inherent to either process, and I think that's a harmful self-perpetuating myth that unfortunately gets repeated by not just managers but otherwise very good Agile developers. Outside of maybe a few no-lifers who just code all day every day, I don't think the vast majority of developers (or humans in any field, for that matter) can or should sustain a steady pace of work indefinitely. This goes both ways. An overworked person will eventually burn out, and an underworked person will eventually take on more work for the stimulation, and I don't think any of those levels of productivity are necessarily set in stone and constant over the course of one's career. Almost everyone needs time for things like vacation, rest, family, outside obligations, and so on. Those obligations will vary greatly as developers get married, have kids, buy houses, care for sick parents, get injured, fall ill, etc. I keep hearing from both managers and development leads that one of the theoretical benefits of Agile development practices is the ability to sustain a healthy pace indefinitely, yet I've never actually seen this play out in practice. Inevitably, the business pushes to improve and inflate metrics by demanding more work, and the development leads promoting this supposed benefit are almost universally highly compensated architects and such who delegate much of the implementation work to others. As far as I can tell, pacing was never inherently good or bad under waterfall either. Companies just had different culture and compensation. Some demanded more work, ideally for more pay, while others were more protective of work/life balance. That seems to be true under Agile as well. You mentioned that kanban felt a bit too much like a treadmill, but as far as I can tell, kanban doesn't insist you put tight deadlines on each individual task. Nothing in kanban says you couldn't take a vacation or work a little more slowly on the next task. Meanwhile, I can tell you from recent experience that scrum is absolutely no picnic when management draws up a big dependency chart across teams and insists that there's absolutely no room to miss sprint deadlines without cascading delays. Expecting more sooner with less is not a problem of process, it's a problem of management culture. Developers pretending that Agile processes are a cure for crunch is just wishful ignorance. You can make any process feel like a treadmill turned to its highest speed by just imposing arbitrarily tight deadlines. I would argue that's against Agile principles, but that just gets into the whole can of worms about overloading terms and organizations confusing principles with recipes. I personally prefer Kanban, but I'm under no illusion that about my willingness or ability to produce consistent output indefinitely under any process. We're expecting our first child soon, and I promise you, my output then will not be the same as the weeks I've worked 100+ hours to meet some tight deadline because I wanted to do it for the good of the company. The sooner we can come to terms with the reality of human life, the sooner we can stop using new processes as excuses for bad management.

[@GalaxyCat001]

And of course a term like 'Sprint' has in it the inherent idea of max performance. But whereas in a real sprint you then rest after having run at 100% capacity for a distance, in dev work 1 sprint is then followed on immediately by the next etc. The official & unofficial term should be iteration and nothing more.

[@shugyosha7924]

@@GalaxyCat001 Great point

[@michaelnurse9089]

I think you are missing the whole point. Overloading employees is a discussion separate from whether you plan your work 'top-down or bottom up' which is what the whole agile/kanban/waterfall discussion is all about. Of course, the get conflated because planning can be come a tool of corporate dysfunction. Hard scientific evidence shows that after a couple hours employees start to actively harm results by just being there. Errors, boredom, resentment, waiting for info/meetings. If one is willing to throw away your life by working for Evil Corp then no amount of agile/kanban/waterfall is going to save you from its clutches.

[@seandavies5130]

I agree, the sooner people stop acting like a rabid cult re. Agile/scrum, pretending they are panacea for every project, the better. Particularly, the idea of sprints and the problems they introduce. Maybe if you are doing something well understood and basic, but not for anything complicated

[@davidboeger6766]

@@michaelnurse9089 I'm not missing the point, I agree that they're separate concerns. The point I was making is that many advocates of Agile pitch it as a way to achieve a pace that is sustainable indefinitely with good work/life balance, which as you and I both pointed out is inherently untrue. Any plan, whether top-down or bottom-up, can be overloaded. I specifically called it out in this comment because he stated it at some point in the video, but I've heard almost the exact same thing said by Agile coaches in corporate training events. My company hired some consultants to help "implement Agile" and they all swore it was a way to make our work more productive while being less demanding. Yet in practice, the company's management just used it as an excuse to load on more and more requirements.

[@nkolchenko]

I've found this channel recently. And it is an awesome one.

[@ContinuousDelivery]

Welcome aboard!

[@adrianpad]

Can we take a moment to acknowledge this bloke's amazing collection of t-shirts?

[@reinerjung1613]

At university, we introduce students to Scrum and Kanban on a superficial level. Later in the second year they have to develop their first project as a team. For these teams we use Kanban for two reasons: Firstly, the project run time is too short (unfortunately, I would like them to work at least twice as long on a project to get more of the social aspects of team work) to apply Scrum in a useful way. Secondly, it is too much management. However, I totally get the point that you have to have some social events in between and some meta communication. That is what we do with our own projects and it helps greatly. In a research context Kanban has the additional benefit that you can handle fluctuations in worker availability better. BTW: This is a wonderful channel. I just recently found it and I find it insightful and learned a lot in different ways.

[@CTimmerman]

In the office you have lunch together and can hang out after work. At home you have (video)chat and can also suggest a movie or something after work.

[@vikramkrishnan6414]

The absence of "story points" and "estimates" alone makes Kanban preferable in my view. Not to mention, too often Scrum results in waterfall through the backdoor, only now you have some demos happening every week. Also Kanban fits a lot better with Continuous Delivery concepts, pick a feature, work on it, periodically merge to master and deploy. Scrum in my view discourages the kind of experimentation that will take longer than a sprint. It also strait jackets things into fixed units of time, so tasks are broken down in some very weird ways Another major plus for Kanban is there is no miscommunication and overpromising to management. You have a prioritized list of tasks and worker capacity. It forces the iron triangle (price, quality, speed - pick two) to the beginning of the process. You want things to move faster, we need more people or we need to rearrange priorities. It forces teams to think in Lean terms. Only the most important features get built. You can literally show your board to management and say, we are at full capacity, things will take time, instead of some imaginary "estimate" that in my experience is almost always off.

[@ContinuousDelivery]

Yes, I agree

[@Spetz83]

This is a good point. Every company I have worked for has turned "story points" into a meaningless exercise. "Story Points are not a measure of time, they are a measure of effort. But 8 story points means it'll take you a day to get this done, 3 story points is a half day, 13 is a week". OK, so Story points are a measure of time in your eyes then? "No, no, no... Story points aren't tied to time.. They are tied to effort/and complexity..."

[@hivee3044]

@@Spetz83 this is an old debate but, imho, lower point estimates can be broken down to a small time range estimates while the bigger the point estimation is the bigger the range becomes to the point it becomes impossible to translate. Saying a 3 pointer is about half day to a day feels alright to me, if it takes a week to get done, it wasn't easy to begin with. Effort point should also take into consideration the time range of completion else it's incorrectly designed. In agile you often hear 2 concepts about estimations effort and complexity which are 2 different things. Early on people spoke more about complexity points but recently effort points has become more prominent because complexity doesn't usually take into account the time of completion in its nature, whereas effort points does.

[@johnwellbelove148]

I've realised over the years that I'd been doing something like Kanban for years, long before I'd even heard of it. To me, Kanban feels like a more natural way of working and organising yourself. In the last two jobs I contracted in organisations that rigidly followed Scrum principles. I often found it very restrictive and the sprint lengths arbitrary and unhelpful. Some tasks were not easily or logically split into sprint sized units, but you couldn't help get the feeling that you were letting the team down by negatively affecting their velocity charts, by rolling the task over the the next sprint. Listening to the Scrum evangelists talk to each other often sounded like first year politics students excitedly discussing some newly discovered ideology.

[@johnwellbelove148]

@@Spetz83 I've felt that it's pretty much inevitable that story points become time based measures, as they are the basis of the 'burndown graph' in Scrum, which is a time based representation. The linearly descending graph of the 'target' line over the length of the sprint and its relationship to the actual story point count encourages you to see story points in terms of time.

[@otmanm4095]

That channel is pure gold. Thanks sharing!

[@gronccoravioli]

My team uses "ScrumBan": Everything is scrum, but without defining tasks at the beginning of each sprint & with a typical "To Do - In Progress - In Review - Done" Kanban board. We also have Backlog refinement meeting once a week where we clean the backlog & move ready tasks into the To Do column of our Kanban board.

[@Brunoenribeiro]

Without defining tasks at the start of a sprint, how do you guys define what needs to be deployable at the end of the sprint?

[@mattpotter8725]

@@Starkypooo From my experience of both Agile and Kanban, and when the team I was in moved to something like this there just aren't any epics, stories and tasks aren't seen like that, or if they are (which in the real world they still are, they just aren't grouped together to look like them) they are sized and there is still an estimated weekly/monthly velocity which is tracked so the product owner/business owner know when the feature is likely to go live. The Kanban team I was in released very efficiently I have to say, but the problem is that it lacked a certain direction and it often seemed like you were releasing just to get things released without actually getting much business benefit until all the stories related to that feature had gone live. If features were pulled in this case you ended up with half finished features on the live server with a lot of redundant code (sometimes a lot of code). This didn't happen very often though, but it is another problem not mentioned and where I think Kanban falls down. Sure you're pushing stuff out faster and doing more lighter releases means there's less chance of there being issues holding up the whole release when only a tiny part of it has an issue, but it's still a risk.

[@grenvthompson]

@@Brunoenribeiro You define that with Acceptance Criteria. As pointed out in this video, tasks are really only useful if the developer needs some way to keep track of the work... but a well written small story worked on by a good software engineer likely doesn't need tasks, and they should be discarded once the story is complete anyway. IMO the worst thing you can do in scrum is try to figure out all the tasks up front, estimate the hours and assign to engineers. Ugh. Not helpful.

[@orlovskyconsultinggbr2849]

ScrumBan is bad idea, actually its misconception of doing things right.

[@gronccoravioli]

@@Starkypooo 1. Unassigned 2. Yes, whenever we move a task/story into ToDo (not bugs tho). We don't use story points to estimate how much time should be spent on it. 3. We have an 1h-1.5h long "Backlog Refinement" meeting each week where we go through newly created tasks as well as some older ones. This is also where we decide whether a task is ready to be tackled within the next sprint or so & we assign a priority level 1-3. According to our Jira analytics, tasks spend less time in the backlog compared to before we used ScrumBan.

[@robwatson826]

Great video, I did wonder why these two ideas were "vs" as I like to think of my team as being Agile and we use a rough version of Kanban to manage work

[@iham1313]

+1 for the shirt

[@emonymph6911]

Great videos - I like that you focus on software design concepts and choices rather then the actual code. This is very rare in the industry. I agree with you and lean towards Kanban + Functional Programming over Agile + OOP methodology's which are common. You reflect on the purpose of each methodology before making a choice rather then jumping on the latest trend. It's refreshing to find someone with an actual brain who reflects on why they do something in a certain way.

[@ContinuousDelivery]

Thanks 😎

[@chrischeetham2659]

Great channel - As a scrum user for the last 15 years I've frequently seen the issues you describe with regards to rushing to hit sprint deadlines at the expense of quality features, somewhat alleviated by breaking specfic tasks down into quality levels - whitebox, alpha, beta, final etc but inevitably things still end up getting missed/left out and pushed back to be fixed at a later date. I've always felt it somewhat inflexible when, as you say, priorities change or support is required on other specific items/priorities mid sprint - this is certainly an interesting approach and one I'll be testing with the team! Will be picking your brains at WW! :)

[@mattpotter8725]

The curse of technical debt!!! I have worked in both Scrum and Kanban teams and whilst I have experienced what you say I think this generally only happens when teams overpromise on what they can deliver. In my experience it's better to underpromise and then pull in a small story or two at the end of a sprint. It may also be that having shorter sprints might work better as well. When I started at a company just transitioning to Agile they started with month long sprints, then went to fortnightly, and then every week. Of course this all depends on the ability to release, we had a release team that then got upgraded to dev ops so this was possible, but I understand that might not be possible everywhere for many different reasons. I do think estimation of the stories might be the problem though, which isn't always an easy thing and sometimes there is a rush at the end. It is a balance because you don't want to massively underestimate either though. I definitely preferred Agile to Kanban though. I felt in Agile the business has more involvement over what they were getting and even to have a look at how it was going on development (not to change anything, that's not possible), whereas I always felt Kanban was just a conveyor belt of being code released and onto the next story/task and then if there were any issues, say the feature wasn't what was expected a new story was added to fix it, which made it look like more was being released when it really wasn't!!!

[@thescourgeofathousan]

I’m finding your content so helpful Dave, wonderful! Cheers

[@ContinuousDelivery]

Great to hear!

[@ricardoguillen8098]

Thank you. Super useful and instructive!

[@sfij1]

Dave some addition. I think agile/lean are the mindsets. scrum/kanban are processes to coordiate the work. I found that scrum has kind of problem avoidance. If the team finds a complicated item/task just start to divide it to subtasks - and the backlog refinement is about that how to divide the heavy task(s). Unfortunately one can allways find and easy sub-task, so the illusion of progress happens. We end up with a lots of completed tasks, and a super heavy but shrinking core problem. Some sprint happens to realize that the heavy task came from a wrong assumption, but we have a bunch of completed subtasks having no meaning if the core is not present. Okay discard the whole - but management doesn't like to discard reported, logged and commited work. We end up a wrong and hackish solution of the heavy problem just to save the work already present. The result is 'release notes', restrictions on the original story - so at he end however reports and git shows something else, but the story is not completed. In kanban there is no planning, no educated guess on finish but at the end the story is delivered. My concern is on this whole kanban/scrum thingy that it is mainly good for maintenance - i mean fixing issues. Bad news for that this can be done AI used - no people needed. Things where ideas and talent is needed I think lean/kanban is better but doesn't add so much

[@yunusyurtturk]

(* I work in a company thats job is highly in embedded software, huge systems) When I started working at my company, we had no standart process. After a few years, some senior/management software friends declared we'll be agile and we start doing so by applying scrums&planning sprints For years, with the push of our seniors we tried to do scrum: daily meetings, plannings, retrospectives, measuring outputs of tasks... But I always felt there is something wrong, we are trying to be something that is not suitable for us. For example planning, I realized we do plannings and sprints because "it is required to be agile" and it is in scrum framework, but there are lots of unexpected tasks, problems that needed to be responded quickly that might take days or even weeks, friends going on vacations (I'm not against vacations) etc. in every sprint plan that made us not to reach our plan. There is also "measuring" issue. Since we get interrupted too much, most of outputs are incorrect, they just don't indicate anything meaningfull. For a long time, we feel courage of some people saying that if it is applied and accepted as good practice in industry, then we must do it. Also I need to mention unwillingness of colleaguges in scrums and planning meetings. Anyway, later I become lead of my team, with some trustworthy friends with me. For around 1 year, we go on like we did but one day I triggered and talk with my friend about these problems and revealed my intention to change our methodology to kanban-scrum mix. No sprints No plannings for time periods Yes almost daily meetings Yes retrospectives (whenever we want) Yes measuring outputs but just for insight or fun. etc... In my opinion, everything is going better, or at least same but this time with less headache.

[@BryonLape]

Scrum is not agile.

[@nickbarton3191]

I've often thought that now we are doing continuous delivery then why do we need sprints?. Actually all we need is user stories ie. can be implemented in 2-3 days.

[@psychurch]

Great info, I’m currently raising a small startup and we’ve been doing the treadmill thing for so long that it’s become painfully obvious of how burnt out the programmers are getting to be. Will add that setting a scope for the sprint and sticking with it is a must, otherwise you’re just extending the treadmill indefinitely 😅🙏

[@RU-qv3jl]

Kanban never forced you to choose between agile or waterfall, it works well with either. It helps you to move towards continuous delivery, continuous improvement and a leaner process. Agile is not a process. Often while referring to agile you seemed to mean scrum, which is just one agile framework that fits under the umbrella of agile as a whole. They’re different things and they combine very well. They work every better when you mean agile and not scrum. Incidentally there is nothing about Kanban that stops you applying as many or few of the principals of agile as you want and vice versa. That’s the beauty of it. It was never a one or the other choice except amongst people who are religiously fanatical about their way of working. I’ve also found Kanban to be one of, if not, the easiest way to help waterfall teams move towards a more lean and agile approach of working and also to help agile teams to improve still further.

[@mikeprice2038]

You nailed it. There is so much confusion about agile, mainly due to what Uncle Bob calls the "Agile Industrial Complex".

[@philm7078]

Great video, and great t-shirt (as always)

[@murrayr100]

You keep equating agile with scrum and sprints but agile doesn't require or imply sprints. when your talking about sprints you should refer to scrum not agile. scrum is only one of several ways of doing agile -XP, DevOps and Kanban are all compatible with Agile

[@Iskelderon]

Nicely summarizes why I prefer Kanban, it concentrates on delivering working modules, not on checking off list items within some artificial time limit.

[@aurelienrb]

10:06 "Kanban shines when there are problems" This is so true, and IMO related to the concept of "business value" that is much more centric in Agile that in Kanban. Focusing on added business value is important, but there's a dark side: when facing many maintainance / DevOps tasks / bugs to fix, it insidiously pushes some developers to compete for the most valuable tasks (for better recognition). While the ones that actually have the better team spirit spend most of their time on "zero business value" tasks, making them "the ones that add little value" to the project, including in the eyes of their colleagues who benefit a lot from not having any "toilet cleaning" chore😕 If the management is not aware of that aspect, this can become a serious issue. But not focusing on business value can also be desastrous. That's why I totally agree with you conclusion: success is in the balance between the 2 mindsets.👍

[@shugyosha7924]

When I worked in Scrum, the management used story points to gauge employees' performance, which made the tasks competitive. It disincentivised taking one for the team/doing things outside your expertise (because it's less efficient for meeting your point quota), and overly incentivised racking up points from small tasks. After I left that team I later saw there had been significant point inflation over time. To management it looked identical to the team accomplishing more.

[@vikramkrishnan6414]

Business value IMHO is much better represented in Kanban in terms of the task queue. The tasks by definition are classified based on business value

[@grenvthompson]

@@shugyosha7924 This is why agile teams are self managed... what you describe isn't agile.

[@shugyosha7924]

@@grenvthompson Yeah, it was a pretty lame setup. Management wanted the benefits of agile without letting go of waterfall thinking. It was basically 2-week waterfalls with a kanban board and retrospectives.

[@michaelnurse9089]

"developers to compete" Here is the problem. If you hire competitive types they will spent their efforts destroying their colleagues and then jump ship to your competitor for 10% pay increase. Rather hire people with a collaborative mindset. Aside: Read about the experiment when scientists wanted to breed the best chickens by selecting only the strongest most competitive chickens. End result was chickens who just killed other chickens on sight and battery productivity dropped to zero.

[@ChristopherCricketWallace]

excellent lecture

[@Emerald13]

Great discussion, i thought the supporting visuals and animations were great. Might be interesting to try to showcase or demonstrate your combined approach in a video with a real or fictitious project.

[@softwarearchitecturematter4482]

Agree , Iterative process is important. Small Iterative processes with feedback loop is the key to success of a software project.

[@alx-vla4986]

I totally agree... I found the "purity" of each gile flavour a limiting factor to the agility itself!

[@Nicholas-qy5bu]

Good video, Something is bothering me tho. How do you prioritize between feature / bug / technical debt ( if any ) ? I can easily prioritize between differents bugs but saying this feature is more important than this bug bother me a lot. What i like with scrum is that you can define a % for each of theses inside any iteration ( aka points ). How do you manage that in Kanban ? Do you assign time ? Or days to one of theses ? Do you have multiple board ? etc ?

[@robnichols9331]

I think mixing sprinting and Kanban can work well. Use sprints at the start of project. If all goes well the review process inherent in sprinting becomes less valuable as the process/team matures and you can get to the point where the sprint ceremonies become less useful, and at that point the team can switch to Kanban. The team can switch back to sprint as needed, and in my experience this often happens as the project reaches conclusion where the extra structure in sprinting can get the team over that final hurdle.

[@markhathaway9456]

Having never seen Kanban before this video, my impression is that it's a management tool rather than a team process for its own internal workings. Both tackle the issue of team-based work whereas small projects done by one person or perhaps two is more like writing a movie screenplay or fiction book or painting a complicated picture or writing a long-ish piece of music.

[@stanete]

Thanks for the video. I think the meaning of "team" has changed. And as such the conversation we're having about "how we deliver software that adds value as fast as possible with the lowest risk" should change as well. In a "team" now we have Product Designers, Product Managers among others. And we all work at different levels of involvement in the whole lifecycle of the product: business opportunity, success definition, customer research, ideation, planning, coding, delivery, measurement, assessment and back to the beginning. It seems that "Kanban" and "Scrum" only tell a small percentage of the story excluding half of the "team". Some people talk about Continuous Discovery and other people talk about Continuous Delivery but I don't see much people talking about a unified way of working as a "team". I'd love to hear your opinion on this.

[@ContinuousDelivery]

I think that is an important point, my take on "Continuous Delivery" does include this. I think it means the "Continuous Delivery of ideas into production" and the CD approach is optimising EVERYTHING to make that happen. If you take that view, it involves everyone, even peripherally, involved in the creation of software. We need a flow of ideas, we need stories that lead us easily to executable specifications and testable architectures and tests and pipelines and we need to manage configurations and test them and auomte deployment. We need to monitor things in production not just for technical feedback but also to evaluate the quality of our product ideas. That is what I mean by CD (and probably quite a lot of other things too). You are right, this involves lots of different roles and types of people.

[@shanedemorais7397]

I think a more positive term reflecting one's knowledge at the time is "missed opportunity" as opposed to "mistake". This is from the book "The art of making". The term "missed opportunity" fosters a different mindset when entering projects knowing that there will be opportunities missed that would have led to better outcomes, and once acknowledged, embraced rather than thinking I've done something wrong, a "mistake". Basically, this allows me to say "I did everything right under the conditions, and now, with hindsight, I can see where I missed opportunities to improve." Which is essentially the point of retro's. A lot of creative, introverted types suffer from the perfectionist mindset, and terms like mistake can cause unneeded anxiety over time.

[@ContinuousDelivery]

I don't mean to be insensitive, but I think that there are both "missed opportunities" and "mistakes". They aren't the really the same thing in a way that seems helpful. I damaged my car recently, revising it out of a garage. It was, I suppose a missed opportunity that I didn't miss the wall, but actually it was my mistake, and I should do better in future.

[@AdobadoFantastico]

At the end of the day, they're all just systems to facilitate communication and collaboration 😀 Good video, always appreciate your insights.

[@l0g1cb0mb]

That's my take, the Hybrid, and I like your version as apposed to the versions I've been exposed where the forecasting, planning and sprint elements were retained from SCRUM, and the swim lanes from KANBAN were integrated, with some organizations paying lip service to the lane limitations as "guidelines\\warnings" of pressure rather than flow controls. The value to the management team that SCRUM offers in the form of burndowns, confidence estimates forecast, etc. heck, even the stand ups that get usurped as status meetings instead of the collab briefs they're meant to be when managers are in on the meetings, kind of diminish SCRUMS value over KANBAN when it looks like both deliver working software, but SCRUM has that accountability element that serves no purpose in the flow directly, but can as an umm... "motivator" if you get my meaning. "Dude I got a PIP for that failed code released last sprint, it was ready, but behind another release, what could I do? Guess I'll be that squeaky wheel from now on to ensure my releases!" I think it has the potential to encourage bad behaviors and create unpleasant environments where one rather stay home than go in and have fun getting paid to play\\code! ^_^ But I ain't one to gossip... .

[@robertkelleher1850]

This channel has the best t-shirts.

[@errrzarrr]

Taking from the comments the most I notice is the same that happens in my team. They do stuff to be Agile certification compliant, instead of doing Agile stuff to improve their product and make things better for their clients and the team. On the contrary, the team has to delivery an excellent product WHILE at the same time perform Agile rituals

[@BryanFinster]

I approve this shirt Pragmatic delivery using the tools to solve delivery problems instead of blindly following a process. The Agile Industrial Complex will have kittens.

[@grrr_lef]

Having worked in both Kanban and Scrum setups, I'd pick Kanban any day.

[@bennewton]

Excellent

[@MoonWho78]

What about external blockers in Kanban, especially ones that take multiple days? Take another ticket or wait to be unblocked?

[@sitnarf7804]

Amazing!

[@arik_dev]

Hey Dave, this isn't strictly related to this video, but I'd really like to get your opinion on what prealpha, alpha and beta mean in the CICD + Agile philosophy. Maybe you could even do a video on it? To my understanding, with CICD you should be continuously producing production ready code. But it seems to me that for code to be production ready, it first needs to implement the features that meet the minimum requirements, AKA, a minimum viable product (MVP). What are some guiding principles that you can use to determine when an app is featured enough to be put in front of customers? And what are some differences (if any) to the Agile + CICD development process when developing brand new software, that has not yet reached customers? A little context, a year ago I quit school to work full time on building what turned out to be a fairly ambitious idea, which was made even more difficult being a junior. As I draw near to a version that seems releasable to me, I keep wondering if my perfectionist nature has kept me from releasing when I should already have. Or perhaps, that I've prioritized features incorrectly, and so taken more time than I should have to get my app in the hands of real people. Also, thanks for the videos Dave! I've been learning a great deal.

[@ContinuousDelivery]

I think that there is a distinction to be made here, "production ready" is not the same as "feature complete". Production ready in the context of CD means, production quality, ready for release into production with no further work. That doesn't mean that it does everything that users want, or need it to. So work so that at every step, each feature that you add is finished and ready for use, even if it will need more features before someone would want to use it. The next question is really "when do I have enough features to release". I think that you have misinterpreted "MVP" a bit. A MVP is the minimum that you can do to learn, it doesn't mean the minimum feature-set that your users need to do something useful. A MVP is an MVP if you have enough stuff to show to your friends or colleagues if you can learn from it. I would encourage you to work so that you can get good feedback as soon, and as often as you can - whatever that takes. You may already have "enough" stuff, and can release now, you may be doing something that people don't like, which would be good to find sooner rather than later. When we built our exchange, the whole company "played at trading" in test versions of it every Friday afternoon for six months before the first version was released to the public - that was our MVP, and we got loads of great feedback from people using it, even though it wasn't ready for paying customers. If your SW isn't ready for prod release yet, try and find a way of getting it in front of people (can be people that you know) and seeing what they make of it. Think of it as an experimental trial of your ideas! Good luck.

[@arik_dev]

@@ContinuousDelivery Thanks! The distinction between "production ready" and "feature complete" was a helpful correction. In CD, every new feature needs to be of quality before I move on to the next, which is not the same as having the full set of features needed to be useful. I also liked your example of "playing at trading", that seems to be an example of "eating your own dogfood", I will definitely start doing more of that. Also, I think I will get some friends to look at it today, even if it is unfinished, so that I can find out what my mistakes are. Cheers Dave!

[@e.h.5680]

Illuminating.

[@Andre_XX]

I agree with the "world's greatest idea" issue with Agile. I saw people spending half an iteration working on a delivery they knew was going to be discarded. I thought that was the very antithesis of the word "agile". I also think the approach needed to a system should be tailored to the type of system. Replacing an ancient legacy system whose rules etc are well-known with a modern platform requires a different approach to a new "greenfields" system that has no legacy to work from.

[@pm71241]

Also ... the "only one task at a time" for the most only makes sense in a certain kind of development. In many smaller companies you simply need to be able to schedule your time between 2-3 tasks to be able to progress on something if one of the tasks suddenly gets blocked by waiting for external feedback or similar. I would make no sense to put such a task back on the backlog, since you're most likely the only one for which it makes sense to take it up again once it's ready to progress. It works kinda like a CPU scheduler.... and a CPU wouldn't get much done if it only could run one program to end even if it had to sit waiting for I/O.

[@ContinuousDelivery]

Part of the approach in kanban is to do work that is ready to do, and avoid blockages that way. Often kanban teams will adopt a "parking space" for truly blocked work that happens sometimes, but it is an exception and not really ideal.

[@pm71241]

@@ContinuousDelivery Depending on what you work on a single task might get blocked several times underway by, say, such simple things, as you discover a firewall rule is missing somewhere which you can't add yourself. You need something to switch over to for the day or two you wait on that to resolve.

[@anticipayo]

Baseed on having lots of experience with agile and some experience with kanban, I prefer agile, mainly because the sprint cycles allows for a small pause of reflection on the overall progress between sprints. That period is called spring planning. I am not sure if kanban has an equivalent feature.

[@rhys9336]

The problem with sprints is that they set an artificial finish line. Most devs are in a rush to finish their sprint commitment and then move into the next sprint and do it all again, when the actual outcome you’re looking for is the ticket in production with a happy customer and some feedback. When people are focused on sprints it leads to an outputs over outcomes culture, instead of focusing on what happens in production.

[@hivee3044]

Aren't you confusing agile with scrum?

[@kennethgee2004]

as at time index 7:27 is the whole point: iteration that leads to deployable or at least releasable code. To many places have no real version control and ways of handling project management despite the number of books and software packages out there. Other become to dogmatic in one style to allow for changes in their process. Adoption of any style that the team can implement that moves towards a deliverable product is better than any rigid framework. Having anything is better than nothing.

[@mykolaontech2142]

Scrum doesn’t necessarily prescribe aligning the release cycle with the sprints, IMO. There’s nothing more “deliverable” to production than already progressively delivered value increments during a sprint.

[@ssssssstssssssss]

What do you suggest to get developers to consider the big picture and not focus just on the feature in front of them? It's a huge cost if they do not consider other features that are specified. I have them schedule software design tasks, but there seems to be a lot of resistance to that.

[@emonymph6911]

If you have a large team make 1 guy the 'feature architect' who considers the flow of all features and UX. They consider the 'big picture' and order the dumb devs to make features they require which can be combined to make a service offering.

[@ContinuousDelivery]

Train them to think that way!

[@Immudzen]

Overall I like the KANBAN approach and that is what my teams normally use. However, we have something closer to multiple queues. I work with a lot of research based code so a great number of the features are only implementable by a subset of the developers. If you need to improve the mathematical stability of a complex algorithm only people with the kinds of skills needed for that problem can work on it. So when people take tasks they take the next highest priority task that they are capable of doing. I have to admit I don't hold completely to that rule though. If I have a day with a bunch of meetings where I don't have time to really get into a hard task but I see a bunch of trivial tasks that I can just get through I will grab a bunch of those. I know it violates the idea of taking the next highest priority task but at least this way tasks get done. If I only have one hour between meetings I just can't deal with mathematical stability, designing a neural network, debugging something complicated, etc.

[@LucTaylor]

Your experience is almost identical to mine Kanban is better is virtually every way (to SCRUM) save one... there's something physiologically beneficial about a schedule and reset

[@justusschwabedal5924]

Fixed time-frames in agile resemble a step size in a search process for me. In development "problems", where one needs to gather data to decide whether to continue a particular pursue, a fixed frame alleviates one from the need to discuss how much data needs to be discovered before pivoting. It's, thus, not Up to the nerves of the manager how much time to sink in a tangent, but an objective assessment of the situation trading off certainty and time constraints. Kanban cannot give you that. The second aspect of a fixed time frame is to foster dedication through planability: the engineer can dedicate a Monday to a hard problem which might not be solvable knowing that he has til Friday to proof its worth. His manager won't scrap his work Thursday morning because it doesn't look hopeful yet.

[@Bobesboy5724]

Please, correct me if I am wrong, but for me, Agile is a set of practices intended to instill a set of values in teams and organizations for the continuous improvement of the delivery of value. I don't think the definition given here fully embodies what Agile is.

[@ContinuousDelivery]

Sorry but you are wrong. Agile says nothing about practices, some approaches to agile do, but agile itself in the context of SW dev is defined by the agile manifesto, which is 4 values and 12 principles - 0 practices. agilemanifesto.org

[@harrievanderlubbe2856]

Toyota for the win... but... I would think that for the person/team that works on a feature, it would be practical for that person/team do a next feature within the same knowledge domain. Is that practical, or is there another/better approach?

[@brigandboy1425]

Thumbs up for the shirt.

[@SaudBako]

9:20 "completely changing direction mid-iteration ... usually frowned upon in the agile circle": Maybe, but agile says nothing about iterations. Principle 2 behind the agile manifesto states "Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage."

[@mikeprice2038]

Does he mean to compare scrum and kanban? Agile is not something a team does, it's something a team becomes by working in a way consistent with the values and principles of agile.

[@martinjungmair705]

When I hear Kanban, I see Agile. There is no Kanban without Agile, but there is Agile without Kanban.

[@yunusyurtturk]

When an agile(sprinting/planning) team realize their plan is wrong, some developers start defending they should continue the plan until next sprint, then they say "this is what planning/sprint means"

[@Plueschtroll]

tl;dr: if your tasks are controlled by outsiders, use Kanban. Great to see that I am not the only one preferring Kanban over Scrum. I work with a machine manufacturer as an engineer (for Industry 4.0 stuff, so still software), and the software team tries to use Scrum. What happens is that in each and every sprint, some product manager or project manager - machine development manager, not software products - jumps in with a big and urgent problem that the team has to pick up. Hence, the planning is absolutely destroyed, and that every time. Scrum really just works if every party plays by its rules, while Kanban can be more flexible for those panic attacks. The other problem is that those managers don't come to the sprint reviews. The team can complain about the situation, but it has no effect, because they of course cannot enforce that the whole company plays by their rules.

[@berkes]

Your example resonates. But my conclusion is the exact opposite. I too had managers who would be on constant panic mode. This new task so URGENT that it immediately needs to replace all current work on the previous HIGH URGENT issue. That is a guarantee for zero efficiency. Zero velocity. Scrum, at least offers the contract that all this urgent work has to wait. Applies that contract to everyone: boss, investor, sales rep or engineer: you wait. Kanban offers no such contract. I do realize, that it matters if in practice, people live by the contract. If they don't, obviously it's not going to help. But with kanban you don't even have the option for that contract.

[@Plueschtroll]

​@@berkes You imply that the team can manage to stop annoying managers. In machine manufacturers, at least those I was working with, the software has the least amount of impact. Of course, if you can enforce Scrum, it can cool down some stakeholders, too. But if you can't, Kanban is still a way to organize this chaos; try and use Scrum will increase it (in that particular unfortunately not too uncommon situation).

[@vitorhq1]

@@berkes it seems that you don't know that one of the Kanban practices is to make policies explicit. You can, and should define contracts for your Kanban System and make them explicit.

[@vitorhq1]

The biggest difference in this matter is that Kanban allows you to review the contracts as your work system evolves while Scrum forces you to keep a set of contracts in place otherwise you will stop using Scrum

[@tongobong1]

You should use agile Kanban.

[@ulissescruz5540]

Since, kamban does not support the notion of a deadline, how would you talk to the custumer when using a Kamban aproach? By the way I liked the video.

[@ContinuousDelivery]

Thanks. Its too contextual to answer really, but the most successful company in the world (Apple) don’t pre-announce. You can make some predictions based on the rate at which you, on average, produce new features, but my view is that predictability is largely an illusion anyway, the only real way to be predictable is to be conservative in your predictions, so as a business, is it better to creat great features sooner, or to predict when, but deliver them more slowly? I think the answer to that may depend on the biz, but mostly sooner is more important than predictably.

[@ThePC007]

Deadlines are a difficult topic. You cannot really predict how long the development of a feature will take, since god knows what problems you may run into while developing it. Falling behind schedule also creates stress and typically produces less-than-ideal software solutions (they may be either unreliable, poorly optimized/scalable, or difficult to maintain), which may hurt you later. Another issue is that deadlines prioritize the development of new features over code refactoring, which is again, not beneficial to the project in the long run. At the same time, I can understand that customers want to have some data that they can use for planning purposes and that sometimes deadlines are a great tool to move development forward and prevent feature creep. Maybe instead of utilizing deadlines it might be beneficial to instead provide certain baselines at which you expect a feature to be completed, but make sure it's not set in stone and can be moved backwards if need be. It's difficult to say, really. There are successful companies that do utilize deadlines in everything they do, and there are also those for which the end quality of the product is more important than short-term development speed.

[@TimSchraepen]

Take a look into upstream kanban using tokens. A customer would rather have better predictability (and later delivery) over deadlines (with unpredictable delivery). And Use scope reduction and not quality reduction to try to reduce lead time in the short term.

[@rogermouton2273]

You have to have some idea of when things will be delivered. What you should do is always be clear to everyone that you don't have 'deadlines' you have 'objectives' - the difference being that the former are dates set that we don't want to move, and the latter are what we're aiming at, but always with the accepted understanding that dates can move because software development is by nature unpredictable. If people want certainty in software development, they need to grow up. There's a couple of other factors: you can keep your feature descriptions high level, so that you're not defining with great precision what will be delivered, but rather the basic idea (that allows some room to move on scope). And you should generally be pessimistic in your estimation - because, most of the time, you're not going to be able to see the complexities of what you're going to implement upfront. Of course, if you finish earlier than estimated, that's a win.

[@errrzarrr]

Ulisses, a fun fact: the most successful products we consume today do not preannounce or have deadlines. They deliver when is good and done and have an event for that. On the other hand, none of them don't do or _are_ Scrum either.

[@rajadas6432]

For the first time, I'll completely disagree to your view. In context of software development, Agile is nothing but set of 4 values + 12 principles intended to deliver value to customer in sustainable way. Agile didn't prescribe any framework, process, procedure or tool. It was codified by 17 software veterans in the year 2001. Kanban, Scrum, SAFe, LeSS, etc etc are many ways to attain agility. Agile is philosophy of better software development & delivering customer value and all these frameworks are ways to walk in that path. Kanban is 70 years old practice rooted in TPS. It was formalized in Software development context by the year 2005.

[@ContinuousDelivery]

No, I didn't say that it did, but it was influenced by by three popular approaches at the time, and was meant to be a synthesis of them all. They were Crystal (iteration based), Extreme Programming (iteration based) and Scrum (sprint based). The 3rd manifesto principle says: "Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale." I say in this video that good agile is a lean approach and kanban is an agile approach.

[@hivee3044]

@@ContinuousDelivery your title and this comment does not make sense to begin with... You can't oppose agile to kanban. One is a philosophy the other is a methodology and like you said, it's an agile methodology. It's like sayings "let's compare sports car (the category) to mclaren mp4".

[@chat-1978]

I agree on this. It's the same problem and confusion with DevOps and automation etc. Culture is not the same as methodology and not the same as skill. I just thought of agile developer titles :)

[@BryonLape]

Neither Scrum nor SAFe are agile.

[@TomDoesTech]

Start with something, figure out what works and what doesn't modify and repeat.

[@mattpotter8725]

Having worked in both Agile and Kanban teams I agree with you that there are similarities and I do have to say after a while working on the team doing Kanban we too reintroduced some Scrum methodology as like you said it was becoming too much like a treadmill. Where I disagree with you though is your comment on backlog grooming. It shouldn't be done too much, but I think it is good for the team to sit down and discuss what is coming up soon. Often in these sessions someone will bring something up that improves what was previously just a discussion between the business owner and product owner at some higher level. If this isn't done this might get picked up by those who pick up the item, but often it isn't. It might get picked up at a planning session, but by then, especially if it's a complex piece of work that is the highest priority feature that needs to be released it puts stress on those who pick it up, which will be almost straight after they've finished their current item, maybe right after the meeting. I also don't recognise your task allocation (apart from where there is a multi skilled team that can't do a bit of everything). I've never worked on an Agile or Kanban team where certain people were assigned certain items to do. If that's happening there is something wrong with the team. You might have more senior Devs who it might be better picking up certain items/tasks, but this isn't done in a meeting, it's done more organically within the team. One last thing, two actually come to think of it - firstly you didn't mention the ability to involve the business (or client) in song the incremental progress being made, I think this is where Agile and Kanban work so well, the transparency and ability to assess progress and change direction of something new, more important comes up. Secondly, having sprints allows different pairs within the team to work on a new task (unless you're very lucky and two pairs finish their tasks at exactly the same time, which in my experience never happens). So you are stuck with the same people working together. This might not be a bad thing, but it's probably better for younger, less experienced members of the team to pair with different people to pick up new skills, in fact this works for the more experienced members as well, everyone has their own set of skills, some things they're good at, other things not so much. I've also never been on a team where someone has come up with the world's greatest idea. Occasionally though the business has had something urgent that comes in and then it has to be sized and listen it is inserted into the sprint, taking out a similar sized story/task. As long as sprints are short, in my Agile team I worked on we released every week, this works. If you have sprints last 2 weeks or longer this might cause problems. In the Kanban team I was on items for released every few days, someone multiple times a day, but this kind of fast release did have other overheads that I'm surprised you didn't mention, namely that on release everyone's individual branch in the team had to merge the release in with the release branch so the more often you release the more time you end up doing this. Usually this caused no problems as team members talked to each other so they knew whether there were likely to touch the same part of the codebase and potentially break each others new code. I'm also surprised that you didn't mention daily standups, either at the board or virtually (for teams distributed around the world or where working from home was a thing). This happened on both Agile and Kanban teams I worked on.

[@snarkyswede526]

With regards to the release merge, the reason he doesn't mention it is because his team, AFAIK, works in the main branch and doesn't really have feature branches, and thus merges all the time

[@mattpotter8725]

@@snarkyswede526 Ok, I get what you are saying but if everyone is working on the main branch and checking in daily you can't release until everything is finished. In Kanban surely every team picking up a story/task has to take a "feature" branch as you call it off you can't release after every individual item is finished. If you are grouping up items to release together in not sure this is true Kanban, but I could be wrong. In Agile/Scrum you can do this as everything is released at the end of the Sprint, but this isn't the case in Kanban where you want to release as soon as every item is finished ideally. You might group a couple of things together if they happen to finish on the same day, but that isn't planned for ahead of time.

[@hivee3044]

@@snarkyswede526 even in scrum, no one should be working on the same branch... Best practice, whatever your methodology is, is to use features branch...

[@cherubin7th]

I use kanban for myself.

[@adicide9070]

uhm is that THE serenity?

[@Marque734]

Comparing Blackcurrant with Berries, aren't we?

[@marcbotnope1728]

100% web software perspective again.

[@ContinuousDelivery]

Nope, my team built one of the world's highest performance financial exchanges this way - all of it, the entire "enterprise system".

[@mykolaontech2142]

I guess, by “web software” they mean non-versioned delivery, as in out-of-the-box software…

[@SalihGoncu]

Well, what about if the programmers already have experience in the problem domain? If they do not need to learn from scratch? This, with a team with domain experience, wouldn't it be better to integrate that experience first and foremost? So, Agile works well with "generic" programmers who are not an expert on the domain but expert in programming. Kanban is better fit for the programmers who know the domain well but may not be that good at programming.

[@Rockem1234]

You still have to "groom" the back log with Kanban, which is most of the work in Agile cycle as well. So, apart from planning and measuring velocity, it's pretty much the same

[@ContinuousDelivery]

It tends to feel lighter-weight in my experience, because you do it on demand. Think of a New feature, add it to the board and prioritise it. Maybe reviewing other priorities as you do. Usually takes minutes.

[@vikramkrishnan6414]

In Kanban you groom the backlog when new tasks and priorities arrive and the grooming is pretty simple, you just move tasks up the queue. There is no story points or 3 hour long sprint planning meetings

[@rogermouton2273]

I don't see how 'grooming' (a term a dislike a lot, actually - because it's a fancy term for refining requirements, which is just something that is a necessity) is 'most of the work' in software development. It depends on the nature of what you're doing. Some development will require a huge amount of work on specs, some might require not much development, but a huge amount of testing. And sometimes you may say that the specs should be very lightweight, and it's best to refine as we develop and test. The problem happens when people try to apply generic methodologies without considering what is practical in their specific context - this is a huge source of wasted time, frustration and even resignations. Also, Kanban should be Agile - if Agile has its proper meaning of being flexible and able to respond quickly to changes. Kanban and scrum are different - the former being a useful way of organising work, and the latter being mostly bullshit.

[@Rockem1234]

@@rogermouton2273 I was going for most of the work of planning, not in the entire development. Defining what should be done, wether it's full fledge definition or a lite one is still hard and will take the most time out of the PLANNING cycle. Once this is done the actual sprint planning takes about half an hour for the entire team. I prefer to have sprint as it gives me a framework of feedback. I see it the other way around as Kanban is just a list of what needs o be done, nothing more.

[@rogermouton2273]

@@Rockem1234 I don't see how having sprints gives you a better idea of how much work is being done. Why would you need sprints to measure velocity?

[@girlsinacoma]

i just watch the videos to see what shirt he wears next

[@researchandbuild1751]

Ive never understood why people had to invent agile. It seems like common sense. I mean if you make a software program for yourself dont you usually make it piece by piece incrementally? Where the hell did "waterfall" even come from? Mist have been some manager thing? I mean agile is just freaking common sense i dont know why we had to champion for it

[@ChaosturnMusic]

I always understood it like, When you used to release software back in the day, you had better get it right the first time. You don't get to release a downloadable patch for a released game cartridge. Nowadays we can update software every day of we'd like, hence the transition from waterfall to agile

[@HoD999x]

what always confused be about agile/scrum: let's say we have more than one person in a team. what do we do if they don't finish at the same time? do some just sit around and do nothing? in my particular case, we had code > deploy > test > acceptance the tester wasn't the developer, so if the developer was done wednesday, he would have nothing to do while the tester tested his changes - OR (this happened in practice) every sprint had an incomplete task that was finished in the next sprint.

[@TimSchraepen]

This is queuing theory at work and only gets stronger (and annoying) with more specialization roles. If your team values flow over resource efficiency, then people “done” with their end ideally put time into learning other skills in order to help out the other tasks.

[@mykolaontech2142]

Ideally, your developers join the tester and help testing by both learning their trade and providing the testing hooks from the code side. Suboptimal - devs take next task while testing in progress. This loses focus, puts lots of unhealthy stress onto testers and creates knowledge silo’s. Not recommend.

[@rogermouton2273]

This is a reason why sprints are a stupid idea. If all the work at the start of a sprint is new, what do your testers do for the first few days (or however long it takes to finish coding a feature)? So, if you have features that finished coding in the previous sprint, but didn't finish testing, then you could give them that work to do. But this means that effectively, there's no time boxed sprints, and you're just continuing to work on stuff regardless of when sprints start/end. So why are you bothering with all the effort of trying to organise work into some arbitrary two week period at all?

[@errrzarrr]

​​@@rogermouton2273 it's micromanaging. You might have feel like disempowered and micromanaged and that's because that's what it is, a micromanaging framework that disempowers developers. On the other hand, the 2-week sprint dogma is the most rigid dogmatic thing I have ever seen. Like all proyects are of the same nature and at the same stage with same resources. No, they are not.

[@rogermouton2273]

Sprints in general are bullshit. You diivide your work up into bits that make logical sense. A logical piece of work may take a week or a month, and generally it isn't humanly possible to say exactly what you can do in two weeks - which is what sprints force you to do. The also force you to break work up into pieces based on what fits into a sprint, rather than what's logical. And, what if you finish your work early? Scrum says, for some unfathomable reason, that you're not supposed to add new work to the sprint after it's started - how is applying stupid rules like this making you 'agile'? Then there's the bullshit of 'ceremonies' such as 'retrospectives' - which assume that after every two weeks, there will be things you did wrong which you could improve. Why would you assume that you keep doing things wrong every sprint, that you can fix with a meeting every two weeks? If you're regularly doing things wrong, why is that happening? It means there's something wrong with your general process. If there's something wrong with your general process, you don't need to talk about it every two weeks, and repeatedly raise the same issues. What you find is that 'retrospectives' are a waste of time and no one has anything of signficance to say.

[@researchandbuild1751]

There is nothing wrong with pulling additional stories into an ongoing sprint

[@rogermouton2273]

@@researchandbuild1751 yes, so why does scrum say that you shouldn't add items to a sprint after it's started?

[@bc4198]

Which term has more cult-like followers? I find kanban to be pretty intuitive and Lean concepts intriguing, but their devotees and their slavish devotion to jargon drive me bonkers.

[@ContinuousDelivery]

I think both camps have their religious zealots and jargon 😏

[@errrzarrr]

Both are very dogmatic and orthodox, that's for sure.

[@brandonpearman9218]

The question is wrong. Kanban is agile.

[@revietech5052]

I never really liked working with cards on a Kanban board. They're typically written ad-hoc with random levels of abstraction. e.g. There will be a card for a square peg but the card for the square hole will not exist or will simply be consumed by another card typically written at a higher level of abstraction. Personally I'd rather ditch the cards and create evolving architectural and design diagrams.

[@jeremyjones4019]

This video is a little misleading Dave. Both scrum and kanban are possible agile implementations, but here you are referring to Agile as if it was scrum, which is incorrect. I personally find it a little sad that agile and scrum get equated, because scrum is generally one of the worst ways of implementing agile, I find kanban and XP to be far superior.

[@ContinuousDelivery]

XP is described as an iterative process. Chapter 7 of "Extreme Programming Explained" - "Essential Practices" has a heading "Weekly Cycle" called an "Iteration". The follow-up book, by Kent Beck and Martin Fowler "Plannined Extreme Programming" has a chapter called "Iteration". So this is not specific to Scrum, it is a shared concept between them.

[@julialittlebee]

Agile is not Scrum. Scrum is Agile, but Agile is not Scrum.

[@Rebecca236]

Agile is a set of guiding principles, not a framework.

[@follow-saichino]

If you want to have something like regular Retrospecitves, Refinements and even Dailies then Kanban gives you no idea on how and when this could happen. Scrum gives you more ideas on that - as it is a framework. So, if your horizont is more wide then just daily developer work, then Kanban leaves you with some questions that Scrum might give an answer. And regarding the argument about "fast deliver the the world greatest idea": A Scrum Sprint is just a timebox, not a release package. In much cases teams decide to bind their release plan to the Sprints, but that is not a rule. It might make sence to delivery continuously during a Sprint and concider the Sprint "just" as a container for planning, visualisation and celebration of success.

[@errrzarrr]

All I have to say is Software Engineering have existed way before Scrum/Agile/Kanban and will exist way after those trends. Keep arguing boys

[@bradappleton9656]

Wow! So much misleading (mis)information here ... hard to know where to start: - Title & theme (incorrectly) suggests Kanban is not Agile (and also seems to equate Agile exclusively with Scrum/XP) - Kanban & Scrum are *both* Agile (and both have strong roots in "Lean", among other things) - The "Kanban Method" was (also) created (initially) for Software Development (by David J. Andersen), and is more than just the "kanban" term from Lean - Kanban is *also* iterative + incremental, but it *decouples* development cadence and release cadence (and doesnt iterations to be fixed-length + timeboxed)

[@andrealaforgia]

No, Kanban, strictly speaking, is not Agile. As Ron Jeffries, one of the signatories of the Manifesto, wrote: "Is Kanban “Agile”? In a word, no. In a few more words, while Kanban can be used in an Agile fashion, its principles are not those of the Agile Manifesto, and it can be used quite effectively in a situation where the Agile values are not in place. It’s a really good set of ideas, very compatible with Agile projects, very likely to help you improve. But it’s not “Agile”: it’s an independent set of ideas. Great ideas." Consider that founding principles of Kanban originated in the 1940s, when Agile was not even remotely conceivable. Kanban is orthogonal to Agile and can be used with Agile, but it's not Agile.

[@bradappleton9656]

well - strictly speaking, Scrum's principles are not those of the manifesto either (it has its own set) - yet they are still compatible/compliant with the agile values+principles. Scrum can also be made to work where the "values are not [yet] in place - as long as you can "inspect & adapt" in the right ways/direction. Kanban is less prescriptiuive (requires fewer "ceremonies/practices" and hard constraints (e.g., fixed-length sprints), and even affords decoupling development cadence & release cadence (which BTW better enables CD). Kanban has a heavier "Lean" background than Scrum (which still has plenty), AND its principles are still manifesto compatible. It does still fall under the overall Agile umbrella (especially the very first one). But most importantly, Kanban was never an "either/or" with Scrum - its more of an "and/also" (and I dont necessarily mean "ScrumBan") and can work together with at the same time. Lastly, RonJ doesnt speak for all of us who participated in [co]creating Agile (not just the manifesto values, but also the principles, and the name, and several of the methods), and has even admitted to being 'wrong' and/or 'extremist' in his views on occasion ;-)

[@errrzarrr]

​@@andrealaforgia who knows nowadays not even Agile is Agile. Mind you.

[@drhilarius]

"Which is the best way of software development?": Far too abstract question, but very good presentation (as always), which puts the necessary context into the right focus later on. What I am missing in those considerations (here and scattered over the WWW) is to pay crucial attention to the maturity of the team. The more mature a team is with agile or lean principles, the more self-managed it can work. Guidance through the various Scrum meetings is more necessary if a team is inexperienced, and visualization of work and continuous learning (which Kanban puts upfront) is only effective if a team is able to work in a proactive way. So "which is the best way of software development?": ymmv

[@Cerebradoa]

1) you mean "Scrum" instead of "agile" 2) you are doing "Scrumban"

[@ContinuousDelivery]

1) No I don't, 2) No I am not 😁

[@fabriziomeschini4337]

Lmao are you ripping Captain Disillusion's logo off?

[@ContinuousDelivery]

You mean that we both use the letters “C” and “D” 🤣

[@paulo2357]

Agile is not Scrum

[@MrEnsiferum77]

Agile is dead. And is been for years. Developers are using waterfall wrapped in fake agile crap.

[@hivee3044]

As a scrum master / agile coach... I start to feel that way for quite a while. Which is also why I love kanban. Kanban in IT, is not about lean, agile etc... It's about process. You start from the actual process in place (most likely a faulty one) and it help you identify what is wrong within the organisation or the subset where kanban is applied and from there, you improve the process until it becomes successful and painless. And that is the main goal of agile. Scrum on the other hand is more of a kanban on training wheels but scrum does not even focus on the team / organisation process.

[@CasperBang]

Sorry but I think this is unnecessary clickbait that do your brand injustice. Agile has few principles, but it's primarily described as the opposite as phased waterfall. By deduction under those rules; if Kanban is not agile, then it must be waterfall - and Kanban is certainly no such thing! I'm going to assume you have seen Veritasium lately (kzbin.info/www/bejne/iWPbeY2GfZqGpMk) and are experimenting on your own?!

[@ContinuousDelivery]

I guess you may not have made it to the end of my video, because I reach the same conclusion as you, kanban is agile, agile (when done well) is lean. Yes I am a fan of Veritasium and watched that episode. Inevitably part of the game of KZbin is to try and attract views. A significant part of that is to play the thumbnail game a bit. I like to think that I share veritasium's philosophy of trying to use the tools of KZbin to our advantage, without compromising the integrity of the channel or misleading people. So I do use "clickbait-y" titles sometimes, but I hope never clickbait-y content. I don't think the title for this one is misleading, maybe we should have added a question mark? This is a topic that I have been asked, often, which is what prompted me to do this episode and while I see no tension between the two, and say that in this video, I am trying to represent the view that they are different things and the explain why they are not. Sorry you didn't like it.

[@andrealaforgia]

>if Kanban is not agile, then it must be waterfall That's a huge logical fallacy. An apple is not Agile. A foot is not Agile. It does not mean that they are Waterfall. As Ron Jeffries wrote: "is Kanban “Agile”? In a word, no. In a few more words, while Kanban can be used in an Agile fashion, its principles are not those of the Agile Manifesto, and it can be used quite effectively in a situation where the Agile values are not in place. It’s a really good set of ideas, very compatible with Agile projects, very likely to help you improve. But it’s not “Agile”: it’s an independent set of ideas. Great ideas." Something can be orthogonal to Agile - without necessarily be classifiable as waterfall - and be used effectively *with* Agile.

[@errrzarrr]

> _If it is not Agile then it is waterfall_ Here we have a priest of the orthodoxy and dogma

[@HarpreetExplores]

Both don’t work!