> The rituals, mainly the standups and grooming sessions, were fantastic. Standups are a great way to keep everyone aligned on the work.<p>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.
> Perhaps Kanban is better suited towards long-lived product development than Scrum.<p>This is the key take-away. And in my experience this is absolutely true.<p>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.<p>Scrum might work for individual "projects". It does not scale or coalesce well with long-term development and maintenance.<p>> Perhaps there is indeed a natural progression of engineering teams adopting Scrum, then moving to Kanban.<p>This also mirrors my experience.
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.<p>That said, I agree that regular timelines aren't the only way to create a sense of urgency in your team.
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."
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."<p>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.
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.<p>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.
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.<p>Very good video from Markus Andrezak explaining the three "modes":<p><a href="https://vimeo.com/146522220" rel="nofollow">https://vimeo.com/146522220</a> (Must see)<p>"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."<p>[1] Simon Wardley and Markus also explain why bimodal IT does not work
As someone in similar circumstances a couple of things jump out which trouble me:<p>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..."<p>"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.<p>"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.<p>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...
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.<p>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.
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.
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.)
> 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.<p>Not to be pessimistic but this sounds like stories and tasks needed to be broken out in even finer detail.
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.
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.<p>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.<p>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.<p>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.<p>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.<p>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.<p>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.
I've preferred Kanban for a while now.<p>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)?
I read this article hoping to learn what "kanban" really is.<p>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.<p>And... that sounds exactly like the Pivotal school XP I've been doing for 10 years.<p>Words, words, words...
Can anyone recommend a good, concise book on Kanban in software - preferably without mingling in Scrum?<p>There are multiple titles that come up on an Amazon search, all with similar review scores.
Would people recommend a team moving directly to Kanban, or is it useful to learn/use Scrum first?<p>What books/resources would people recommend to learn Kanban effectively?
I was curious to understand what exactly software managers were calling by "kanban" now that the name is fashionable.<p>Well, I was not disappointed. The articles talks about everything, except anything marginally related to the meaning of "kanban" in manufacturing.
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.