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

It's important for everyone on the team to know what others are doing in order to share knowledge. If people are zoning out, you're not getting that benefit.

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.

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...

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.