On November the 7th, Scrum co-authors, Ken Schwaber and Jeff Sutherland invited the world to the Scrum Guide update where they presented Scrum history and the changes applied with this revision.
7 of us from Gdansk office gathered in the training room to watch the webinar live. Thank you all for coming, we added to list of 7000 people from 72 countries that participated in the event.
I would like to propose my view on the Scrum Guide changes and what they mean for all people using Scrum.

 

Scrum is not only for software

Scrum was used outside of software for quite a while already.
The word itself originates from 1984 article „New New Development Game” that described similar patterns for producing cars, photocopiers, cameras, etc. Even Ken Schwaber suggested using it to introduce Scrum to organisation and corporations in his „The Enterprise and Scrum” book from 2007. So the concept is around for quite a while.
Recently Alicja Łapa, Bogdan Baraszkiewicz, Krzysztof Rozestwiński and myself have taught Scrum to members of WebOps Academy, developers, testers, members of recruitment team, office administration as well as event and media associates. It can and should be used whenever you work on complex product. My son’s preschool (http://www.iwrd.pl) is using Scrum – although unknowingly and without having the actual name – for quite some time to develop children, because it follows B.F. Skinner’s observations about how organisms learn and develop. Recently, Ewelina Gałęzowska-Szomborg and me have discovered many connections between Scrum and Coaching process.
So definitely, Scrum is used in many places outside of Software. It existed before was implemented to software development and I hope that it will.

You can release as often as you want

For some time releasing increment was Product Owner’s decision. It has always been. It doesn’t need to be synchronised with Sprint conclusion. And if within the Sprint we have working functionality that can be consumed by the market – why should we keep them waiting?
Moreover, you wouldn’t want to release if your increment is making product not useful. Or worse than before. We are all fighting to maximise value here – not only Product Owner, though PO still remains accountable. Various of our products are already doing it – Smart is following this route for 3+ years already and I heard many other examples within Kainos that are doing just that.

Scrum Master as a „Scrum Marketing”

Careful rewording here caused everybody to realise that SM is not a policeman anymore.
You shall not use Scrum Guide as a bible and implement all of the ingredients at the same time. If all things are changed at once, people may rebel and object, because they are put in the panic zone and natural brain response is fight or flee in such circumstance. So even when introducing Scrum, try to do it in smaller steps, especially in dysfunctional organisations and products. It definitely requires SM’s patience.
For new ventures, you have greater opportunity to start with as much as possible, still you will probably find it challenging to have everything done right on the first try. This enhances a bit Scrum Master’s relation with Product Owner as you need to be a skilled marketer and storyteller to „sell” Scrum. And you need to know how to define Scrum value to the Team, organisation and Product as well as how to measure this value. Not to mention rapid „user” feedback from the above parts about the implemented changes.
I hope that this emphasis will greatly reduce the number of „Scrum Moms” that might want to do the right thing, but are not doing it the best possible way.

Daily Scrum

IT IS NOT A STATUS MEETING!
Once again, importance of this meeting as a key inspect and adapt event in a Sprint is underlined. It is in fact Review+Retrospective+Planning of the last 24 hours and for the next 24 hours in relation to Team achieving Sprint Goal. Making the daily form more elastic is another reflection of what the teams are already doing. It should make this meeting more efficient and opens possibility for having fun here as well. I’m waiting for „Dailymat” similar to retromat (https://plans-for-retrospectives.com) where we can share ideas for Daily form.
Additionally wishing that it will reduce number of „Scrum Dudes” who think that being SM is just about the 3 questions. And break teams free from the mental automatism of Daily Scrum routine.
Ideally, we could think about removing the questions altogether.

Sprint Backlog must have at least 1 Retrospective action

For some time teams have been wondering where to put the Retrospective findings so they are not lost. Now you have to incorporate them within your Sprint Backlog. For visibility and transparency. And so the Team doesn’t forget about it.
Good practice: have this action resolved with working on increment (same as infrastructure and architecture changes that emerge with the increment), so we can inspect results of last Retrospective with rest of increment on the Review of the Sprint. And you can do it for first Sprint as well, after defining initial rules for the team, figure out what else you can do within the Sprint so the work is better.
Suggestion for the start: focus on one thing only. Other might happen (and will if you have good team, organisation and SM), still the power of focus will be shown the most with completing one action within the Sprint.
For long term improvement plan – merge Change Backlog with Product Backlog and treat process, team development and organisation health as an integral and vital value of your Product. Your team is also your increment and should be important part of your Product Increment.
Although for me it will be challenging running team growing exercises within Retrospective – need to think about coming up with action after for example 2 truths and one lie.

Timeboxes are maximum time

It was obvious for certified SMs that they are maximum time.
Timebox can’t be extended – if the goal is not met within timebox, we regroup and think what we can do different next time to achieve the goal within this timebox. It is true for meetings as well as the Sprint. And if the goal is met earlier – happy days. We can spend the saved time on next thing – building more for the product, polishing our skills, reducing technical debt or just plain good old rest (or party!).
I’m also really happy of one more thing and want to repeat it. For Scrum Ceremonies (Planning, Review, Retrospective) the timeboxes are set for monthly Sprint. For shorter Sprints timeboxes are usually shorter. Not „proportionally”.
From my experience it depends more on team size than on Sprint length. And most of the teams I’m working with are working in 2 weeks sprints and our ceremonies with within 4 hours.

Summary

Changes? What changes? Once again, Scrum is noting down the observed patterns that teams are doing already.
Suggestions themselves come from Scrum Forum and were voted by users of the framework (https://scrumguide.uservoice.com/).
So we are still doing the same, only now some things are more explicitly written.
Scrum on and good luck.

Entire webinar available here – if you want to rewatch it https://vimeo.com/241757318