Scrum, the most used Agile framework/method in the world, has been responsible for many successful and some less than stellar Agile transformations.
Created prior to the establishment of the Agile Manifesto, but its influences heavily intertwined into the Agile Manifesto, the difficulty I have had after using it for over ten years is that I do not believe that it is adequately adapting to an evolving commercial reality. In essence, I do not believe that it fully supports the Agile Manifesto statement “Responding to change over following a plan.”
The commercial pace is getting faster, ever increasing demands are being placed on Information Technology. Ten years ago, to deliver into production every month would have been considered unthinkable for most IT shops. Now days, if you deliver once a month, especially for internet deliveries, you would be considered archaic.
Continuous delivery has helped us to overcome a number of frequent delivery barriers but it seems that it is never enough.
To keep in front of the pack, delivery of software solutions needs to potentially evolving so rapidly that what you are delivering changes on a day to day, hour by hour basis.
If you find yourself in this situation, and this will not be every delivery commercial situation, then the key purpose of a timebox within Scrum is broken.
The intent of the Scrum timebox was to have a period of no change. That at the start of the timebox, given what you were historically capable of producing within the timebox, you would pull in a similar amount of work that was highest priority in the Product Owner’s opinion. Once the planning was completed then change within the timebox was highly frowned upon – how else could you meet the initial goal without a tight control on holding external factors at bay?
But if your commercial reality is that you have to be adaptable to change within that timebox, that you cannot hold the external factors at bay, then you risk breaking the purpose the timebox.
Some would say that if you try Scrum under these conditions, but without an intention to deliver the contents decided at the start of Sprint Planning that you aren’t doing Scrum, or that you are doing Scrumbut. However, in today’s current commercial climate is this really acceptable? Is it okay that many are advocating a method that doesn’t easily support the growing needs of us as a software development profession?
Sure you can follow other method. You could have daily Sprints. Alternatively you can rework the timebox to be a regular cadence period where you always conduct a demo and retrospective, but is this still Scrum? And if it is not, then is Scrum ‘Agile’ enough for our future?