Bachelor Thesis Scrum

The Scrum Guide is the essential reference. By referring to that document, ask yourself whether or not a "maintenance phase" makes sense in Scrum. How would the "maintenance" work be identified and planned? What are the implications for events, roles, and artefacts? Would the way of working be fundamentally different?

Without going into too much details, I have led multiple teams supporting a brand new live system in the past.

We started off with weekly sprints however moved to a Scrumban model due to the need to allow for newly identified critical issues being brought in asap thus changing the goal and rendering sprint inert (had originally thought about reducing sprint even smaller however went for a mixed approach instead).

We would have daily scrum, retros and review for fixes produced per week cycle however the backlog was worked through dynamically.

Inspecting and adapting was key to finding a process that worked well.

I think Ian's answer (as usual) is very good and thought provoking as the need for the situation I was working in was from teams not properly keeping to a good level of quality within the sprint and being more focused on quantity over quality leading to major issues being identified in production.

Really, working across multiple sites, it is something seen quite alot where some true values haven't been adopted by the organisations and the desire to push to unrealistic timescales with a none dynamic scope has led to a decrease in quality, although the teams are doing the motions they have not adopted the principles (I like to refer to this as zombie scrum).

Thank you. For your replies.