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

[Music] which is the best way to organize your software development agile or kanban and what do those things really mean anyway in this episode i want to explore the differences describe the pluses and minuses and tell you my preferred approach so which should you pick agile kanban or maybe both [Music] hi i'm dave farley of continuous delivery welcome to my channel if you haven't already please do hit subscribe and if you enjoy the video today please hit like as well if you'd like to learn more about the approach to development that i generally recommend check out some of my training courses on my training course site lots of good content there and some of it's free agile and kanban are both effective approaches to organizing our work they both work significantly better than the alternatives one important reason for that is that they allow us room to make progress incrementally and so leave us room to make mistakes and recover from them without too much pain agile and kanban both offer techniques to organize and structure our work wikipedia defines agile software development like this agile is a set of practices intended to improve the effectiveness of software development professionals teams and organizations it defines kanban like this kanban is a lean method to manage and improve work across human systems so both are really trying to optimize our work agile is in our context came out of software development it was described by a bunch of software developers who wanted to promote a better way to approach development they established the principles at the start of the century in the agile manifesto kanban came from lean manufacturing specifically toyota it was invented to try and visualize work another part of the definition of kanban says this work items are visualized to give participants a view of progress and process from start to finish in japanese the word kanban means signboard or billboard so it's a lot about visualizing what's going on people often see these two schools of thought as very distinct and despite playing that game a little with the title of this video i don't both of these approaches share many common attributes and values both are squarely aimed at making incremental progress and i think that's important so working in many small steps rather than fewer big ones this is vitally important because unlike software development approaches that preceded them this means that we can make progress with greater confidence even when we don't yet fully understand the problem and we can track that progress direct it incrementally and clearly see where we are so i see the difference between lean kanban approaches to software development and agile as more about nuance and maybe some of the rituals rather than about the fundamentals to put this another way i see kanban as an agile approach and i see good agile as a lean approach each school of thought reinforces rather than challenges the other let's explore those commonalities in a bit more detail in the bad old days we used to think about managing change like this it's going to cost us lots more to make changes late in the development process so let's optimize to make all of the key decisions at the start the problem with this is that this is a horrible world to live in it means that we have to have perfect foresight and to be able to predict all of the things that we don't yet know that may trip us up this means that we need to make all of the most important decisions at the point that we know the least that we're ever going to know about our task traditional software dev was kind of built on the assumption that this was some kind of truth of the universe that we couldn't change but it isn't this isn't how things in real life work in real life we try stuff see what works stop doing the things that don't work and do more of the things that do in the real world we call this learning agile and kanban turn this assumption that we aren't allowed to learn other than at the start of a project on its head let's imagine what a nicer world would look like for a moment if we could start work quickly and then proceed in a way that assumes that we're going to make mistakes then we could correct our mistakes as we go for that to work it would be great if when we find a mistake we could correct it at about the same cost whatever point in time we find the problem that means that this ideal world would have a flat cost of change curve whenever we find a problem it's going to be equally cheap or expensive to fix it to do that we can't afford to spend too much time in detailed analysis at the start we need to do some but we don't need to know all of the answers before we begin work we'll need a good story on testing dependency management version control and software architecture to allow us to make changes at any time without breaking anything fundamentally what this is all about is a few really quite basic ideas we'll need to optimize to be good at learning getting great feedback and clear insight into our work we'll need to proceed in small steps incrementally so that we can check frequently whether or not our ideas are good ones and we'll need to work in ways that are transparent so that we can see very clearly when we begin to make a mistake fundamentally agile and kanban are both built on the assumption that our guesses are probably wrong so we should check them as we go and we should limit the scope of our guesses so that when we check them we can understand the results and if they are wrong we won't have wasted too much effort or time on them this is how science and engineering work so that's actually a pretty good starting point the biggest difference between agile and kanban is in the detail not the basic principles and the principles are what matter more in terms of planning most agile approaches divide work up into iterations scrum calls them sprints each iteration is essentially a unit of delivery for our software if your code isn't releasable at the end of an iteration whatever it is that you're doing isn't really agile from a process perspective what this is doing is setting the batch size for software delivery to an iteration usually a period of one or two weeks worth of work agile teams track the rate of progress by counting iterations how much work do we usually do in a single iteration and using that to guide their planning at the start of each iteration they agree on the priorities agree the capacity to do work based on how much work they've been able to do recently and anything else that may affect their plan and then they begin kanban works a little differently kanban from a process perspective reduces the batch size of work even further the only interesting unit of work in kanban is a single feature planning in kanban is really pretty simple you divide the work up into small features you prioritize the list of features with a simple kind of bubble sort process is this feature more important than that one and you maintain that prioritized list of work when people on the development team become free they pick the next most important feature and start work on it and they work on that feature and ideally only on that feature until it's finished agile teams track progress at least in terms of planning at the level of iterations they track how much work they achieve in each iteration iterations scope their releases they use measures like velocity to determine the rate of production within an iteration and so on the downside of this is that they are constrained to iteration-sized chunks of work if halfway through an iteration an agile team thinks of the world's greatest idea the fastest that they can begin work on that world's greatest idea is the following iteration unless they discard their current plan and completely change the direction mid-iteration which is something that's usually frowned upon in agile circles so if you're working in two-week iterations and get the great idea after a week it's nearly three weeks before you can release the world's greatest idea kanban is more flexible because the batch size of work tracked and planned is a single feature if a kanban team is fully occupied and they think of the world's greatest idea they can put that idea at the top of their priority list immediately and the next time someone on the team finishes their current work and picks up the next task they'll pick up the world's greatest feature and start work on it the other place where kanban shines is when there are problems agile teams are planning for an iteration what if their plan is wrong the risk in agile is that one or two weeks worth of work for the team is and that's still quite a lot of work may go wrong what usually happens when things do start to go badly is that you don't really notice until quite close to the end of an iteration planning tends to be at the level of iterations or sprints in agile teams but progress within an iteration or sprint can sometimes be a little bit trickier to see in any definitive way so we get people working hard to make iteration deadlines sometimes misguidedly cutting corners on quality to try and make sure that they hit the release at the end of the iteration sometimes squeezing testing out maybe even deferring it to the following iteration this isn't really what agile is meant to be but it's still pretty common if you can't get everything that you planned finished for the end of an iteration can you safely release what you have cherry picking the features that are complete or do you have to call that iteration a bust and continue in some kind of mini death march and roll the goals over of that iteration over to the next this isn't always as quite as bad as it sounds how the teams organize themselves and how the code is structures has a big impact on how difficult or not decisions like these end up being in kanban there's no fixed release plan at all no sprint agreement no built-in expectation that in two weeks time we will have finished this collection of features kanban is a flow-based process it kind of inverts the problem completely instead of working on predicting the future even if only in terms of an iteration or two ahead in time it focuses exclusively on now the current state i suppose that a kanban backlog is a form of plan prioritizing the work the team expects to do but it's easy to discard things reorder things or add new things anywhere in the list at any time so we always represents our current best guess once members of a kanban team pick up pick up some work and aim their aim is to work on it to completion kanban boards are designed to consciously limit the capacity of the team to do work so that each person or working group a pair perhaps is only ever working on one finger at a time in lean terminology this is called one piece flow we do one piece of work through to completion kanban teams create a kanban board to visualize these flows so here we have a team that can do three things in parallel let's imagine three pairs of people working on new features together someone working as part of the team maybe a product owner maybe somebody else has sorted the features based on some notion of their value pair a comes free and picks the next priority item from that list and starts work on it maybe breaking down the job into tasks that they think will be helpful these tasks are for the benefit of the people doing of the work not for anybody else but even so it means that the fine-grained plan for the work is visible to other people they start work on the task that they think that they need as they learn more they may add more tasks or throw some away that's totally up to them meanwhile other teams are doing the same thing picking the next priority and working on it when the work is complete and the team is happy the tasks are discarded and the card on the wall representing the work is moved over to represent that it's complete kanban teams work on the feature in front of them and when that feature is finished it's finished so it's available for release if you're a follower of this channel you've probably already guessed that i prefer kanban for organizing our work and planning it's simpler more reactive to change and crucially for me it reduces the batch size of our work to smaller pieces so we can get a clearer picture and more chances to learn there are some downsides though i worked on a full-blown lean project in the early 2000s for a period of six to eight months we used kanban for planning and organizing our work what we found though was that over that period of time it started to feel like a little bit of a treadmill pick a feature work content on it till it's finished move on to the next one and so on over time we realized that it was stressing us a bit it was becoming tiring my preference these days is to take a bit of both kanban and agile thinking one of the big advantages of the agile approach is that it establishes a regular cycle the iteration on a nice human time scale we start an iteration looking forward to the cool new stuff that we're going to be working on we get together in a kickoff meeting and discuss how things went in the previous iteration and ways that we could think of improving maybe we have a cake to celebrate the successes of the previous iteration that's the stuff that by preference i will take from agile planning we'll have a retrospective to see how we could improve we'll discuss upcoming work in a general sense and we'll socialize a bit as a team and take that little step back from the detail lift our heads and see where it is that we're going but that's all really i don't want the plan i don't want the backlog grooming we'll do that on demand whenever we decide we need to change our plan i don't want work allocation or anything else kanban looks after the rest the degree to which teams like this discuss upcoming work tends to be consciously a little bit vague it isn't fixing us to some guess of when any given feature will be released in part that's because in my experience at least this is the most efficient approach to development so i think you'll get the features sooner than by any other approach this way and in my experience the quality of the output will usually be higher too so agile versus kanban not really kanban reinforcing agility certainly thank you very much for watching [Music] you

Channel: GOTO Conferences

Views: 11,265

Keywords: GOTO, GOTOcon, GOTO Conference, GOTO (Software Conference), Videos for Developers, Computer Science, Programming, Software Engineering, GOTOpia, GOTOxDaveFarley, Dave Farley, Agile, Agile Development, Kanban, Lean, Continuous Delivery

Id: N9coClM4qf8

Length: 17min 18sec (1038 seconds)

Published: Fri Apr 01 2022