Years ago, when I did my ScrumMaster training. I thought, well, this is a nice fad. Then, after being involved in the local Agile community for a few years. The main organizer would plan a shutdown session for the community every year as he was sure we had decimated all the information we could. The work had been completed. We could now move unto new and brighter things.
But thigs didn’t work out that way. People tried and failed and tried again.
And still people start on their journey, and I have noticed one thing. People try with very little help and very little support. But the most strange thing is that most new Scrum teams try Scrum without ever finding the scrum guides. They try. And after a few months of struggle they finally relent and ask someone for help.
Can we do this? Is this against the rules of Scrum? What does the Agile manifesto say about the amount of meetings in a Sprint?
And if you do a cold search on Google for “Agile Rules” and “Scrum Rules” you can see why.
If you don’t know where to find the basics about Scrum or Agile, you’ll end in a rabbit hole, looking at Rudby matches or some software vendors software marketing meterial.
Without a bit of marketing money to get the manifesto and Scrum guides on the first three entries on Google I am affraid this will remain the norm.
But if you did manage to make it to the Scrum guide. There’s a wonderful section on the changes to the Scrum guide over the years. And this brings me finally to the topic of this blog. How the changes to the Scrum guide reflects the most important thing in Scrum and Agile. And I think the reason why they are surviving far beyond most people’s expectations. “Change” is build into Scrum and Agile and has been from the start. As a Team you should reflect on the new state and enviroment you find yourself in. And change the way you do things and hopfully make a good change.
Some of the changes over the years is that the Scrum guide has become less presciptive. They took out the section about commiting to the sprint backlog to working to a forcast. Because we know as we learn more, we have to adapt. This was the first mayor change to a more fluid system.
The creators also quickly realized that Teams stoppped trying to improve, because change is hard. So they backtracted and proscibed the Retrospective improve go into the Sprint backlog.
With this ever changing way of working I can now see for myself being asked the same questions years from now from Teams that have being doing Scrum for months or years. The same questions that lead me to sending them their first copy of the Scrum guide and a link to the Agile manifesto.
The more things change the more they stay the same.