Moving from Scrum to Kanban
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Title of Series | ||
| Number of Parts | 110 | |
| Author | ||
| License | CC Attribution - NonCommercial - ShareAlike 3.0 Unported: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal and non-commercial purpose as long as the work is attributed to the author in the manner specified by the author or licensor and the work or content is shared also in adapted form only under the conditions of this | |
| Identifiers | 10.5446/50986 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
NDC Oslo 201212 / 110
1
2
3
5
7
9
11
12
15
19
20
23
24
27
28
29
31
32
33
35
36
37
38
39
41
43
46
47
51
52
56
59
60
61
62
63
65
67
70
71
74
75
77
79
80
81
83
87
91
92
93
94
95
96
97
98
100
103
106
108
110
00:00
Right angleLogicKanban <Informatik>Software developerInclusion mapCodeSelf-organizationSoftware developerLattice (order)Presentation of a groupForm (programming)Multiplication signMathematicsComputer programmingBitSoftware testingKanban <Informatik>SphereDifferent (Kate Ryan album)Computer animation
01:03
Software developerKanban <Informatik>Kanban <Informatik>Lattice (order)Mixture modelSelf-organizationComputer animation
02:42
Software developerSoftwareProduct (business)Software frameworkProduct (business)Spring (hydrology)Software frameworkDiagramParameter (computer programming)MereologyCodeCore dumpCone penetration testCuboidKey (cryptography)Kanban <Informatik>Multiplication signDifferent (Kate Ryan album)Computer clusterComputer animation
03:32
Software developerProduct (business)Electronic program guideHorizonSeries (mathematics)Projective planePhysical lawFeedbackProduct (business)View (database)Key (cryptography)Multiplication signDifferent (Kate Ryan album)CuboidGoodness of fitQuicksortComputer animation
04:45
Constraint (mathematics)CollaborationismoutputSoftware developerProduct (business)Lattice (order)Cycle (graph theory)Letterpress printingMechanism designSoftware developerQuicksortAnnihilator (ring theory)BitSoftware testingFiber bundleSturm's theoremMultiplication signCombinational logicPhysical lawTerm (mathematics)CuboidComputer animation
06:41
Product (business)Software developerSoftware testingBitPhase transitionSoftware testingProduct (business)Coordinate systemSoftware developerProjective planeRight angleRoundness (object)Combinational logicMultiplication signSoftwareGoodness of fitSelf-organizationComputer animation
08:58
Software developerInformationState of matterSource codeLine (geometry)QuicksortMoment (mathematics)Multiplication signComputer animation
09:44
Convex hullIterationSoftware developerPoint (geometry)Revision controlLaptopMultiplication signOnline helpSelf-organizationCumulantDifferent (Kate Ryan album)FlowchartView (database)Template (C++)AreaMereologyTrailProduct (business)Software developerComputer animationDiagram
11:15
Product (business)PlastikkarteKanban <Informatik>Software developerSoftwareQueue (abstract data type)Kanban <Informatik>DataflowMultiplication signBitLattice (order)Visualization (computer graphics)MathematicsDifferent (Kate Ryan album)Product (business)PlanningEstimatorCASE <Informatik>Software developerSelf-organizationWordProcess (computing)Point (geometry)Physical systemExecution unitTerm (mathematics)NumberDecision theoryInformationSlide ruleComplex (psychology)Ideal (ethics)Arithmetic progressionMathematical optimizationAxiom of choiceMathematical analysisQueue (abstract data type)Library catalogSoftware testingMetropolitan area networkLetterpress printingIntegrated development environmentMereologyInferenceDemosceneCycle (graph theory)Computer animation
19:08
Software developerExecution unitMotion blurSoftware developerPhysical systemSoftware testingPlanningSoftwareState observerNumberInferenceDisk read-and-write headAreaWeb browserGreatest elementNormal (geometry)Data managementDemo (music)WhiteboardTerm (mathematics)Topological vector spaceProduct (business)TrailComputer programmingFocus (optics)BitLattice (order)Block (periodic table)InternetworkingComputer animation
22:31
MereologyOrder (biology)PlastikkarteKanban <Informatik>Control flowAutocovarianceLine (geometry)Physical systemMathematicsPoint (geometry)StapeldateiProduct (business)PlastikkarteWave packetPatch (Unix)BitCellular automatonDataflowSystem callLevel (video gaming)Order (biology)Kanban <Informatik>Factory (trading post)Computer animation
23:49
Process (computing)Limit (category theory)Software developerBitProduct (business)Library catalogProcess (computing)WhiteboardComputer animation
24:51
DataflowSoftware developerView (database)TrailVisualization (computer graphics)Revision controlTwitterLine (geometry)Arithmetic progressionFlowchartWhiteboardLimit (category theory)Physical systemPlastikkarteTelecommunicationCumulantRow (database)Lattice (order)DataflowPhysicalismInformationComputer animation
26:29
Process (computing)Software developerSoftware testingMathematical analysisDifferent (Kate Ryan album)State of matterCuboidProcess (computing)Analytic continuationCycle (graph theory)Multiplication signWhiteboardPlanningIdeal (ethics)NumberSoftwareBit rateAverageSpreadsheetProduct (business)DataflowBitCartesian coordinate systemValue-added networkPhysical systemSpring (hydrology)Right anglePoint (geometry)Computer animationDiagram
28:46
Software developerChannel capacityBuffer solutionFocus (optics)Physical systemWhiteboardProcess (computing)Software testingMultiplication signNormal (geometry)Kanban <Informatik>SoftwareSoftware developerChannel capacityPhysical systemWorkloadProduct (business)Buffer solutionDataflowBitMeasurementMereologyMathematicsLevel (video gaming)Control flowComputer architectureDifferent (Kate Ryan album)WebsiteClosed setLine (geometry)1 (number)Instance (computer science)Hand fanAttribute grammarWeb pageExtension (kinesiology)Connectivity (graph theory)Ideal (ethics)Computer animation
33:16
Software testingMathematical analysisSoftware developerLimit (category theory)Ideal (ethics)Limit (category theory)Kanban <Informatik>Musical ensembleDataflowArithmetic progressionSoftware developerPhysical system1 (number)State of matterOperator (mathematics)Computer animation
34:27
Limit (category theory)Maxima and minimaTelecommunicationMessage passingLimit (category theory)Focus (optics)DataflowNumberState of matterMaxima and minimaAxiom of choicePhysical systemProcess (computing)Kanban <Informatik>Computer animation
35:47
Software testingMathematical analysisSoftware developerKanban <Informatik>Limit (category theory)Physical systemArithmetic progressionLimit (category theory)DataflowKanban <Informatik>Streaming mediaState of matterWhiteboardBuffer solutionMappingProcess (computing)Greatest elementMoment (mathematics)Representation (politics)Mathematical analysisLattice (order)Term (mathematics)Multiplication signLatent heatQuicksortExistential quantificationQueue (abstract data type)BitBlock (periodic table)Right angleBus (computing)Computer animationDiagram
40:24
Limit (category theory)WhiteboardÜberlastkontrolleQueue (abstract data type)Statistical dispersionLimit (category theory)WhiteboardRight anglePhysical systemLattice (order)Sign (mathematics)QuicksortPhysical lawDifferent (Kate Ryan album)Commitment schemeComputer clusterComputer animation
42:35
Software developerLocal area networkGroup actionWhiteboardProduct (business)SpacetimeWeightSoftware bugNumberLimit (category theory)Computer animation
43:43
NumberSoftware bugPhysical systemDatabaseDirection (geometry)Insertion lossComputer animation
45:01
FrequencySelf-organizationMultiplication signLattice (order)Focus (optics)LacePrice indexCuboidComputer animation
46:24
Event horizonIndependence (probability theory)Limit (category theory)Kanban <Informatik>CuboidSelf-organizationFrequencyDifferent (Kate Ryan album)Lattice (order)Event horizonMultiplication signView (database)Cycle (graph theory)Goodness of fitPoint (geometry)Computer animation
47:14
Software developerMultiplication signGoodness of fitPoint (geometry)View (database)WhiteboardPlanningIntegrated development environmentAsynchronous Transfer ModeMassKanban <Informatik>Sound effectLattice (order)Product (business)Self-organizationStandard deviationLevel (video gaming)Computer animation
50:34
Rule of inferenceSoftware developerRight angleProcess (computing)Self-organizationOrder (biology)Multiplication signProduct (business)Streaming mediaKanban <Informatik>Logic programming
51:49
Software developerTwitterTask (computing)1 (number)Classical physicsSoftware developerSoftware testingKanban <Informatik>WhiteboardTelecommunicationEvent horizonMultiplication signProduct (business)Physical systemCycle (graph theory)QuicksortSimilarity (geometry)Lattice (order)Representation (politics)Pattern languageGroup actionBitPredictabilityDependent and independent variablesMereologyArithmetic progressionWordDifferent (Kate Ryan album)Limit (category theory)DataflowMarginal distributionFigurate numberProcess (computing)Rule of inferenceRight angleInstance (computer science)Moment (mathematics)Key (cryptography)PlanningNetwork topologyTerm (mathematics)Goodness of fitFlow separationReading (process)Computer animation
Transcript: English(auto-generated)
00:01
Hello everyone, my name is Rachel Davis and I'm going to be talking to you today about moving from Scrum to Kanban. Now this is actually the first time I've given this talk, I've given lots of different talks and this is when I was talking to the organizers, they said it would be good to have a presentation about Kanban and I thought actually what people are struggling with
00:25
is to move or to figure out, like if we're already doing some form of Agile, how do we get the best of both or why would we want to change? So a little bit of background about me, so I started out as a software developer but I have become a bit post technical,
00:45
so I haven't been writing any code for about the last five years, I did work in an XP team in 2000, I was doing test driven development and pair programming, so really the methodology that I know best in the Agile sphere is XP.
01:00
Then I moved into becoming a coach, lots of organizations are wanting to get started with Scrum as an initial approach, so I've been working with Scrum teams probably for the last six years and more and more the teams that I'm meeting are looking at other ways of bringing lean ideas into the way that they work and Kanban is a particular approach
01:25
that has been starting to be more widely adopted and then people are trying to work out do we go that way or do we not go that way or do we kind of have a Scrum ban mixture. So, oh also I have written a book about Agile coaching, so that's, I don't think it's at the bookstore here,
01:43
there's a different one about Agile coaching. So, please I know that this is Norway and you may not feel like perhaps asking questions, but please I do encourage you if I'm talking about something and you have a question you think I wish she would talk about this, raise your hand, let me know that you have a question.
02:03
So, my experience is in the industry lots of teams are using Scrum, some people have heard about Kanban, some teams are using Kanban and this talk is really about how to evaluate whether it's a good thing for you to use and also what would you need to do to get started.
02:24
I'm actually going to start by talking about Scrum because I think if you're moving for any reason, it's usually because something isn't working. So, let's talk about what are the things in Scrum that might not work in the organisation that you're applying Scrum in.
02:43
So, just before we get started in that, who here is using Scrum in their organisation? Now, here's a very simple diagram, this is kind of a mic cone diagram of what Scrum is. So, it's a framework for developing and sustaining complex products.
03:05
The core part of it is that you have a backlog of feature requests and you're going to work in sprints and you make a little sprint backlog for the sprint that you're working in and every 30 days or less, you're producing a product increment and every day you're getting together as a team,
03:24
as a team approach to kind of work out how are we going to get towards delivering that product increment. Now, so sprints are really this time box and this is the key difference between Scrum and Kanban
03:41
is that Scrum is a time box driven approach. Now, this is like how it should work, this is the ideal view. Sprint product increment, sprint product increment, each sprint is like a mini project in itself, releasing something that could be valuable and used and going live and people using it and giving feedback,
04:03
but it's not really what I see most of the time when people are actually implementing Scrum. So, the good thing about sprint is you have a clear goal and if you were in Esther's talk earlier on, one of the things that brings a team together is you have a shared goal.
04:21
So, planning a sprint, we all get together as a team, we figure out what our goal is for this month or this two weeks and then we're working towards it, so we've got a reason to collaborate and we're not being pulled off onto all sorts of other different side projects. We've got, we're on this sprint, this is our goal and we're not also doing this and this and this other thing.
04:44
Now, the upside of that is actually from the outside, stakeholders know how to engage, they know when to expect things, there's sort of rhythm to the development, you have regular meetings where people can see what's been developed,
05:02
there should be demonstrations of the latest product increments, sprint reviews and there's a cycle for people to know when do they need to get their features ready for consideration for the next sprint, so it's a good coordinating mechanism. Now, let's talk about some of the downsides of Scrum
05:24
and I'm going to ask you also whether you've experienced any of these. So, one of the downsides of sprints is it's like any deadline, so we have a date, we have to do stuff by, we may have planned slightly optimistically,
05:40
there were the unexpected things that went wrong and so often it feels like that crunch time at the end of the sprint where we're rushing to get things done, things are maybe not done as properly as they should be, you know, there's a little bit of a rush on testing, a little bit of compromise on design
06:01
and you often end up with things that didn't quite make it, things that didn't get finished or even didn't get started. One thing I think is that this idea of having a time box creates this sort of strange way of packaging up items because the items are packaged up as bundles that fit in a time
06:25
rather than sensible bundles of features that you might actually want to consume and use. So, partly you do end up with this kind of, well, we've made product increment but it's not really what we want to go live with yet, so let's make another one and let's make another one.
06:41
So, I don't know who has come across this term Scrum-a-fall, anyone? So, it's a guy called Brad Wilson and he, I think he describes it as the combination of Scrum and Waterfall to kind of the worst effect, if you see what I mean, but it is very common in large organizations,
07:04
especially working on large products, and you might actually have parallel teams working on this, that you have a bit of a requirements phase and then the sprints are really seen as the development phase with a bit of testing thrown in. So, you're doing your sprints, you produce a product increment,
07:22
you put it on the shelf, then you produce another one and another one and nobody's really that interested in the product increment you made because it's not really going to go anywhere, it's going to be stacked up and in six months time we're going to release something. So, then it means that sometimes the testing isn't fully resourced
07:41
and we don't get round to doing all of the testing until, you know, maybe the fifth and sixth month and maybe we don't have all the people on board the project and, you know, maybe now we're getting towards that end point and, you know, some of the people involved in the requirements are no longer involved, they're looking at phase two. So, you get some of the classic things you would get with waterfall,
08:03
but you are really getting some improvements through having a good coordination within the team. So, the team is more focused, but the general product or product development is still a big lump of software that's being built. So, I don't know, I'm going to ask show of hands,
08:22
has anyone seen this kind of situation? A few people. And it just, the thing is, it's not wrong. I'm not here to judge or say this is wrong, it's just that some of the practices make less sense. You know, naturally the stakeholders just feel like,
08:40
well, I could go and I could go to the demo, but on the other hand, that's not really what's going to be released. So, maybe I'll just, I'm too busy right now, I'll go next time. And then maybe they go to the last one and then they go, that's not what we wanted. So, you can get this kind of Scrum waterfall situation. There are some other things which are in Scrum,
09:02
which I think teams find challenging. So, one of them is burndown charts. So, who here uses burndown charts in their teams? Okay, this is often a source of confusion and mystery. Burndown charts are supposed to make it easy
09:21
for people to see what's going on, but just purely having a slopey line that's the ideal line and a sort of line that is where we're at the moment often doesn't communicate that to people. It's not enough information because it doesn't kind of say where the work is. It's either things are finished or they're not finished, but you can't really tell within the team
09:41
what the state of them is. So, here are a couple of pictures of burndown charts. They're just random pictures that I happen to have on my laptop. And one of them, and what you'll find is that they don't look the same for a start, and you can work in organizations where different teams are using different burndown templates and from a stakeholder point of view,
10:02
that's quite confusing. This bar version has things that were added after planning and things that were removed after planning. Now, if you know about Scrum, you know that you're not really supposed to do that, but it seems like this team is kind of doing it.
10:22
They've adapted their burndown chart to kind of show, well, this is why we're running late because we have to do other stuff instead. So, we're not really even using that sprint as a protected capsule around the development. There's another one that I found, and on my laptop I had found
10:41
that I'd named this Crazy Burndown Chart. And it's because it is crazy. It doesn't actually help you know what's going on. I think, what does it tell you? It tells you somebody had too much time on their hands to do tracking, I think. And I don't think it really helps to see
11:02
where the work is. And so, one of the techniques you can use in Kanban is this cumulative flowchart stuff, which I'm going to come onto, and that's sometimes a way to get a clearer view of what's going on. Now, the other thing that is a bit of a mystical thing within Scrum is product backlog grooming.
11:23
Now, product backlog grooming is really the art of going through the near items on the product backlog and trying to understand what they are and get them clear. It's not really requirements analysis. It's much more trying to figure out what should be in there, what is valuable,
11:41
what's the next thing we should really be working on. But people find that it's somehow invisible work. The team is having daily Scrum meetings and they're focusing on what we need to do today. And the product backlog work kind of always takes second place. So you end up in this situation where people
12:02
kind of get towards the end of the sprint and they're going, ah, we better get some stuff ready for the next sprint, otherwise our planning meeting is going to take ages. So this is, but it isn't visible work typically. If you look at the burn down chart, that doesn't really tell you where you're at with your product backlog grooming.
12:22
And Kanban can help you with that. So there is one other thing that I wanted to mention and I didn't put a slide on it just because I thought it's contentious, which is estimating. So one of the things that I see in Scrum teams very often is a lot of confusion
12:42
about what units we're estimating in. Complexity points, ideal days, what does a point really mean? You know, people are always constantly thinking, right, when we say one point, we really mean half a day or three hours. And then there's a lot of discussion.
13:00
There's a lot of time that the team puts in in terms to try and estimate their product backlog, to try to get these magical numbers. And yet, are those numbers that useful as an art to predicting things? So, and when you do Kanban, one of the things that I think people
13:21
are attracted to Kanban is they think, great, now we don't have to estimate everything. And that's not necessarily true. You may still want to do estimation and you may still need to do product backlog grooming, those kinds of activities. But there is an illusion that people move to Kanban because they think they will get rid of planning meetings.
13:43
And I don't think that's the case. So let me talk about Kanban now. Now, I also want to know who here is using Kanban. Is anybody already using Kanban? A few people, cool. And I should say, I'm not pro-Kanban or pro-Scrum,
14:04
I'm kind of pro-sensible things to do that work for the team. So I'm trying to really say what's in Kanban that you might be able to use for your organization. So Kanban is, it's really the Japanese word for visual signal card,
14:24
or something like that. I'm not, I don't speak Japanese, so I may be entirely wrong. But to me, it's all about visualizing the work and using visualization as a way of triggering what we need to do next.
14:42
So you need to take some care in thinking about how we visualize it to make it something that people will respond to. Now, there are a whole bunch of books that have been written about Kanban for software development. So one of these, and I guess one of the main proponents
15:01
of Kanban is David Anderson, and he's written this book, Kanban, Successful Evolutionary Change for Your Technology Business, is his title. There are other books. There's a book about Scrumban. There's also a book which Henrik Niberg has written. I think there are a bunch of different books,
15:21
there are a bunch of different papers. People have been really trying this approach out. But it hasn't, I would say, it hasn't really settled into this is what we all agree Kanban is, isn't. Just the same as there's still debate within the Scrumban community about what's the correct unit to use
15:40
or the right way to draw a burndown chart. So you will get conflicting opinions within the Kanban arena, I guess. Now, what this does is it really uses two techniques that are really from the lean product development environment, I guess.
16:04
One of them is making things visual, and the other thing is trying to focus on flow by limiting work in progress. So working on fewer things, having shorter lists of stuff, having less inventory in the process. So a key thing about visualizing is if we can start
16:26
to really clearly see what the flow is, we can start to get the rocks out of the way to improve the flow. If it's too difficult to see what the steps that things go through, then it's harder to really look at optimizing the end-to-end flow
16:45
and people tend to do something called local optimization. So they tend to kind of say, well, let's just get the bit of flow between you and me working rather than let's look at the end-to-end flow. And people are very naturally thinking about,
17:01
it's very difficult to let go of what is the most efficient for me versus what is most effective as a throughput for the system. So it's something that feels counterintuitive because everybody feels they should just be busy all the time, but at the same time if you're busy, then you may be working too far ahead on stuff that you may not need
17:24
and actually your attention might be better placed into improving the system. So one technique that you use within Canman is to just start making the cues of work visible. So you're starting to make the inventory of work in the system
17:43
easier to see. So this is just a picture of wait times at Disney Park and because it's displayed, it allows people to make a choice. So what you're really trying to do is not just make the system cues visible
18:04
to the people working in the system, but also to the people who are making choices so that people understand what the typical wait time to get something is. If I'm asking for a feature and I don't really understand how long it takes between something going on the product backlog
18:21
and something actually coming out and being released, which can actually be weeks and weeks in some organizations, then I will not be making well-informed decisions. So it's trying to make information available to help people make better decisions. And what you're doing here,
18:42
it doesn't say how many people are in the queue, it's just telling you how long will you have to wait before you get something. And what typically you do in Canban systems is you move much towards cycle times. You know, what's the date we started working on something and the date we finished working on something rather than thinking about points
19:02
or what points are to time, those kinds of things. You're looking at cycle times. Now, here is a picture just from a scrum team and this is their initial steps towards Canban. So they are starting to make the work visible.
19:22
Now, I don't know if... Can you make any inferences from this board? Anything that you would... observations you would have about it? Can you see what's going on easily? It's a bit messy for a start
19:41
and actually, if you're going to get into making things visual, you have to take care that things are easy to read, that it is clearly set up, that column headings are clear to understand. For example, this board has a kind of a blocked area
20:01
kind of towards the top here. But it's not really clear what's in the blocked area, where the blocked area ends or how things get in there or how they get out of there. And if you took a closer look at these tickets, so they kind of started with good intentions. They thought, well, what will use something
20:22
to print out the tickets in our defect tracking system because that's what they're using for their planning software. But the thing is that the program that they're using, the main thing it prints in big, big letters or rather numbers is the reference number. So if you look closely at this,
20:41
it's just a whole... the big bold text is some long reference number. So in the stand-up meeting, people are saying, well, I'm working on issue number one, two, three, five, six. And that's not an easy thing to communicate. The other thing that it may not be clear from this board
21:01
is there's two teams. They're both writing software to run on Internet-enabled TVs for the Olympics. And the team at the bottom is using a particular browser. The team at the top is trying to do an HTML version.
21:20
Actually, what you'll see is there's a blank area in the top team, and that's because... and that is... that area is ready for test. What they're doing is they're working in one-week sprints, and then at the end, they kind of go... put everything over ready for test, and then nothing gets tested in that one-week sprint,
21:41
and everything carries over to the next. And so they're kind of got a... Sprints are being used to build stuff but not build on test, so there's no meaningful product increment. And actually, also then, the kind of demo that they have isn't a normal sprint review. It's kind of a management walk-around
22:01
where people show things working on the TVs in their area. So again, there's no real accountability to this is what's working and tested. It's more like, you know, here's some stuff. Look how cool it is. And then... So it's not an integrated team in terms of the development and the testing. So you need to do a little bit more
22:22
than just make the work visible. You start needing to try and sort of focus on, let's not have too many things going on at once. So Kanban is used in the Toyota production system. This is really going back to more lean manufacturing, lean production.
22:41
And if you go to a Toyota factory and look at the production line, cards are used in multiple ways to control the flow. So each order for a car has a Kanban card that goes with it that goes through the production line with it. Also, the stock around the different cells
23:01
on the production line have their own systems of cards so that you don't have, you know, 100 wheels. You just have a stack of 20, and then as that gets used, you pull in another 20. So they keep their supply chain, their supply levels low so they're not building up batches of stuff. So they don't on Monday make a batch of red cars
23:23
and on Tuesday make a batch of black cars. They have to change their paint system so that they can make a red car followed by a black car followed by a white car, and that's really improved the flow. So they're using Kanban to be the ticket for the order
23:42
and they're focusing on how can we improve the flow per order through the system. Now, so this is, I guess, a little bit of a sketch of something that's really a bit like the team we were looking at before.
24:02
They've got some stuff that they're about to work on. This is stuff that they are working on, but they don't really have anything ready for release because they're really thinking, our real release is to make something available for the Olympics. And these mini one-week sprint product increments, well, they're not going anywhere so we don't really care about them that much.
24:22
So one of the things to do is to start focusing on releasing stuff, so to have fewer things in the pipeline and actually get that all the way released. And when you start limiting the work in process, so you're perhaps doing less product backlog grooming
24:40
now and you're now focusing on what's the next thing to release and what's stopping us from doing that. Now, as well as having boards that visualize this flow, you can also use a technique called cumulative flow chart.
25:02
So I don't know, is there anybody here using cumulative flow charts to represent what their board information is? Maybe I should also ask, is anybody using a board that looked like that board I showed you with columns and cards on it?
25:22
A few people. Now, who is not using a physical board but they're using an electronic board? Now, there's absolutely nothing wrong with using an electronic board. The same principles apply. It's just easier and more tangible to explain it with the physical cards.
25:41
And I think when you have the limits of a physical board with physical cards on it, you start to realize that you've got too much work in progress more quickly. When you're using an electronic system, it's often easier to keep adding and adding and adding rows and tickets and then it starts to be a lot of things
26:01
that you're discussing when you have your daily scrum meeting. So cumulative flow charts, I think I see them really as being a more useful version of a burndown chart because what you're trying to do is trying to make not just the general trend line visible
26:21
but actually the view of how many items are in each of the columns of your board. So I'm just going to go through a few examples. So here's a very simple one and I've just tried to keep this simple so that you can get the basic principles. So you'll notice that the vertical axis
26:40
is not points, it's not ideal days, it's number of things. So it's just number of items in any one state which makes it quite easy to create it because you just look at the board and go one, two, three, five, okay, and then on the next one and you usually do this in a spreadsheet. I haven't been using planning software to generate these.
27:01
I've been using spreadsheets. This is a very simple process. It only has three states. So it's like there's some work that's on the product backlog that we haven't started. There's the work we're actually doing and there's the work that we've released. And what you'll see is that the green stuff is gradually increasing
27:22
at a steady rate and you can look to see how many items are in process at any time and you can look across ways to see roughly how long does it typically take and you'd start to look at what average cycle times are for things. It does assume that items are roughly similar sized.
27:43
So that's not, you know, and if you've got odd-shaped items, your flow will be a bit more ragged. Now, if you're doing scrum, then what you'd see is really this kind of slightly stop-start. You know, you release some stuff, you do another sprint. There's more stuff released, do another sprint.
28:02
And if you use Kanban, you're not using sprint. So Kanban doesn't have the idea of wait until the end of a time box. You really are releasing as you go. So as soon as something is finished, release. Then the next thing, release. So it works very well with a continuous deployment setup.
28:24
Now, just to illustrate what scrum-of-fall would be like if you used a cumulative flowchart, you probably have a lot of different states and notice that many weeks go by before you actually have anything ready to release. So you're not generating the value.
28:41
There's a long cycle time there before you get your value. Now, what these charts can help you see and what the boards can help you see are bottlenecks in your process. And bottlenecks, the definition from the goal is any resource, so that's a person or a thing
29:04
or a machine, that their capacity is less than the demand placed on it. Now, it could be we've got six developers and one tester. That tester then becomes the bottleneck.
29:20
Now, if we added six testers, the bottleneck would normally move somewhere else. It's normal in a system to have some bottlenecks and typically what people do to cope with bottlenecks is they create some buffers in their system. So if you know that you have a bottleneck,
29:41
what you don't want to do is have a situation where that person is waiting around not doing anything. So you just think about the classic thing you might do in Scrum where the development team is busy developing stuff and they haven't made anything available to test and then they say, oh, right, the last day of the sprint
30:01
is everything to test. That person really can't then cope. You want to level the workload and have some buffers. They've got some stuff ready to test that they can pull through the system. So what you start doing when you're using Kanban is you first of all have some basic columns and then as you start to understand your workflow better,
30:21
you start introducing some buffers to try and smooth out the flow so you get a better throughput. Now, yes, yes, yes, yes, I'm coming to that.
30:43
So I'm not yet talking about how you start doing it. I'm just trying to explain roughly what Kanban is and then what are the steps that you would take. So yes, I agree with you, yes. Any other questions just before I move on? Yes, yes, yes, yes, yes.
31:19
So that's an interesting thing is that
31:21
Kanban is a technique from a production line. Knowledge work isn't a production line. You're creating unique things every time and actually in software development, the items are very much different sized. You can get something very, very small like change some text on a page or build this new component or improve this performance and reliability of the system.
31:44
They're kind of different sized items and so one of the challenges really is that Kanban works best for similar sized items. So typically what teams might do is have columns where you're trying to break those down. So visualizing that product backlog grooming activity
32:04
so that you're breaking things down into similar sized features so that then you can start to use this kind of flow-based approach.
32:27
Yes, yeah. I think that's actually a challenge for Scrum as well. So for instance, non-functional requirements or quality attributes, they are things that you have to be checking all the time
32:42
rather than, you can't say, oh, we've done the architecture because you keep changing it. So to some extent, or you can't say, sprint one, we've delivered performance because you're gonna keep having to keep checking that it's keeping to a level performance. So I agree, but I think that's an issue
33:01
with both Scrum and Kanban. You have to figure out a way to do that and being clear about the measures that you have and the way that you're gonna inspect for those measures is part of the answer. So I'm gonna move on a little bit now. So this cumulative flow charts,
33:20
I've showed you some kind of ideal ones which are a little bit smoother. Typically what you start to see is that these bands start to expand where there's somebody who's blocked and waiting. And so what people start doing in a Kanban system is they introduce these WIP limits. WIP is short for work in progress.
33:42
And so what you're trying to do is impose a limit of how many things can be at a particular state and what you're doing is that, well, the way you operate those limits is that supposing you are a developer and you see that there are three things
34:02
that are already in development. If one of them gets blocked, you can't start another one. You have to try and figure out how to unblock the thing that is blocked or go to help somebody else where there is a further upstream activity that needs to flow through.
34:22
So I've got some text to write that out because I think sometimes that gets confusing. So how do we operate WIP limits? This is some text from David Joyce who has been running some Kanban teams at the BBC. So the limit governs the maximum number of work items that can be in any state at any instant.
34:45
So if I haven't reached the limit, I can pull more work in. I can start doing some more stuff but if I've hit my limit, then you can't start working on some more stuff and you actually have to either wait,
35:02
focus on process improvement stuff or try to help unblock the system and that really relies on team communication and it isn't helpful if everybody tries to help too much if you see what I mean. So if you probably want to in your team
35:21
kind of go, oh, we're blocked on this, so maybe you and you, we're gonna work to try and block it and you and you, let's try and do some look-ahead work and perhaps not focus on the making more stuff. What we're doing instead is we're thinking about how we could improve things, maybe looking at tools,
35:41
ways of improving the way that we work. Now, this is kind of a very ideal picture but really this is where you've got quite narrow work in progress limits and what you see is that the flow of items is happening more,
36:01
that you're getting things out of the system very soon. So almost as soon as you finish something, it's going live, as soon as you finish something, and you're focusing really on keeping that cycle as short as you can. Now, I'm gonna flip into talking about how you might get started with Kanban.
36:21
So the very first thing I think is you start with a technique which is called value stream mapping. Now, to formally do value stream mapping, as in the kind of lean textbooks, you really try to follow the work and use examples and look at how specific pieces of work,
36:41
how long they actually take, where do they wait around. So if you imagine, you might write a requirements document and then it might be waiting to be signed off and you might have to wait for the steering committee to get together and then wait for a team to be formed and there could be all of these different steps. Now, it's helpful to do these practical examples
37:04
where you actually follow a piece of work and look at how long it really takes to get through but often in terms of setting up a board for a team to use, you may be better off to start just sketching out what is it we think our workflow is and so what happens in this picture?
37:22
There is a little stick person and he's starting to create a book of work. So he's working in a bank and he gets traders asking him for stuff and sometimes he says to the traders, no, and other times he says,
37:41
oh yeah, that sounds like a good idea, yeah, let's put that in our book of work and so that's your first queue of work starting to form and then you start working with the team to figure out what would it take to do these things. There needs to be a bit of analysis to understand what the impact is, where the piece of work will have to be done
38:01
in the banking system. So you're doing some of the sort of analysis work and so then what you're doing this team is really discussing what is the flow of items and this team, so I mentioned about estimating, this team do choose to do estimating. They say well we want to do some t-shirt sizing
38:20
just so we can decide like if something's too big we might need to actually have some meetings to break it down. They also started, I don't know if you can quite see, but at the bottom here they start having some definitions of done around the columns but not a definition of done at the very end
38:40
but is this ready for us to move forward to the next and then there are some little buffers starting to appear. Now this is just what it looks like. It's a sketch. It's what they think they might do. It's a future sketch.
39:00
It's an illustration. It's not a precise process definition. But it helps to have that conversation and start talking about what the process is, what the states that the work goes through and where does it wait around. But practically the team's only gonna know how does this system work when they start operating it.
39:22
So this initial thing, get the sketch done, then try it out. So step two, the team is now based on their whiteboard sketch. They've started to make a board design. They have some names at the tops of the columns. They haven't put their WIP limits on yet
39:42
and that's partly because they want to get used to this new way of working. But notice that they have really tried to make it easy to read, make it clean and tidy. They've got super sticky post-it notes that won't fall off.
40:00
They have, you can't quite see it, but they have some magnets that they have bought to represent team members. They haven't put those on yet. And they started, those definitions of done that they had, they printed them out and they put them at the bottom of the columns. Now that's, this is a board of just representing where's our work at the moment.
40:21
Then they start using it. And in Canva you typically do have a daily stand-up meeting, but what you do in your daily stand-up meeting is you are looking to see, is the board representing work at the moment? Are there blockers that are not being dealt with? Do we have any bottlenecks? Is anybody kind of blocked or too busy?
40:43
And you're typically, and this is different than a Scrum stand-up meeting, you're focusing, you tend to focus from the, I'm just trying to think how this looks to you, from the done column end first. You're looking back to say pull the items this way.
41:02
You're not stuffing more things in. So it's a pull system. So you're typically, when you're looking at the work, you're not looking at what's the next thing that we should work on. You're more normally thinking, what's blocked that needs to be moved forward? And you tend to run this meeting looking at, talking about the work,
41:21
not a person by person. So it's not driving out this kind of commitment, you know, what did you do today? It's much more saying where is this piece of work? And if you're not working on any of those things on the board, then you might not actually say anything. So you're really trying to shift this into
41:41
does the board represent what we're doing and do we need, does the board tell us that we need to do something different? Now, as you start doing that for a little while, you can start to get a sense of what would be sensible WIP limits for us to try. Again, this is our initial WIP limits.
42:02
We may need to reflect and add more columns. We may need to change our WIP limits. But I think I'd be right in saying that David Anderson normally recommends start with high WIP limits and then gradually tighten them. So if you've just got a WIP limit
42:22
of one thing per person and then one thing gets blocked, you're running into blocked quite soon. So you might want to have slightly more relaxed limits to allow people to have something to do. So now, this is the team after they've been going for a few weeks.
42:42
And if you look, you can see that there's too much stuff on the board. And they haven't really been following the WIP limits. So this is a team that's still learning. And this is what you're trying to do with the WIP limits is to become more aware of when you exceed them.
43:01
The way that they've designed their board makes it quite easy for you to put another Post-it note in so you can see how many Post-it notes are crammed into the prioritized backlog column. There's too many things there. One technique that I've seen teams use is actually design your board
43:22
so there are literally only spaces for the amount of tickets that you're allowed to have and then put kind of a cross thing so that you can't, you're very conscious, oh no, look, we're going past our limit. So you may want to think about that. But more crucially, what this prompts is we need to reflect on what's going on.
43:42
So this is a picture from a retrospective and it is a picture of a cake that is shaped like a bug and it has a number on it which is 1133. This bug took many weeks for the team to sort out
44:01
and somebody in the team made a cake like the bug and they ate the bug. But they also used it as a way to celebrate we've killed that bug but how did it really happen? Why did it take us in this direction? Why was this so difficult for us to fix? And a lot of that came down to not having the knowledge
44:21
in the team and they needed to expand their understanding of the other systems. This was a, something was very difficult to replicate that was happening in one of the databases and it was difficult enough to replicate and really, really difficult to figure out what was going on. But it was worth having a retrospective
44:41
literally just about that thing and what you want the team to do is to become more responsive to noticing what's happening, what's slowing them down and thinking how do we make sure that doesn't happen again? So, yes, yes.
45:30
So that hasn't, it just hasn't been my experience that that's happened but I can imagine it might happen and if that is happening it might be an indication
45:40
there's too much stuff going on. If you're finding that the meeting is kind of getting bloated that's possibly too many things to discuss. We probably are trying to do too many things at once. So my reaction would be maybe to kind of do less, have fewer blockers and then have a smaller focus.
46:03
Now a question that a lot of people worry about when they're moving towards this approach is they worry about where do all our meetings go? So I mentioned retrospectives. Now normally in Scrum we have those at the end of the sprint. And you know like you have your release or you should have your release at the end of the sprint.
46:23
So in Scrum the meetings are pinned to the time box and the release is pinned to the time box and what you're trying to figure out when you move to a Kanban approach is really what's the real frequency that in your organization how often does it make sense to get stakeholders together?
46:41
How much does it make sense to get the team together? Do you need to have some meetings or some events that are triggered by hitting a limit? So there are, when people move to use, when teams move to using Kanban they're not throwing everything away.
47:01
It's just they're starting to realize that they don't all have to be kind of bolted to this cycle, that you can have different frequencies for different things. So it's not that retrospectives disappear or go away. Now I'm getting towards the end of the time and I want to now take the other point of view
47:22
and kind of say well okay, so what are the good things in Scrum that we might lose and what would we want to be careful about? So you don't want to throw the baby out with the bathwater. I don't know if you have that saying in Norway we're doing in the UK.
47:41
So I have come across teams that have been trying to use Kanban and things are not good and I have actually been in environments where we have gone back to using Scrum. Now the kinds of things that were happening for that to be a thing that we decided to do
48:03
was, and this is with a particular organization, they were making a news portal and they had, they'd just been making features as people suggested them. They had lots of features. It kind of got into this business as usual mode. You know somebody comes up with an idea,
48:21
you just build it and release it and it felt as if the team really didn't know where they were going or what they were working towards. There was, it just seemed like anyone could ask for anything and so there was this and this is something that can happen to Scrum teams as well. It's like you just, you can't see the view
48:41
outside the sprint. You can't see the big picture. You can't see the roadmap or the where are we going view and if you can't see that then it can feel demotivating. It can feel like, you know, I made, you couldn't, and I've experienced this on XP teams as well, is that we just release features
49:03
and we release features and we're an effective team but it feels like there's nothing big to celebrate. We're just doing lots of small releases of stuff and we don't really know where we're going and you can lose this sense of what is the product we're making or what's the big release plan.
49:22
You know, where's our product going. So sometimes, and especially if teams, and I've seen this where a whole bunch of people have joined an organization and they've just kind of gone along with what's happening so there's a big Kanban board and they have a stand-up meeting
49:40
and then they kind of go away and they don't really know what anybody else is doing and there has been a lack of the meeting coherence because if you think about it, one of the things that Scrum does is it gives, it helps the team establish a goal which binds the team together. If you have a big mass of people
50:01
and it's not very clear what the goal is, you can end up with factions and with people not getting on as a team and so that's something to watch out for really is that people are starting to just feel like a cog in a big machine and they're not really feeling accountability, they're losing.
50:20
It's that big team effect that you end up having. So I don't know, does anyone recognize what I'm talking about, this kind of effect? So what I've found is actually it can be helpful to get back to basics sometimes. Sometimes it does help to say, right, that this is a product we're working on,
50:40
this is the small team who are working on it, we're gonna work very closely with the product owner, we're going to have sprints, but the key thing is if you can do Scrum but do the product increments as serious product increments and not get into this Scrum-a-fall situation where it becomes this long, waterfall,
51:00
Scrum in the middle kind of situation. And I think sometimes when people are new to Agile you get people who will join an organization and maybe they said, oh yeah, I did Scrum in my last organization, but maybe they didn't really. And you can get people who are kind of passengers with the process and they don't really feel
51:20
engaged with it and sometimes it helps to just bring it back to a much simpler, more rule-based thing while people are learning. And then once they start to understand how things work, then increase the flexibility for changing stuff and move more towards a Kanban way of doing things.
51:41
Now, I think I'm slightly early in the timings, I think I've maybe got five minutes left for questions, so have you got any questions? Any questions, yeah? Yes, yes.
52:05
So you can, well, so you can have a way that I've seen people do, they have like a ticket which represents the user story and then they have like a little tail of tickets which represent the tasks, but they are small,
52:21
you know, they use a mini Post-it note things to have a few tasks. That, you have to really ask yourself, why are you doing that? And you wouldn't necessarily do, as you do with sprint planning, a session where you say, let's work out all the tasks for the sprint. You're much more, oh, we're about to start this item, let's figure out the task
52:41
because then we can work out how to share that work out across the team. So you might have that as a triggered thing that you do as you take a ticket into starting to work on it. And obviously you wouldn't do tasks for the ones that are small and kind of obvious. Does that make sense?
53:08
Yes, yes, yes. And actually a classic thing people don't show, for instance, is testing tasks.
53:22
So people kind of go, here's the development task and then we have a column for testing and we don't actually then unpack to say what are the testing tasks. So it very much comes down to the skills of the team and you have to think about, when you're creating tickets, what are you really trying to represent? What's your communication,
53:41
what communications does that facilitate? Now, all I would say is that Kanban leaves it open as this is a tool set that you're using so it's up to you whether that's useful for you to have a triggered event like every time we take a new ticket, we do that unpacking into tasks or do we say use the task to represent the workflow
54:03
so we have columns for them. But it's not something, basically, Kanban is much lighter and less processed than Scrum. And Scrum is pretty light. So it's even less. So one of the things that Kanban doesn't have,
54:20
for example, is roles. And it doesn't have any prescribed events. All it's saying is make things visible and limit the work in progress and then reflect on what you see. Try to look to improve your cycle times. And so that leaves it open to try all sorts of different experiments
54:40
to try and improve your cycle times. Any other questions? Oh, sorry. The question was, and I might not word this question exactly now because it's been a few moments, but it was if you,
55:02
so you were saying that there are user stories and sometimes they're different sizes and sometimes you might want to do a task breakdown. So would you do that in Kanban or not? And you could if you wanted to, but you might not. And I think the other part was
55:22
that sometimes some of these tasks when you break down an item are actually items in work, they're kind of activities in your workflow. So it might be that you don't have a task representing it because you now have a column representing it. So I don't know, was that a fair representation of your question?
55:43
Okay. Any other questions? Yes.
56:00
So I think it very much depends on how you establish them at this cadence of meetings. You clearly want this to be, you have some business people involved, but at the same time you don't want everybody at all of those stand-up meetings necessarily. You may want key representatives.
56:21
You might do something a bit like the product owner kind of pattern in Scrum, but you might not. One of the things you might decide to do is to have showcase events where you have everybody in the department goes to see those. So there's a bigger showcase. You might have a smaller group responsible for prioritization,
56:41
and it may be that two or three of those people are really sitting with the team, actively being part of that system. I think anywhere where you have separation, where you have the people apart from the people, so what you don't really want is for the columns on the Kanban board to be like departments who only talk through tickets.
57:09
And then I'm just remembering that I didn't repeat your question, so your question for the people who may not have known is how do you involve the business side in Kanban?
57:22
Any other questions? Yes? So you can't. And it's through the team kind of going, and yes, you could. Imagine you got some item.
57:40
So the question is how can you assure that the items are the same size? If you get a very big item, it's going to block the pipeline up, and it's going to have a long cycle time. It might be that that's a useful thing to release, and so you don't necessarily have to have things that are all the same, but it's just that if you are trying
58:02
to make predictions about things based on your average cycle time, it helps to have things that are more or less the same size, but you're not trying to force things to be the same size.
58:21
Yes. So if you had, just imagine, and you had a very big item, it would just be in process for much longer. You're not exceeding your limit by putting a big finger in. It just slows things down. So it's just that's going to start, people are, you want to encourage people
58:42
to reflect on that. It can, and it typically does vary, it's just that you don't want it to be very great. You would want, in an ideal world, you're trying to break down the items to sort of similar size-ish things,
59:01
but it may be that if you are really trying to release, and you've come up with a minimal marketable feature that you think, right, this is the thing that we want to put live, it may make sense to do a bigger blob of work. Now I'm just thinking, my time is probably up. I don't know who was going to remind me about 10 minutes.
59:20
Did you remind me about 10? I didn't see you. So I guess if there's any other questions, then please come and see me afterwards, but otherwise, thank you.