Is Kanban the New Scrum?
infoq.com
infoq.com
I'm an enthusiastic student of methodologies, consider Deming and Drucker are patron saints, and look for "one way flow" and "eliminate waste" (muda) opportunities everywhere.
I've now been on 4 scrum teams. I've been thru "master scrum training" three times. I have no idea what they're talking about. As far as I can tell, the Scrum methodology means talking about what "scrum" means. (Another possibility is that "scrum" is easier to say than "we have no idea what we're doing".)
See, I'm a GANTT chart, critical path, front load as much as possible, and iterate madly kinda guy. Worked great all the times I was in charge.
My current team is doing kanban. We have post-it notes that we move around. I have no idea what they represent. Chunking work like this is unnatural. There's really no way to infer the whole (work in the large, get a birds eye view) from the kanban project management artifacts.
I don't see how scrum or kanban relate to QA and testing. I've asked. (I used to be a QA manager, not very good, but I understood the work.) There's just arm waving "magic goes here" between the incompatible acceptable testing ("when are you done?") and the artificial sprint deadlines.
We also duplicate the kanban items in a bug tracking system. Ignoring the failings of Jira for a moment, I fail to see how how any mediated process can be "agile".
I could go on and on.
Since the whole point of Kanban, Scrum and similar systems is to manage your work, I'd say that's the place to start figuring it out. If you don't understand what work's being done, you can't have any input, and can't improve things (one of the other points of Kanban).
Also, Kanban is a pull system, not push, so it works very differently to most methodologies. You can see it in some of the modern web companies like 37Signals, with their "develop the HTML first" mantra, as well as XP and TDD.
Kanban doesn't relate to testing at all as far as I know, but Scrum has their "definition of done", in that everything should be ready to ship when it's done. Normally that includes being code complete, having automated tests, customer signoff, etc.
What I'm saying is that the kanban strategy does not apply to software development. Full stop. Does not map. Not applicable. Completely unrelated. Irrelevant. Moot. Nonsensical. Like measuring feline happiness in banana units.
If my employer could effectively chunk my work into itty bitty little stickies, they wouldn't need me.
#2 - When have you seen a scrum iteration planned around the QA/test cycle? Never? The sprints are defined by PHBs, devs grudgingly play along, QA/test can just suck it.
A real QA/test org would say a product is done when its done. I've not seen that happen on any scrum project. Rather, products are done when they've run out of time or juice (eg Yourdon's death march).
How is that not Kanban/pull? This pattern appears in a lot of places once you start looking for it, from SICP and their 'pretend the function already exists' onwards.
#2 - Testing is part of the feature, not bolted on. If a feature isn't tested, by both QA and your customer, it's not done, is it? Not in traditional Scrum, anyway. If your definition of done includes "ship it, untested, to the customer at the last minute", by all means document that with a poster on your wall ;)
And if the PHBs are defining both the length of the sprint and what goes into it, then it's not really scrum either. The whole point of the timeboxing is not to have a death march, but to avoid a death march, and a whole bunch of features glommed on, untested, at the last minute.
#2 - I'd agree with you about "by sprint end" for unit tests and any other harnesses that devs can write. But real QA/test work? I just don't see it. When I've been in charge, the three areas (reqs, dev, test) are interleaved. Makes for nice feedback loops. If dev and test had their own sprints, with test trailing by a week or so, I could almost see that working.
#2b - I've never seen sprints finish nicely, where unfinished work (points) didn't carry over to the next sprint. Total fiction that anything gets "done".
With proper project management, imho, the scope of work is predetermined and things get dropped to meet a hard deadline, or the deadline is pushed. And the final acceptance testing (e.g. go/no-go process), without fail, takes two weeks. That's tacked on to the tail of when everyone has jointly decided that everything's "done". I've yet to see that kind of quality, rigor, professionalism using scrum.
> the scope of work is predetermined
That's bullshit/impossible for most software, and the exact opposite of being agile and catering to real needs, not imagined ones. That's the whole point of agile methodologies, embrace change.
2. Done is done - it's a binary yes/no thing. Done but not tested is not done. Done but needs documentation is not done. This varies from place to place, but code-done is not done, and coding is usually only 30-odd % of the work.
2b. If that's the case, then you're overcommitted. Next sprint, drop back to what you managed to get done this sprint. The idea is to get things repeatable and features turning out in a maintainable steady fashion.
In practice, it works - if there's some discipline from both the devs and the business. If stuff gets shoehorned in, or devs are pulled off to work on critical stuff, then it works about as well as you'd expect (ie. not very).
#2 - Tom Lasseter (Pixar) supposedly said "We release snapshots of our movies, they're never done."
Kanban IS the new Scrum insomuch as it's the latest buzzword, but any agile process should be in itself "agile". As in, it's about shipping using the best possible process for your situation. Maybe that's scrum, or kanban, or waterfall, or something in between.
If you are using any of them you should ask what problem you have with your current process and what you are solving by doing scrum, xp, kanban, etc. Dit it work? Can it be done better? What needs to be fixed?
Iterate enough on your process and you'll be running like a well oiled machine regardless of what method you use. People get good at stuff with practice.
Where it goes wrong I think is when you worry more about scrum vs. kanban vs. xp vs. flavor of the week because the rules don't matter, doing your work better for whatever definition of better you're optimizing for is what truly matters.
Review is a major part of doing any sort of good work, but most people seem to overlook it when talking about scrum - "I did scrum and it locked us into doing stupid blablabla" means that you're not doing scrum.
Still, the feeling of being limited in freedom is the greatest annoyance to me and perhaps the fact that there's little room inside sprints for emergencies (at least this was how SCRUM was implemented in the last company I worked at). I really appreciate flexibility in ordering and the execution of tasks and SCRUM didn't grant me this ability.
I wonder if people around here feel the same ...
The other thing is that it seemed to remove any creativity of control from the developers. In some cases this is a good thing because developers get stuck in ruts and heads way in the sand. But small tweaks improvements that only show themselves to be available when you get into the code, can't' be done. They'll be put in the backlog, and generally never lifted to the top. And if you put them in, then it 'adds risk to the sprint'.
Ultimately it feels like it removes a lot of fun from the role of developing. Granted a lot of the above stem from the company and not necessarily the process.
Kanban is not a queueing system, it is a system for identifying bottlenecks in a supply chain and at all times minimising the amount of components that need to be manufactured. One of the key revolutionary features was that the supply chain extends to each component so different departments become suppliers to others.
What typically happens is that there are a certain number of kanban cards for each component. Each card represents one component. When a client takes a completed component from the stock, the associated kanban card goes to the start of the queue. Someone picks up the card and starts work on the component and the card follows the manufacturing process until the component has been completed. The card stays with the completed component until a client takes the component and the cycle begins again.
The purpose is that by counting the number of cards at the start (number of items requested by clients) and at the end (number of items constructed but not yet claimed by a client) it becomes trivial to identify bottlenecks.
Apart from this then-revolutionary pull-based process, Toyota's process had two other key findings.
1) the same worker should stay with each component until completion. One kanban card = 1 worker. If someone is assembling a car door, they don't half-complete a door and pass it on to someone else, they follow it from the time they pick up all the components to the time that it is completed. They found that this was the most productive way of working.
2) You do not deliver a faulty component to a client. That is, each component must be tested before going on to the next stage.
1. Self-organizing team. No one tells you what to do.
2. Fix bugs first. No one likes a backlog full of 132,423 bugs. Fix 'em as you find em.
3. Priority queue is decided by the whole team (with input from management) but is MACRO and has value goals associated with it (e.g. redesign signup - increase conversions 30%). Team figures out what that means, and measures it.
4. Features that don't "move the needle" (or moves it negatively) get yanked. Code has weight and tends to rust. If it doesn't meet the business goals but is showing positive reception (e.g. increased conversions at all) bias towards rework.
5. Only work on one thing at a time. This is super important. Don't have four or five stories "in process". Too much WIP = nothing gets done. If you are blocked on something, pull the andon cord and we can figure out what we need to do to fix it. Go read a book. Go for a walk. Do something other than starting another task.
6. Velocity helps us figure out what "reasonable pace" means. That's it. It's not used for long-range planning, just "are we working at a sustainable pace?"
7. Frequent retrospectives (every two weeks) help us nudge the ship in the right direction. We evaluate our process and see what needs fixin', and make sure that promises made are not abandoned due to externalities (management interference, or other non-technical reasons).
8. Iteration planning is short and is only used to keep the team informed.
9. Use passive information radiators to communicate status and progress instead of meetings etc.
Might I ask what tools you guys are using to manage this?
The funny thing is that none of this stuff is all that impactful in reality - you either have a good team, a bad team or more likely something somewhere in between.
Unfortunately there is an army of project managers that keep on pushing the new magical pill as if its progress.
*I don't know of any other profession that has such elaborate...*
Find the least amount of process necessary to get your work done and make sure everyone knows what's going on and has reasonable expectations.
It's honestly not hard to do this, and you don't need a crazy methodology to do it.
I've worked on scrum teams before, it can be done well if no one takes it too seriously IMO. Once you start guilting the team over the artifacts of scrum, it's fallen apart and become a detriment to your goal of Getting Shit Done.
Maybe the reality is that it only works for some kinds of programming, when not taken too seriously. But then why bother at all?
Just getting shit done doesn't mean bullshit arbitrary time-slices, half-day postmortems at the end of said timeslices, insertion of "project managers" who know little to nothing of either the actual business problem being address or the technical means used to address it, people working on a parallel svd implementation having to explain their work daily to web designers, blah blah blah.
The whole thing is a money making cult for the people who invented it, and a means of empowering a class of employees (project managers) who should exist only in very small numbers, if at all.
The claim seems to be that if you don't use scrum, you will just end up doing some horrible waterfall. This is a false dichotomy.
Why not just learn about methodology instead?
One of my least favorite aspects of the whole thing is having someone with little to no actual cs/math/ee/programming background tell me that since he/she/it used it for some trivial web programming, clearly my group doing r&d in machine learning were a bunch of morons who just didn't _get_ it because we thought it was incompatible with the kind of work we did.
Not all software work is cookie cutter.
I prefer Zed Shaw's methodology: http://programming-motherfucker.com/
Works great for manufacturing. Where it seems to fall down - in my limited experience - is when you try to apply it to IT.
JIT / lean just doesn't work well when you get into the IT ghetto.
It's still very much a craft discipline. Industrial processes don't work so well there.
Items going into different bins, using a signaling mechanism on when to create more of 'what goes in the bin' doesn't work for me when these 'items' in the kanban bin are 'product features'.