I started reading this post with the expectation that the author would have an opinion about what else we could look into as inspiration for Scrum.
But got disappointed midway through because there's no opinion on what better other than "not-scrum".
I didn't read any consideration of real alternatives, like Kanban, or XP, or FDD or anything else.
The only mention to ShapeUp (the 37signals process which is basically a "we just like 6 weeks better"+ small changes when compared to Scrum) is quite brief and does not show how the author thinks ShapeUp would improve the situation.
Then there's the "less meeting" passing comment, but no suggestion on what is the right level or number of meetings.
I was very disappointed by the end, as I expected to have an opinionated view on Agile software development, but left the article with a sense of lack of resolution.
I would encourage the author to publish his ideas about the solution. We can have a chat on the Scrum Master Toolbox Podcast or at the Global Agile Summit.
We must reassess our ways of working, but let's design experiments, and inspire others to try them. We need more.
Indeed, I believe the future does not lie in other processes, but in less process overall. Given the right amount of skill and trust, a small and empowered team can achieve great things. They can pick from whatever process tools they deem necessary, but in general they will communicate closely with each other.
I'm looking forward to your post, especially because of one the questions not directly addressed: how do we scale software development to larger organizations (teams of teams) without losing the flexibility Agile promises?
Not just one team anymore. Software has gone massive in scale over the last 20 years....
To be fair, though, Benedikt *did* mention Kanban. Personally, I tend to favor starting with the structure of a "Scrum-like" environment to put a few guardrails in place (think "just enough Scrum"), and then shift toward Kanban (which I strongly believe in) as team matures and responsibility develops. Anyone operating in a truly CI fashion is at least conceptually doing Kanban. I don't mean any of the strict modern "Kanban products" or processes, I mean the root concept, Toyota’s Lean manufacturing Kanban and its focus on eliminating waste ("muda"). That, + the Manifesto, seems a solid foundation (https://agilemanifesto.org).
Scrum has always been too rigid below a certain company size and structure. I have never seen a startup doing Scrum properly, as they have to pivot feature once or twice a week. The same applies to scale-ups as uncertainty is the new normal.
I ditched Scrum for a mix of Scrum and Kanban more than a decade ago. I wanted to add some visibility to an extremely agile, event driven methodology.
I started reading this post with the expectation that the author would have an opinion about what else we could look into as inspiration for Scrum.
But got disappointed midway through because there's no opinion on what better other than "not-scrum".
I didn't read any consideration of real alternatives, like Kanban, or XP, or FDD or anything else.
The only mention to ShapeUp (the 37signals process which is basically a "we just like 6 weeks better"+ small changes when compared to Scrum) is quite brief and does not show how the author thinks ShapeUp would improve the situation.
Then there's the "less meeting" passing comment, but no suggestion on what is the right level or number of meetings.
I was very disappointed by the end, as I expected to have an opinionated view on Agile software development, but left the article with a sense of lack of resolution.
I would encourage the author to publish his ideas about the solution. We can have a chat on the Scrum Master Toolbox Podcast or at the Global Agile Summit.
We must reassess our ways of working, but let's design experiments, and inspire others to try them. We need more.
Thank you very much for your elaborate comment.
Indeed, I believe the future does not lie in other processes, but in less process overall. Given the right amount of skill and trust, a small and empowered team can achieve great things. They can pick from whatever process tools they deem necessary, but in general they will communicate closely with each other.
I might pick up your ideas in a future post!
I'm looking forward to your post, especially because of one the questions not directly addressed: how do we scale software development to larger organizations (teams of teams) without losing the flexibility Agile promises?
Not just one team anymore. Software has gone massive in scale over the last 20 years....
To be fair, though, Benedikt *did* mention Kanban. Personally, I tend to favor starting with the structure of a "Scrum-like" environment to put a few guardrails in place (think "just enough Scrum"), and then shift toward Kanban (which I strongly believe in) as team matures and responsibility develops. Anyone operating in a truly CI fashion is at least conceptually doing Kanban. I don't mean any of the strict modern "Kanban products" or processes, I mean the root concept, Toyota’s Lean manufacturing Kanban and its focus on eliminating waste ("muda"). That, + the Manifesto, seems a solid foundation (https://agilemanifesto.org).
I tend to do the opposite: https://www.leadinginproduct.com/p/scrum-or-kanban-which-one-to-use
But in fact, my choice is not about team size, but about product maturity. The newer the product, the more flexibility is needed -> Kanban.
Scrum is a great training wheels framework. It helps you move on from waterfall and adapt to iterative development.
That is certainly true. If you come from a waterfall process, any kind of agility in the sense of learning and adapting is better.
Scrum has always been too rigid below a certain company size and structure. I have never seen a startup doing Scrum properly, as they have to pivot feature once or twice a week. The same applies to scale-ups as uncertainty is the new normal.
I ditched Scrum for a mix of Scrum and Kanban more than a decade ago. I wanted to add some visibility to an extremely agile, event driven methodology.
Immutability doesn’t fit well with uncertainty.
True!
Does anyone have the same feeling than me that, when a dev team reaches CI/CD, scrum is not as useful as it was in the past?
Right! This is the gist of the post, even though it is not only about CI/CD.
Are you saying that after all this years Kanban will become sexy?
Ok, let’s do this! lol I am ready for the mainstream.
Indeed! An Shape Up! :-)