20 ms·

Ditching Scrum for Kanban - The best decision we’ve made as a team

173 points by fearenales 11y ago

gjmulhol 11y ago
I love this. We briefly flirted with scrum but now just have a much more Kanban-like system now, too. The only issue I foresee long term is that the sprint mentality of Scrum might recharge people and get them to, well, sprint, at product goals. Kanban, because it is never ending, might start to feel like a slog. There is never a way to have that feeling of "wow, we crushed it and cleared out our list. We are awesome." The list just extends forever. We have put measures in to help with this: primarily just having our engineers say at the beginning of the week what they hope/plan to get done this week (or two). Sometimes that is just noting subtasks in pursuit of a larger feature, but at least it borrows some of what is a very powerful part of Scrum: the social commitment that comes from standing up and saying "this is what I will finish this sprint."
- adamjc 11y ago
  Our crew use a Kanban approach, and to counter the 'slog' mentality, we have a retrospective every 2 weeks. I find that it really helps air what good we've done, and where we could improve. If we've accomplished a lot it's a great place to reflect and think positively.
  - gjmulhol 11y ago
    I really like this idea. We groom our Kanban board, which creates a similar effect, but not so explicitly. In your case or ours, one of the nice things about stepping back is reprioritization, which happens nicely in Scrum but not so much in Kanban. It is easy to define a path and never diverge only to wake up and realize you built an old vision.
- regularfry 11y ago
  I see it the other way round. We're doing Scrum (ish, I guess) right now, and the see-saw between either ending a sprint with a couple of late-night panic sessions to get everything out of the door, or ending it with most of the team kicking their heels with one pair still going up to the deadline is what feels like the slog. I see Kanban as much smoother: I don't see artificial, self-imposed crunch mode every fortnight as a positive. It's all very well aiming at a social commitment, but the way it works in practice is either a) you under-estimate and have dead time; b) you over-estimate and crunch; or c) you nail it and one sprint runs smoothly into the next. The trap is that c) never happens. I think what makes the difference is that we're continuously delivering, so there's no delivery ceremony between one sprint and the next to make the crunch mode mean something.
  - JoeAltmaier 11y ago
    Aligns with my experience. We're always continuously delivering, with madeup goals stuck in to align with arbitrary sprints. The real activity takes as long as it takes. Sprints are a stilted reporting structure, adding drama but little real value.
  - cmdkeen 11y ago
    The crunch approach to sprints is the killer. If you know you can't complete all the work in a sprint the answer should not be to bust yourself to try and complete it. Have a conversation with yourselves and the product owner to readdress what you can realistically achieve in the time remaining and then do that. It's a really hard thing to do, we all want to be the hero that saves the sprint. It also encourages you to end up with lots of discrete chunks of work in a sprint so you can complete 80% of your initial commitment and salvage a sense of achievement rather than getting 80% through a few big tasks but none of them actually done. A sprint with 4 developers and 4 tasks each estimated to take 2 weeks will almost never succeed. A sprint with 4 developers and 20 tasks each estimated to take a day or two stands a much better chance of success. Combine that with some metrics around "complexity per developer per available day" and you quickly end up with some charts showing productivity that is hopefully improving which will hopefully improve morale.
    - andrewprock 11y ago
      "hero that saves the sprint" To me, that rhymes with "hero that papers over bad management".
  - sandGorgon 11y ago
    in that case, do you use retrospectives at all ? if you dont have a goal post, then how do you retrospect.
  - alistairSH 11y ago
    ...ending a sprint with a couple of late-night panic sessions to get everything out of the door... My first reaction is you are not sufficiently grooming your backlog. Stories are left too large, with too many unknowns. If you tend to have a small number of large tasks, this is likely the case. That, or you just aren't very good at estimating. A large number of small tasks would indicate this problem. In the second case, you need to circle back with the PO and discuss which items can push to the next sprint. And make a concerted effort to estimate better during grooming and planning sessions.
_Codemonkeyism 11y ago
The context and mode defines your process: agile, lean or six sigma. Most companies have no clear understanding about their context (should read Simon Wardley [1]) or mode. Very good video from Markus Andrezak explaining the three "modes": https://vimeo.com/146522220 https://vimeo.com/146522220 (Must see) "The biggest mistake companies can make is to define their (one) process, culture, way of work. The work that needs to be done in a sustainable company differs in at least three fundamental ways." [1] Simon Wardley and Markus also explain why bimodal IT does not work
- bryanlarsen 11y ago
  Any text links? Thanks.
  - _Codemonkeyism 11y ago
    Simon Wardley blogs at http://blog.gardeviance.org/ http://blog.gardeviance.org/ One link is http://blog.gardeviance.org/2015/10/agile-vs-lean-vs-six-sigma.html http://blog.gardeviance.org/2015/10/agile-vs-lean-vs-six-sig... (I'm sure his view and his value maps on strategy will be huge in 5 years, although he is relativly unknown today)
    - sandGorgon 11y ago
      thats' a very interesting blog on strategy. Thanks for that - the only problem I see is that the "settlers" analogy has no real life mapping (unlike Pioneers <-> scrum and TownPlanners <-> six sigma).
PaulHoule 11y ago
Remember the triple constraints of cost, scope and time. If you are going to commit to releasing at a certain time you are going to have to let the scope slide. (Sometimes you can add more people on a 2 week basis but the ramp up time makes it usually impractical.)
- T-hawk 11y ago
  And this is exactly the difference between Scrum and Kanban. Scrum fixes the time periods and allows for adjusting scope, by cutting stories and features. Kanban fixes the scope while allowing the time period to be open-ended. Which methodology is more appropriate depends on which constraint a business wants or needs to optimize for.
  - PaulHoule 11y ago
    It is even better to do something hybrid that is tuned to the application. A bad thing about scrum is that it introduces a lot of phony deadlines that have nothing to do with the business; this is like the common practice of the boss setting a short deadline on the hope that they can control the cost (total hours) by controlling calendar time. On the other hand having a release every two weeks means you actually need a release. There are so many projects where a few programmers spend say 1.5 years building a components and hypothetically the application is feature complete, but they are nowhere near running it on a real server or packing it up for the customer with an installer and all that and it takes another 0.5-1 yr to figure out how to make a release. Then there is a stressful process of making a few more releases to fix the inevitable problems, then they go off and work another 2 yrs on the next release and then find they've forgotten how to make a release. The best thing about scrum is that it avoids that. The idea that the phony deadline is fixed is another problem. If you can slip the schedule by 2 or 3 days in scrum to address critical things in the scope there that is no problem but many agilists will fight that. Another failure mode is the project that is hitting the goals for milestones well (estimating things about 10% accurately) and that makes people feel good, but somehow you never get to the last milestone. I came in late and helped finish one of those severely troubled projects where there was a huge amount of blame to go around. Scrum and Kanban concepts were being used by teams involved, but a lot of people on my team including the boss and star programmer would not do what scrum required. My boss would bitch me out for making "rediculous" estimates of 4 hours to do something that involved a 45 minute build process and I wondered how the other people on the team didn't have this and I found I was the only one who was serious about estimating and that the star programmer did not do it at all. In the end we gave up on scrum and got heavy on checklists. We made a checklist with about 300 steps for a release process and it a was a stressful process but we learned how to do it reliably. Also we had a checklist of things to have done before the final release. It was not pretty but we did cross the finish line and get the product in front of customers and they liked it, so I felt I did my part and felt free to move on when it was done.
JoeAltmaier 11y ago
We've used Kanban (or something like it) for 20 years. Long before Kanban existed as a thing. Near the end of a project, we'd draw up the "finishers' list" with numbered items and initials next to each. Daily team review of each remaining item, reassign priority or responsibility as needed.
seanwilson 11y ago
> The rituals, mainly the standups and grooming sessions, were fantastic. Standups are a great way to keep everyone aligned on the work. Can anyone elaborate why they find standups useful? The planning board should already communicate what's being done, what's been done and why people are blocked. I only find them helpful if some people in the team generally don't communicate well what they're up to (e.g. during daily work, over lunch). Otherwise I find most people zone out during the standup and it just interrupts work.
- danmaz74 11y ago
  > I find most people zone out during the standup Out of curiosity, how long do your standups last? How big is the team?
  - alistairSH 11y ago
    I'm a project manager/scrum master, with a team that varies from 6 to 12 (roughly half the team is semi-permanently on-loan to other related projects/teams). My daily stand-up is usually 5-10 minutes. About 5 minutes of the standard "what I did, what I plan to do, and what's in my way". And 0-5 minutes of resolving problems (figuring out if I need to escalate, or if another team needs to be involved, etc). Anything longer than that, and we schedule follow-up meetings with a more correct set of attendees.
  - smileysteve 11y ago
    15 (goal) minutes with a 10 person team. Everybody didn't zone out every day, but most did, most of the time.
    - nickpsecurity 11y ago
      Exactly. It's a waste of time. Best to give a direct message or face-to-face telling the person what they need to know. Or not say anything if nothing is needed. At most, I'd say weekly meetings that were a mix of tracking project status and fun just for team-building purposes. Keeping people connected.
    - 11y ago
daigoba66 11y ago
> Perhaps Kanban is better suited towards long-lived product development than Scrum. This is the key take-away. And in my experience this is absolutely true. On the other hand, working now as a consultant where I am frequently on shorter-term projects with a definitive "end" for the engagement, the time-boxed sprint approach (or "Scrum") actually seems to work well. Scrum might work for individual "projects". It does not scale or coalesce well with long-term development and maintenance. > Perhaps there is indeed a natural progression of engineering teams adopting Scrum, then moving to Kanban. This also mirrors my experience.
- dvanduzer 11y ago
  Kanban was invented at Toyota in the '40s and '50s: https://en.wikipedia.org/wiki/Kanban https://en.wikipedia.org/wiki/Kanban Depending on the scale you're operating at, it's easy to see this as a waterfall methodology. There are lots of different words to describe organizing work, but what's important is that the methodology remains consistent enough that the team understands it. I think of time-boxed sprints as great for training. Humans aren't going to get better at estimating how long it takes to complete complex engineering tasks. But teams that work together over a long enough period of time can plan ahead better. (For example, time-boxed sprints would suggest that everyone has to take vacations at the same time for Scrum to be effective.) There are plenty of ways to deal with the fact that humans are asynchronous. I particularly liked this author's focus on team morale as a major factor.
- alkonaut 11y ago
  My experience too. A short deadline (few months to a year) and a green new codebase is a good place for scrum. A medium/large project (200 man years in the code over 10 years say), then it's a lot harder. A required refactoring in the codebase that would take 200h is a common discovery in issues estimated at a few h.
- kaizendad 11y ago
  I completely agree with this. In shorthand, having been Product Manager for a number of teams at a variety of companies in several industries, I've found that Scrum is better for teams developing mostly new features, with relatively little maintenance; and Kanban better for teams focused primarily on maintenance, with fewer large features. The rationale is really simple: for new feature launches, reporting and tracking vs. schedule is key; for maintenance, throughout is key. That said, regularly missing predicted story points by more than about 10% is not the sign of a healthy team. Being bedeviled by routine bug fixes is not the sign of effective management. Both are routine issues that most highly-effective teams, whether Scurm or Kanban, deal with well.
vincentkriek 11y ago
I really like KanBan and think it's a better fit for a lot of teams than SCRUM is. SCRUM works great for teams which have a stable backlog of work and an incidental problem that might pop up. If you can't keep a backlog stable for three weeks, you shouldn't do scrum. KanBan allows you to pick and choose practices from scrum that do add value, and ignore the ones you are just doing to follow the book. I worked in a team for 2 years that tried to do scrum because it's new thing that everyone should be doing and I feel it added nothing of value.
- cmdkeen 11y ago
  If you can't keep a backlog stable for a few weeks then you aren't doing project work you're on support or firefighting. Scrum is all about IT project work, Kanban is a more general "efficiently get a pile of tasks done" process which can apply to small IT tasks or building a car.
  - peterbell_nyc 11y ago
    Depends where you are in your product lifecycle. Pre-product market fit, it's often a bad idea to build and keep a stable backlog a few weeks in length.
cmdkeen 11y ago
As someone in similar circumstances a couple of things jump out which trouble me: Project Managers - That this role is mentioned, but not that of Scrum Master, is odd but unsurprising. PMs aren't mentioned in Scrum at all and often the way they want to do things clashes with the Scrum way of doing things. In the given example of the PM moaning about estimation Scrum at least forces that realisation quickly, something which Kanban lacks. There may well have been a Scrum Master, one of the things I've experienced them doing is guiding my team down from 1 month sprints through 2 week ones down to a single week. "It's really hard to plan for 2 weeks work" is a classic moment for the Scrum Master to say "what about..." "We tossed out the retrospectives" - Despite acknowledging them as a good thing? For me retrospectives are the most powerful part of Scrum. Stopping retrospectives might save you a few hours and some awkward conversations but is likely to hamper your continued development. Scrum is really good about moving a team to the "conscious incompetent" phase - i.e. you are forced to be aware you are bad at something and really need to work on it. Retrospectives are the way to improve and grow. "We kept our deadlines" - That you had deadlines (again the sign of a PM somewhere), and view them as important enough to mention again is interesting. It hints at quality not being the most import factor, which is one of the keys to doing Scrum well. For me moving to Kanban was a fix for a Scrum team that wasn't working well. I've worked on a good Scrum team, that took a while to get going, but got there by being able to be open and honest about poor morale and then dealing with it. The new team didn't get there, we moved to Kanban and while everyone is happier our productivity is much, much lower. I do feel there is a place for switching to Kanban - when the scope of the project has moved into "we know how to do this" space, often close to a major release (if you do infrequent releases) where 3rd party involvement plays havoc with planning. If you're dealing with points high on the "the business don't know what they want" or "we don't know how to do this" chart then, for me, Scrum is still king. If you're high on both axes then you might want to switch projects / companies...
- eitally 11y ago
  One of the biggest problems with Scrum (as mentioned in other comments) is that in a lot of large companies you have strong top-down enforcement of budgets, deadlines & expectations, which usually means the PMO is in control. This means you end up with a project manager as an awkward intermediary between the stakeholders & the product team. In almost every case, the product owner should be the project manager, but this very rarely happens in enterprise, and Scrum fails.
rabbitheart 11y ago
The team I was previously on tried to use Scrum and seemed to naturally fall into a similar model to Kanban; we got rid of what helped, and stopped doing what didn't. It was an amazing relief, especially since Scrum sprints and the numbers just weren't working. Sadly, our Scrumlessness was found out and it was implemented again shortly before I left. Morale was dropping steadily on the team already (unrelated reasons), reimplementing the parts we already knew didn't work was a bummer, and the Scrum leader talked down to me when I tried to advocate for the team.
- tablet 11y ago
  It is really stupid to NOT allow any team choose its own process. Your scrum leader is not a wise person, to put it lightly.
  - rabbitheart 11y ago
    I think the most frustrating part was that I explained we had tried Scrum and adapted it for our team's needs. We weren't anti-Scrum, we just found a way to make it work for us. I was then told "[Company] is a Scrum company. We all use Scrum as it is" and was brushed off. Same Scrum leader would yell at the operations team for failing to complete sprints in time when servers fell over, and other nastiness that becomes the priority when you work in a position where you prioritize server health and function over new builds and features. The other Scrum leader we had was pretty great, but, unfortunately, was not the one assigned to my team. Sorry if this borders on ranting. I really enjoyed working for that company, but it was a rough time toward the end of duration there. Apparently I have lingering frustrations, especially since I'm still friendly with many on the ops team. :)
jusuchin 11y ago
> Say what you want about our supposed inability to estimate, but I challenge any team to nail estimates within a 20% margin for a large feature on a large app. Not to be pessimistic but this sounds like stories and tasks needed to be broken out in even finer detail.
- digitalclubb 11y ago
  I think that's a fair assessment. If people can grasp creating small independent deliverables for their projects (of any size) then things become a lot easier to estimate. Monitor velocity and pull less into future sprints if you're still getting it wrong. If there is a piece of functionality that brings unfamiliarity to the delivery team then create a spike ticket to investigate (though use them sparingly). If you break things down small enough, really understand your velocity and have a transparent relationship with your product owner then there should be no need for any stress from anyone.
darkerside 11y ago
Was the author's team just totally lacking a leader who could point out the patterns in underestimating the scope of work. If you are consistently missing your estimates, you adjust. Get to a point where you are consistently under-promising, and over-delivering. Morale problem solved. It's not rocket science. That said, I agree that regular timelines aren't the only way to create a sense of urgency in your team.
- perlgeek 11y ago
  It's not that easy. If a team member gets sick for a week, it can already be impossible to meet the goals of a two-week sprint. It happens (not so often, but it does) that we underestimate the complexity of a task by a factor 5 or so; that alone can also make it impossible to meet the goals. There are just too many things that lead to building pressure when there's no actual need for pressure from a business point of view.
  - darkerside 11y ago
    Estimation is just educated guessing. If you were guessing a non-randomly generated number, and you found you were guessing high every single time, wouldn't you eventually try reducing by orders of magnitude? Team members do get sick, scope tends to sprawl, and life just generally gets in the way; but good estimation includes a buffer. Under-promise and over-deliver, at least until you figure out what you're doing.
tootie 11y ago
I think the value of Scrum is that it provides great visibility into development for stakeholders. They can see the progress of the backlog and know what's being committed to every sprint. It does put some artificial boundaries on work getting done, but I think it strikes a good balance between pure agile and keeping business happy.
arielweisberg 11y ago
It sounds like you got a lot of positive things out of it. Which is great. Also great that you are iterating and not sticking to what the coach gave you. My take on what made many elements of SCRUM work for me follows. 2-3 hour backlog grooming sessions is a warning sign. Of what I couldn't say but maybe it is time to evaluate team size or how meetings are being conducted. Push as much stuff out of meetings as possible. If you have a morale issue due to stuff slipping (and I suspect maybe you didn't capture everything in this post) then it may not be planned sprints that are the issue. Expectations that people have of themselves and of the team are something you are free to set. I think SCRUM tend to end poorly for developers because they are placed on top of dysfunctional systems of expectation that discourage many kinds of failure. I am perfectly happy abusing SCRUM and letting things slip from sprint to sprint sometimes excessively. Fitting things into 2 weeks was a goal to gain the benefits of constrained scope and clearly articulated and designed implementations or requirements, but failure is something I made sure to embrace. Sure we had retrospectives to see what could be learned and what we could do better, but you have to be very careful to make sure it isn't second guessing or moving the goal posts. You shouldn't fault people pretty much ever as part of SCRUM, but definitely don't fault them for slippage. There should be next to no onus on an assignee for a task to prove they did the right thing. IMO That kind of feedback comes best out of band on a very macro scale when there is a pattern of failure for an individual to address AND you must get buy in from the individual that there is improvement to be had. The reason I stress this is that I don't want people to try and avoid things that they might fail at. That pushes people away from important work that needs to be done. I think that planned sprints and retrospectives are the 1-2 punch of SCRUM. By estimating what you should be capable of you are then capable of reasonably identifying WHY you didn't achieve that and trying things until there is improvement or you establish that the estimates are wrong. SCRUM without high functioning retrospectives is missing 50% of the goodness IMO. It's great that you kept regularly scheduled meetings. There is a huge amount of buy in, knowledge sharing, and consensus you get for relatively low cost by having regularly scheduled meetings. With small enough teams you can get it all done with one hour long interrupt per week. Socially it's also good because it discourages backroom deals, planning, and cliques which are toxic. Doubly so if you have remote workers.
- mpdehaan2 11y ago
biehl 11y ago
I've preferred Kanban for a while now. When I started doing work on a git-flow/feature branch basis, the sprints lost their value to me. I've begun to wonder if the sprints were simply an artefact from poor practices in old CVS/SVN workflows (like needing a short, regular stabilizition and release cycle)?
LeicaLatte 11y ago
Waiting for the follow up post on how he's ditching kanban for X next.
- themodelplumber 11y ago
  Wampaku has worked out very well for my team.
kemiller 11y ago
Scrum is supposed to be about regular feedback and sustainable pace, not motivation.
nickpsecurity 11y ago
Waiting for this title: "Ignoring waterfall and agile fads while sticking with Boehm spiral model (1986), good management, minimal meetings/paperwork, regular code reviews, and usage-driven testing. Best decision I ever made." Haven't seen it yet but it's worked for many organizations and projects. For decades. Surely some improvements since then but one has to wonder what the useless-to-critical ratio is in activities of the new things. It still isn't clear to me.
- keithba 11y ago
  +1. I was taught this as a young lad at Intel by a graybeard who'd been developing since the 60s. It made a lot of sense then, and it makes a lot of sense now.
adrianmacneil 11y ago
Would people recommend a team moving directly to Kanban, or is it useful to learn/use Scrum first? What books/resources would people recommend to learn Kanban effectively?
- trhway 11y ago
  >is it useful to learn/use Scrum first? 'Smart people learn from their mistakes. But the real sharp ones learn from the mistakes of others.'
marcosdumay 11y ago
I was curious to understand what exactly software managers were calling by "kanban" now that the name is fashionable. Well, I was not disappointed. The articles talks about everything, except anything marginally related to the meaning of "kanban" in manufacturing.
- sbuk 11y ago
  Can you elaborate?
  - marcosdumay 11y ago
    In physical production (where it comes from), kanban is a lean method for ensuring that you don't spend on producing right now something that is not needed right now. It works by tokens that "pull" the production from other productive unities that are ultimately "pulled" from external (client) demand. The article talks about all kinds of rituals and gains, but never once touches that "pulling" activity that is central to the concept, nor the lean objective.
    - sbuk 11y ago
      Thanks. I'll confess to being a Kanban noob. Do you have any resources that you can share? Looking with Google seems to present more of this sort of article.
      - marcosdumay 11y ago
        Wikipedia has a surprisingly good explanation: https://en.wikipedia.org/wiki/Kanban https://en.wikipedia.org/wiki/Kanban There's a link to Toyota's site at the bottom, as the inventors, they have plenty of authority on it. Wikipedia has also an article about Kanban in software development. As expected, the introduction does not even make sense, but the methodology section contains a form of continuous improvement, what could work. Also, I could not understand how any of the experiences related on the article could come from the Wiki's methodology - it has probably no relation at all with was implemented at the author's place.
BurningFrog 11y ago
I read this article hoping to learn what "kanban" really is. From the text, it seems like it's scrum, but without having a deadline every sprint for what you committed to at the start of it. And... that sounds exactly like the Pivotal school XP I've been doing for 10 years. Words, words, words...
- antod 11y ago
  The commonly understood aspects of Kanban is that it is a pull (team members assign themselves work based on priorities) system that has a 'work in progress' limit - ie the most number of items a team/person can work on at once. If something urgent comes up that needs working on right now, something else will need to go back on hold. Kanban works best when tasks are explicitly prioritised against each other.
shockzzz 11y ago
Sounds like they're about to throw out Kanban in favor of quitting
bsg75 11y ago
Can anyone recommend a good, concise book on Kanban in software - preferably without mingling in Scrum? There are multiple titles that come up on an Amazon search, all with similar review scores.
slavik81 11y ago
This really resonates with me. My experience with scrum was very similar, and I thought Kanban might be a nice answer to the arbitrary deadlines that frustrated me. Never got a chance to try it, though.

173 points by fearenales 11y ago

I love this. We briefly flirted with scrum but now just have a much more Kanban-like system now, too. The only issue I foresee long term is that the sprint mentality of Scrum might recharge people and get them to, well, sprint, at product goals. Kanban, because it is never ending, might start to feel like a slog. There is never a way to have that feeling of "wow, we crushed it and cleared out our list. We are awesome." The list just extends forever. We have put measures in to help with this: primarily just having our engineers say at the beginning of the week what they hope/plan to get done this week (or two). Sometimes that is just noting subtasks in pursuit of a larger feature, but at least it borrows some of what is a very powerful part of Scrum: the social commitment that comes from standing up and saying "this is what I will finish this sprint."

adamjc 11y ago
Our crew use a Kanban approach, and to counter the 'slog' mentality, we have a retrospective every 2 weeks. I find that it really helps air what good we've done, and where we could improve. If we've accomplished a lot it's a great place to reflect and think positively.
- gjmulhol 11y ago
  I really like this idea. We groom our Kanban board, which creates a similar effect, but not so explicitly. In your case or ours, one of the nice things about stepping back is reprioritization, which happens nicely in Scrum but not so much in Kanban. It is easy to define a path and never diverge only to wake up and realize you built an old vision.
regularfry 11y ago
I see it the other way round. We're doing Scrum (ish, I guess) right now, and the see-saw between either ending a sprint with a couple of late-night panic sessions to get everything out of the door, or ending it with most of the team kicking their heels with one pair still going up to the deadline is what feels like the slog. I see Kanban as much smoother: I don't see artificial, self-imposed crunch mode every fortnight as a positive. It's all very well aiming at a social commitment, but the way it works in practice is either a) you under-estimate and have dead time; b) you over-estimate and crunch; or c) you nail it and one sprint runs smoothly into the next. The trap is that c) never happens. I think what makes the difference is that we're continuously delivering, so there's no delivery ceremony between one sprint and the next to make the crunch mode mean something.
- JoeAltmaier 11y ago
  Aligns with my experience. We're always continuously delivering, with madeup goals stuck in to align with arbitrary sprints. The real activity takes as long as it takes. Sprints are a stilted reporting structure, adding drama but little real value.
- cmdkeen 11y ago
  The crunch approach to sprints is the killer. If you know you can't complete all the work in a sprint the answer should not be to bust yourself to try and complete it. Have a conversation with yourselves and the product owner to readdress what you can realistically achieve in the time remaining and then do that. It's a really hard thing to do, we all want to be the hero that saves the sprint. It also encourages you to end up with lots of discrete chunks of work in a sprint so you can complete 80% of your initial commitment and salvage a sense of achievement rather than getting 80% through a few big tasks but none of them actually done. A sprint with 4 developers and 4 tasks each estimated to take 2 weeks will almost never succeed. A sprint with 4 developers and 20 tasks each estimated to take a day or two stands a much better chance of success. Combine that with some metrics around "complexity per developer per available day" and you quickly end up with some charts showing productivity that is hopefully improving which will hopefully improve morale.
  - andrewprock 11y ago
    "hero that saves the sprint" To me, that rhymes with "hero that papers over bad management".
- sandGorgon 11y ago
  in that case, do you use retrospectives at all ? if you dont have a goal post, then how do you retrospect.
- alistairSH 11y ago
  ...ending a sprint with a couple of late-night panic sessions to get everything out of the door... My first reaction is you are not sufficiently grooming your backlog. Stories are left too large, with too many unknowns. If you tend to have a small number of large tasks, this is likely the case. That, or you just aren't very good at estimating. A large number of small tasks would indicate this problem. In the second case, you need to circle back with the PO and discuss which items can push to the next sprint. And make a concerted effort to estimate better during grooming and planning sessions.

_Codemonkeyism 11y ago

The context and mode defines your process: agile, lean or six sigma. Most companies have no clear understanding about their context (should read Simon Wardley [1]) or mode. Very good video from Markus Andrezak explaining the three "modes": https://vimeo.com/146522220 https://vimeo.com/146522220 (Must see) "The biggest mistake companies can make is to define their (one) process, culture, way of work. The work that needs to be done in a sustainable company differs in at least three fundamental ways." [1] Simon Wardley and Markus also explain why bimodal IT does not work

bryanlarsen 11y ago
Any text links? Thanks.
- _Codemonkeyism 11y ago
  Simon Wardley blogs at http://blog.gardeviance.org/ http://blog.gardeviance.org/ One link is http://blog.gardeviance.org/2015/10/agile-vs-lean-vs-six-sigma.html http://blog.gardeviance.org/2015/10/agile-vs-lean-vs-six-sig... (I'm sure his view and his value maps on strategy will be huge in 5 years, although he is relativly unknown today)
  - sandGorgon 11y ago
    thats' a very interesting blog on strategy. Thanks for that - the only problem I see is that the "settlers" analogy has no real life mapping (unlike Pioneers <-> scrum and TownPlanners <-> six sigma).

PaulHoule 11y ago

Remember the triple constraints of cost, scope and time. If you are going to commit to releasing at a certain time you are going to have to let the scope slide. (Sometimes you can add more people on a 2 week basis but the ramp up time makes it usually impractical.)

T-hawk 11y ago
And this is exactly the difference between Scrum and Kanban. Scrum fixes the time periods and allows for adjusting scope, by cutting stories and features. Kanban fixes the scope while allowing the time period to be open-ended. Which methodology is more appropriate depends on which constraint a business wants or needs to optimize for.
- PaulHoule 11y ago
  It is even better to do something hybrid that is tuned to the application. A bad thing about scrum is that it introduces a lot of phony deadlines that have nothing to do with the business; this is like the common practice of the boss setting a short deadline on the hope that they can control the cost (total hours) by controlling calendar time. On the other hand having a release every two weeks means you actually need a release. There are so many projects where a few programmers spend say 1.5 years building a components and hypothetically the application is feature complete, but they are nowhere near running it on a real server or packing it up for the customer with an installer and all that and it takes another 0.5-1 yr to figure out how to make a release. Then there is a stressful process of making a few more releases to fix the inevitable problems, then they go off and work another 2 yrs on the next release and then find they've forgotten how to make a release. The best thing about scrum is that it avoids that. The idea that the phony deadline is fixed is another problem. If you can slip the schedule by 2 or 3 days in scrum to address critical things in the scope there that is no problem but many agilists will fight that. Another failure mode is the project that is hitting the goals for milestones well (estimating things about 10% accurately) and that makes people feel good, but somehow you never get to the last milestone. I came in late and helped finish one of those severely troubled projects where there was a huge amount of blame to go around. Scrum and Kanban concepts were being used by teams involved, but a lot of people on my team including the boss and star programmer would not do what scrum required. My boss would bitch me out for making "rediculous" estimates of 4 hours to do something that involved a 45 minute build process and I wondered how the other people on the team didn't have this and I found I was the only one who was serious about estimating and that the star programmer did not do it at all. In the end we gave up on scrum and got heavy on checklists. We made a checklist with about 300 steps for a release process and it a was a stressful process but we learned how to do it reliably. Also we had a checklist of things to have done before the final release. It was not pretty but we did cross the finish line and get the product in front of customers and they liked it, so I felt I did my part and felt free to move on when it was done.

JoeAltmaier 11y ago

We've used Kanban (or something like it) for 20 years. Long before Kanban existed as a thing. Near the end of a project, we'd draw up the "finishers' list" with numbered items and initials next to each. Daily team review of each remaining item, reassign priority or responsibility as needed.

seanwilson 11y ago

> The rituals, mainly the standups and grooming sessions, were fantastic. Standups are a great way to keep everyone aligned on the work. Can anyone elaborate why they find standups useful? The planning board should already communicate what's being done, what's been done and why people are blocked. I only find them helpful if some people in the team generally don't communicate well what they're up to (e.g. during daily work, over lunch). Otherwise I find most people zone out during the standup and it just interrupts work.

danmaz74 11y ago
> I find most people zone out during the standup Out of curiosity, how long do your standups last? How big is the team?
- alistairSH 11y ago
  I'm a project manager/scrum master, with a team that varies from 6 to 12 (roughly half the team is semi-permanently on-loan to other related projects/teams). My daily stand-up is usually 5-10 minutes. About 5 minutes of the standard "what I did, what I plan to do, and what's in my way". And 0-5 minutes of resolving problems (figuring out if I need to escalate, or if another team needs to be involved, etc). Anything longer than that, and we schedule follow-up meetings with a more correct set of attendees.
- smileysteve 11y ago
  15 (goal) minutes with a 10 person team. Everybody didn't zone out every day, but most did, most of the time.
  - nickpsecurity 11y ago
    Exactly. It's a waste of time. Best to give a direct message or face-to-face telling the person what they need to know. Or not say anything if nothing is needed. At most, I'd say weekly meetings that were a mix of tracking project status and fun just for team-building purposes. Keeping people connected.
  - 11y ago

daigoba66 11y ago

> Perhaps Kanban is better suited towards long-lived product development than Scrum. This is the key take-away. And in my experience this is absolutely true. On the other hand, working now as a consultant where I am frequently on shorter-term projects with a definitive "end" for the engagement, the time-boxed sprint approach (or "Scrum") actually seems to work well. Scrum might work for individual "projects". It does not scale or coalesce well with long-term development and maintenance. > Perhaps there is indeed a natural progression of engineering teams adopting Scrum, then moving to Kanban. This also mirrors my experience.

dvanduzer 11y ago
Kanban was invented at Toyota in the '40s and '50s: https://en.wikipedia.org/wiki/Kanban https://en.wikipedia.org/wiki/Kanban Depending on the scale you're operating at, it's easy to see this as a waterfall methodology. There are lots of different words to describe organizing work, but what's important is that the methodology remains consistent enough that the team understands it. I think of time-boxed sprints as great for training. Humans aren't going to get better at estimating how long it takes to complete complex engineering tasks. But teams that work together over a long enough period of time can plan ahead better. (For example, time-boxed sprints would suggest that everyone has to take vacations at the same time for Scrum to be effective.) There are plenty of ways to deal with the fact that humans are asynchronous. I particularly liked this author's focus on team morale as a major factor.
alkonaut 11y ago
My experience too. A short deadline (few months to a year) and a green new codebase is a good place for scrum. A medium/large project (200 man years in the code over 10 years say), then it's a lot harder. A required refactoring in the codebase that would take 200h is a common discovery in issues estimated at a few h.
kaizendad 11y ago
I completely agree with this. In shorthand, having been Product Manager for a number of teams at a variety of companies in several industries, I've found that Scrum is better for teams developing mostly new features, with relatively little maintenance; and Kanban better for teams focused primarily on maintenance, with fewer large features. The rationale is really simple: for new feature launches, reporting and tracking vs. schedule is key; for maintenance, throughout is key. That said, regularly missing predicted story points by more than about 10% is not the sign of a healthy team. Being bedeviled by routine bug fixes is not the sign of effective management. Both are routine issues that most highly-effective teams, whether Scurm or Kanban, deal with well.

vincentkriek 11y ago

I really like KanBan and think it's a better fit for a lot of teams than SCRUM is. SCRUM works great for teams which have a stable backlog of work and an incidental problem that might pop up. If you can't keep a backlog stable for three weeks, you shouldn't do scrum. KanBan allows you to pick and choose practices from scrum that do add value, and ignore the ones you are just doing to follow the book. I worked in a team for 2 years that tried to do scrum because it's new thing that everyone should be doing and I feel it added nothing of value.

cmdkeen 11y ago
If you can't keep a backlog stable for a few weeks then you aren't doing project work you're on support or firefighting. Scrum is all about IT project work, Kanban is a more general "efficiently get a pile of tasks done" process which can apply to small IT tasks or building a car.
- peterbell_nyc 11y ago
  Depends where you are in your product lifecycle. Pre-product market fit, it's often a bad idea to build and keep a stable backlog a few weeks in length.

cmdkeen 11y ago

As someone in similar circumstances a couple of things jump out which trouble me: Project Managers - That this role is mentioned, but not that of Scrum Master, is odd but unsurprising. PMs aren't mentioned in Scrum at all and often the way they want to do things clashes with the Scrum way of doing things. In the given example of the PM moaning about estimation Scrum at least forces that realisation quickly, something which Kanban lacks. There may well have been a Scrum Master, one of the things I've experienced them doing is guiding my team down from 1 month sprints through 2 week ones down to a single week. "It's really hard to plan for 2 weeks work" is a classic moment for the Scrum Master to say "what about..." "We tossed out the retrospectives" - Despite acknowledging them as a good thing? For me retrospectives are the most powerful part of Scrum. Stopping retrospectives might save you a few hours and some awkward conversations but is likely to hamper your continued development. Scrum is really good about moving a team to the "conscious incompetent" phase - i.e. you are forced to be aware you are bad at something and really need to work on it. Retrospectives are the way to improve and grow. "We kept our deadlines" - That you had deadlines (again the sign of a PM somewhere), and view them as important enough to mention again is interesting. It hints at quality not being the most import factor, which is one of the keys to doing Scrum well. For me moving to Kanban was a fix for a Scrum team that wasn't working well. I've worked on a good Scrum team, that took a while to get going, but got there by being able to be open and honest about poor morale and then dealing with it. The new team didn't get there, we moved to Kanban and while everyone is happier our productivity is much, much lower. I do feel there is a place for switching to Kanban - when the scope of the project has moved into "we know how to do this" space, often close to a major release (if you do infrequent releases) where 3rd party involvement plays havoc with planning. If you're dealing with points high on the "the business don't know what they want" or "we don't know how to do this" chart then, for me, Scrum is still king. If you're high on both axes then you might want to switch projects / companies...

eitally 11y ago
One of the biggest problems with Scrum (as mentioned in other comments) is that in a lot of large companies you have strong top-down enforcement of budgets, deadlines & expectations, which usually means the PMO is in control. This means you end up with a project manager as an awkward intermediary between the stakeholders & the product team. In almost every case, the product owner should be the project manager, but this very rarely happens in enterprise, and Scrum fails.

rabbitheart 11y ago

The team I was previously on tried to use Scrum and seemed to naturally fall into a similar model to Kanban; we got rid of what helped, and stopped doing what didn't. It was an amazing relief, especially since Scrum sprints and the numbers just weren't working. Sadly, our Scrumlessness was found out and it was implemented again shortly before I left. Morale was dropping steadily on the team already (unrelated reasons), reimplementing the parts we already knew didn't work was a bummer, and the Scrum leader talked down to me when I tried to advocate for the team.

tablet 11y ago
It is really stupid to NOT allow any team choose its own process. Your scrum leader is not a wise person, to put it lightly.
- rabbitheart 11y ago
  I think the most frustrating part was that I explained we had tried Scrum and adapted it for our team's needs. We weren't anti-Scrum, we just found a way to make it work for us. I was then told "[Company] is a Scrum company. We all use Scrum as it is" and was brushed off. Same Scrum leader would yell at the operations team for failing to complete sprints in time when servers fell over, and other nastiness that becomes the priority when you work in a position where you prioritize server health and function over new builds and features. The other Scrum leader we had was pretty great, but, unfortunately, was not the one assigned to my team. Sorry if this borders on ranting. I really enjoyed working for that company, but it was a rough time toward the end of duration there. Apparently I have lingering frustrations, especially since I'm still friendly with many on the ops team. :)

jusuchin 11y ago

> Say what you want about our supposed inability to estimate, but I challenge any team to nail estimates within a 20% margin for a large feature on a large app. Not to be pessimistic but this sounds like stories and tasks needed to be broken out in even finer detail.

digitalclubb 11y ago
I think that's a fair assessment. If people can grasp creating small independent deliverables for their projects (of any size) then things become a lot easier to estimate. Monitor velocity and pull less into future sprints if you're still getting it wrong. If there is a piece of functionality that brings unfamiliarity to the delivery team then create a spike ticket to investigate (though use them sparingly). If you break things down small enough, really understand your velocity and have a transparent relationship with your product owner then there should be no need for any stress from anyone.

darkerside 11y ago

Was the author's team just totally lacking a leader who could point out the patterns in underestimating the scope of work. If you are consistently missing your estimates, you adjust. Get to a point where you are consistently under-promising, and over-delivering. Morale problem solved. It's not rocket science. That said, I agree that regular timelines aren't the only way to create a sense of urgency in your team.

perlgeek 11y ago
It's not that easy. If a team member gets sick for a week, it can already be impossible to meet the goals of a two-week sprint. It happens (not so often, but it does) that we underestimate the complexity of a task by a factor 5 or so; that alone can also make it impossible to meet the goals. There are just too many things that lead to building pressure when there's no actual need for pressure from a business point of view.
- darkerside 11y ago
  Estimation is just educated guessing. If you were guessing a non-randomly generated number, and you found you were guessing high every single time, wouldn't you eventually try reducing by orders of magnitude? Team members do get sick, scope tends to sprawl, and life just generally gets in the way; but good estimation includes a buffer. Under-promise and over-deliver, at least until you figure out what you're doing.

tootie 11y ago

I think the value of Scrum is that it provides great visibility into development for stakeholders. They can see the progress of the backlog and know what's being committed to every sprint. It does put some artificial boundaries on work getting done, but I think it strikes a good balance between pure agile and keeping business happy.

arielweisberg 11y ago

It sounds like you got a lot of positive things out of it. Which is great. Also great that you are iterating and not sticking to what the coach gave you. My take on what made many elements of SCRUM work for me follows. 2-3 hour backlog grooming sessions is a warning sign. Of what I couldn't say but maybe it is time to evaluate team size or how meetings are being conducted. Push as much stuff out of meetings as possible. If you have a morale issue due to stuff slipping (and I suspect maybe you didn't capture everything in this post) then it may not be planned sprints that are the issue. Expectations that people have of themselves and of the team are something you are free to set. I think SCRUM tend to end poorly for developers because they are placed on top of dysfunctional systems of expectation that discourage many kinds of failure. I am perfectly happy abusing SCRUM and letting things slip from sprint to sprint sometimes excessively. Fitting things into 2 weeks was a goal to gain the benefits of constrained scope and clearly articulated and designed implementations or requirements, but failure is something I made sure to embrace. Sure we had retrospectives to see what could be learned and what we could do better, but you have to be very careful to make sure it isn't second guessing or moving the goal posts. You shouldn't fault people pretty much ever as part of SCRUM, but definitely don't fault them for slippage. There should be next to no onus on an assignee for a task to prove they did the right thing. IMO That kind of feedback comes best out of band on a very macro scale when there is a pattern of failure for an individual to address AND you must get buy in from the individual that there is improvement to be had. The reason I stress this is that I don't want people to try and avoid things that they might fail at. That pushes people away from important work that needs to be done. I think that planned sprints and retrospectives are the 1-2 punch of SCRUM. By estimating what you should be capable of you are then capable of reasonably identifying WHY you didn't achieve that and trying things until there is improvement or you establish that the estimates are wrong. SCRUM without high functioning retrospectives is missing 50% of the goodness IMO. It's great that you kept regularly scheduled meetings. There is a huge amount of buy in, knowledge sharing, and consensus you get for relatively low cost by having regularly scheduled meetings. With small enough teams you can get it all done with one hour long interrupt per week. Socially it's also good because it discourages backroom deals, planning, and cliques which are toxic. Doubly so if you have remote workers.

mpdehaan2 11y ago

biehl 11y ago

I've preferred Kanban for a while now. When I started doing work on a git-flow/feature branch basis, the sprints lost their value to me. I've begun to wonder if the sprints were simply an artefact from poor practices in old CVS/SVN workflows (like needing a short, regular stabilizition and release cycle)?

LeicaLatte 11y ago

Waiting for the follow up post on how he's ditching kanban for X next.

themodelplumber 11y ago
Wampaku has worked out very well for my team.

kemiller 11y ago

Scrum is supposed to be about regular feedback and sustainable pace, not motivation.

nickpsecurity 11y ago

Waiting for this title: "Ignoring waterfall and agile fads while sticking with Boehm spiral model (1986), good management, minimal meetings/paperwork, regular code reviews, and usage-driven testing. Best decision I ever made." Haven't seen it yet but it's worked for many organizations and projects. For decades. Surely some improvements since then but one has to wonder what the useless-to-critical ratio is in activities of the new things. It still isn't clear to me.

keithba 11y ago
+1. I was taught this as a young lad at Intel by a graybeard who'd been developing since the 60s. It made a lot of sense then, and it makes a lot of sense now.

adrianmacneil 11y ago

Would people recommend a team moving directly to Kanban, or is it useful to learn/use Scrum first? What books/resources would people recommend to learn Kanban effectively?

trhway 11y ago
>is it useful to learn/use Scrum first? 'Smart people learn from their mistakes. But the real sharp ones learn from the mistakes of others.'

marcosdumay 11y ago

I was curious to understand what exactly software managers were calling by "kanban" now that the name is fashionable. Well, I was not disappointed. The articles talks about everything, except anything marginally related to the meaning of "kanban" in manufacturing.

sbuk 11y ago
Can you elaborate?
- marcosdumay 11y ago
  In physical production (where it comes from), kanban is a lean method for ensuring that you don't spend on producing right now something that is not needed right now. It works by tokens that "pull" the production from other productive unities that are ultimately "pulled" from external (client) demand. The article talks about all kinds of rituals and gains, but never once touches that "pulling" activity that is central to the concept, nor the lean objective.
  - sbuk 11y ago
    Thanks. I'll confess to being a Kanban noob. Do you have any resources that you can share? Looking with Google seems to present more of this sort of article.
    - marcosdumay 11y ago
      Wikipedia has a surprisingly good explanation: https://en.wikipedia.org/wiki/Kanban https://en.wikipedia.org/wiki/Kanban There's a link to Toyota's site at the bottom, as the inventors, they have plenty of authority on it. Wikipedia has also an article about Kanban in software development. As expected, the introduction does not even make sense, but the methodology section contains a form of continuous improvement, what could work. Also, I could not understand how any of the experiences related on the article could come from the Wiki's methodology - it has probably no relation at all with was implemented at the author's place.

BurningFrog 11y ago

I read this article hoping to learn what "kanban" really is. From the text, it seems like it's scrum, but without having a deadline every sprint for what you committed to at the start of it. And... that sounds exactly like the Pivotal school XP I've been doing for 10 years. Words, words, words...

antod 11y ago
The commonly understood aspects of Kanban is that it is a pull (team members assign themselves work based on priorities) system that has a 'work in progress' limit - ie the most number of items a team/person can work on at once. If something urgent comes up that needs working on right now, something else will need to go back on hold. Kanban works best when tasks are explicitly prioritised against each other.

shockzzz 11y ago

Sounds like they're about to throw out Kanban in favor of quitting

bsg75 11y ago

Can anyone recommend a good, concise book on Kanban in software - preferably without mingling in Scrum? There are multiple titles that come up on an Amazon search, all with similar review scores.

slavik81 11y ago

This really resonates with me. My experience with scrum was very similar, and I thought Kanban might be a nice answer to the arbitrary deadlines that frustrated me. Never got a chance to try it, though.