The author had really bad experiences. SCRUM is super agile when done right. Change can be introduced during sprint transitions (reviews, retrospectives and pla

The author had really bad experiences. SCRUM is super agile when done right. Change can be introduced during sprint transitions (reviews, retrospectives and planning) - never in the middle of a sprint. Doing so will kill moral and break the rhythm of the dev team. SCRUM is meant to be owned by the developers - not management. Shame on companies that hijack and impose such process. SCRUM gives dev teams rhythm with sprints. Allows them to deliver mini releases of functional software in 2-week increments (could be 1 to 4 weeks too - lenght should be decided during planning). The goal of a sprint is to be decided by the developer and doesn't have to be about the software. Can be about learning, improving as a team or helping team members to grow. Here are a few examples I've seen: - Measure 5 metrics in Kibana - Marie-Pier leads sprint review demo - Try self-merging PR's and measure the results - No more loose ends Of course, in parallel the team builds and delivers an increment of functional software. The planning, review and retro rituals are paramount. SCRUM can only work well if those are well planned and executed. The retrospective is particularly important to allow the team to improve themselves. Its an opportunity to change their own process (i.e. change the definition of done). Contrary to wide belief, story points are not part of SCRUM. Its a mechanism that can be used to gauge the size of work - it should be up to the dev team to decide whether to use them or not. Again dev teams should own that process - should not be imposed by management. These lessons I've learned in the past two years thanks to an awesome SCRUM evangelist we've hired. I'm proud to say its changed our lives for the better.