Timeline for How to use trunk based development when using Scrum
Current License: CC BY-SA 4.0
14 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jan 23, 2024 at 21:03 | comment | added | Ewan | PS im not saying you are paid, but the people on your links are. | |
| Jan 23, 2024 at 21:02 | history | edited | Ewan | CC BY-SA 4.0 |
added 1538 characters in body
|
| Jan 23, 2024 at 20:40 | comment | added | Ewan | I think you need to re-read those links. If I had to choose a single thing in the scrum guide to support my argument (ignoring the huge body of other descriptions and diagrams that litter the internet) it would be "If a Product Backlog item does not meet the Definition of Done, it cannot be released or even presented at the Sprint Review. Instead, it returns to the Product Backlog for future consideration." I don't see how you can square that with continuously deploying every small change and feature flagging them | |
| Jan 23, 2024 at 20:29 | comment | added | Thomas Owens♦ | I'm not paid to implement Scrum and I'm telling you that you are absolutely wrong. I'm paid to help teams find and implement the best processes and methods, whether that's Scrum or something else. I've pointed to several things from the past ~5 years that support my statements. You can't link to one thing from a reputable source that supports yours. | |
| Jan 23, 2024 at 20:27 | comment | added | Ewan | Jeeze the second link even makes the distinction between "mini-increment" and "releasable increment". Personally I am somewhat skeptical when Scrum professionals with a vested interest in people paying them to implement scrum tell me that scum is conpatible with kanban and TBD and CD and anythign else under the sun | |
| Jan 23, 2024 at 20:26 | comment | added | Thomas Owens♦ | At the end of a Sprint, you have something that should be releasable/deployable. Maybe it was made on day 3 and deployed. Maybe you released deployed 10 things. The minimum expectation is to product at least one deliverable Increment every Sprint. It could be 1, it could be 1000. It could be deployed or maybe you don't deploy at all and just demonstrate. You can build avionics software using Scrum, but you aren't deploying to production - in-service aircraft - every month. | |
| Jan 23, 2024 at 20:21 | comment | added | Ewan | Your quotes directly contradict your view : "The PO should therefore release at the end of every sprint". Just because its not forbidden to have an early deployment IF "..the PO are willing to support that.." doesnt mean doing it for every commit is encourages or even suggested! | |
| Jan 23, 2024 at 20:17 | comment | added | Thomas Owens♦ | There are more things to read: this forum post, also including a post by me, this blog post, or maybe this forum post. If you don't believe me when I say that you can deploy multiple times in a Sprint, there are PSTs - people who train Scrum certification classes - that say the exact same thing. I could keep going, too, if you want even more. | |
| Jan 23, 2024 at 20:13 | comment | added | Thomas Owens♦ | What does a Sprint Goal or the Sprint Review have to do with continuous deployment? I don't think you understand what the point of the Sprint Goal or Sprint Review are. The Sprint Review is not a time to get "deployment sign-off". It's an event that happens at a consistent time and a regular cadence to get the team and key stakeholders together to align. I can tell that you don't understand Scrum and this propagates incorrect information. I'm not a huge fan of Scrum, but at least I understand its intent, purposes, and the "rules of the game" and don't misrepresent the framework. | |
| Jan 23, 2024 at 20:10 | comment | added | Ewan | The scrum guide states that sprints have goals, meetings at the end to present and discuss work done and can be cancelled. Of course not all work in a sprint is writing code, there's no reason not to complete something that can be completed. But if you continuously deploy everything and then say "the scrum guide doesn't say we can't" well, I think you are missing the point | |
| Jan 23, 2024 at 20:01 | comment | added | Thomas Owens♦ | There is nothing in Scrum that says anything like this. You are not limited to deployments at the end of the Sprint. Like I said, Continuous Delivery and Continuous Deployment are consistent with Scrum. There's a discussion thread on the Scrum.org Forums, including a detailed post by me, explaining more. The Sprint is a feedback loop, not a delivery loop. It guarantees a maximum length between feedback with stakeholders. More frequent delivery and feedback is allowed. | |
| Jan 23, 2024 at 19:55 | comment | added | Ewan | CD in scrum takes place on merge to master, which takes place at the end of a sprint. If you throw out the sprint as the core unit of work and you are still saying you are doing scrum, well then everything is the same as everything else and you are doing TrunkKanScumBan | |
| Jan 23, 2024 at 19:48 | comment | added | Thomas Owens♦ | Your first paragraph is incorrect. The Scrum Guide states that the "Sprint Review should never be considered a gate to releasing value". Continuous Deployment is not at odds with anything in the Scrum framework. | |
| Jan 23, 2024 at 19:27 | history | answered | Ewan | CC BY-SA 4.0 |