The Two Things You Should Know About Scrum
Being opinionated on Scrum, I have a lot of teams ask me to stop by and help tune their Scrum process. I join the team for their various scrum rituals and this is almost always the feedback I offer:
Scrum is not about doing work in 2-week intervals. It is not about meeting every morning to hear what everyone did yesterday. Nothing about these rituals imbues any magic that makes a team any more effective.
Scrum is about mitigating risks-- the primary one being that developers will go off into a room for 6-months and build something nobody wanted.
The first thing you should know about Scrum is that it is a framework to rapidly experiment. To do this, you need to produce experiments rapidly'ideally every sprint. Technically, this is called an increment, but it helps to think of it as an experiment because what you are really doing is finding out how to deliver business value by experimenting, inspecting, and adapting frequently.
The second thing you should know about Scrum is that a singular Sprint Goal is the glue that brings everything together. Paradoxically, this is the thing most frequently missing from Scrum teams. Your team should decide on one Sprint Goal and make your daily rituals center on discussing progress towards that one Sprint Goal. When the team starts defining this Sprint Goal and making it their center of gravity, everything will suddenly make more sense and the team will feel a unifying purpose. Do not simply make your Sprint Goal a bullet-point list of every work item brought into the sprint because then you do not know what to shed if things get rough. A Sprint Goals says 'If we do anything this Sprint, it will be this.' Change your morning Scrum to be about the Sprint Goal.
In closing, I always highlight what seems to be a little known fact that everything you need to know about Scrum is contained in a terse, free 14-page document. If Scrum is your team's operating system, then it is mandatory that every person participating on the team read the Scrum Guide. Read it and implement it, with no modifications, for 1 month. After the 1-month trial period, you can begin making small modifications to suit your team but beware that you run the risk of negating the value of the framework. The entire benefit of adopting a well-known methodology is that you are adopting the lessons-learned of a million teams.