7 ms·

I've always been quite fiercely against Scrum as a development process, and I still am in the context of constantly evolving cloud based services, but I've rece

I've always been quite fiercely against Scrum as a development process, and I still am in the context of constantly evolving cloud based services, but I've recently seen it being done to great effect for mobile app development. I think this is similar to Pete Hodgson's clarification[1] that gitflow (which he originally documented) isn't suitable in that sort of environment. If you've got a constantly deployed set of artifacts it doesn't make sense to plan in two week blocks, and then freeze a release. In the world of software which has actual discrete releases then you either have a massive gap between releases as you get everything just right, or you say "every two weeks we'll release what's ready", and for that approach Scrum works really well. When you're working on cloud hosted services the typical approach is more of releasing things as they're ready, possibly sitting behind feature flags or partial rollouts, and for that Kanban has worked much better in my experience. It gives more flexibility around changing priorities, and space for the inevitable production incidents and technical support that can suck up a week of time out of nowhere. [1] https://twitter.com/ph1/status/1260702766118232065?s=21 https://twitter.com/ph1/status/1260702766118232065?s=21

bryanrasmussen 6y ago
I agree scrum is too heavy for a release every two weeks thing, what it's good for in my book is: You have a very big project to make and you know exactly what it needs to contain, examples: 1. you have an application that users already use but you need to move off a platform by a particular time or you are screwed. So you know exactly what you need to replicate in the new platform (your current functionality) and you have a set deadline to do it in. For me it was the company got sold and we needed to be off of Thomson Reuters platform within a year or pay over $100,000 a month to use it. 2. You have entered into a legally binding contract and you know what the application is going to need to contain and what you can drop without getting sued or not getting paid. If it is your own application you can always stretch timelines out a bit to get to where you need to be, or you can decide to drop features to get to where you want to be. But once there are other people in there you might not be able to stretch timelines of drop features, and then you need something that gives you a way of alerting you beforehand if you're going off the rails.
- Scarblac 6y ago
  If you know exactly what needs to be done, why do all the extra work to be able to divide it into sprints? The whole point of sprints is that requirements are allowed to change, just not more frequently than there are sprints.
  - bryanrasmussen 6y ago
    you have it in sprints because you have a deadline so you can see how well you are progressing towards your goal by seeing how many issues are fixed in their sprint, going over to next sprint etc. It's not a lot of extra work to divide it into sprints, especially as you have people whose tasks are to divide things into sprints and keep track of things.
UK-Al05 6y ago
Nothing in scrum says you release every two weeks. Most modern scrum implementations, you release every story when you're done. The sprint is just a concept for planning what stories you're going to do in those 2 weeks, and retro. Personally I think plans and information can change in 2 weeks, so I prefer kanban. But at this point here isn't much between them.

bryanrasmussen 6y ago

I agree scrum is too heavy for a release every two weeks thing, what it's good for in my book is: You have a very big project to make and you know exactly what it needs to contain, examples: 1. you have an application that users already use but you need to move off a platform by a particular time or you are screwed. So you know exactly what you need to replicate in the new platform (your current functionality) and you have a set deadline to do it in. For me it was the company got sold and we needed to be off of Thomson Reuters platform within a year or pay over $100,000 a month to use it. 2. You have entered into a legally binding contract and you know what the application is going to need to contain and what you can drop without getting sued or not getting paid. If it is your own application you can always stretch timelines out a bit to get to where you need to be, or you can decide to drop features to get to where you want to be. But once there are other people in there you might not be able to stretch timelines of drop features, and then you need something that gives you a way of alerting you beforehand if you're going off the rails.

Scarblac 6y ago
If you know exactly what needs to be done, why do all the extra work to be able to divide it into sprints? The whole point of sprints is that requirements are allowed to change, just not more frequently than there are sprints.
- bryanrasmussen 6y ago
  you have it in sprints because you have a deadline so you can see how well you are progressing towards your goal by seeing how many issues are fixed in their sprint, going over to next sprint etc. It's not a lot of extra work to divide it into sprints, especially as you have people whose tasks are to divide things into sprints and keep track of things.

UK-Al05 6y ago

Nothing in scrum says you release every two weeks. Most modern scrum implementations, you release every story when you're done. The sprint is just a concept for planning what stories you're going to do in those 2 weeks, and retro. Personally I think plans and information can change in 2 weeks, so I prefer kanban. But at this point here isn't much between them.