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?
Agile Forest 
I’m not a huge fan of Scrum, but… while it’s not for everyone, it’s still quite applicable to a lot of environments.
There are actually very few places where all of the feedback cycles are weeks or less. Where you make small changes and deliver constantly. Heck, there are still lots of places where delivering once a month would be considered a breakneck pace.
While Scrum isn’t on the bleeding edge of Agile fashion, it still is a framework worth considering for many places.
Thanks Robert. I agree the pacing problem is not an issue for everyone, but I have seen it all too often to believe that it is the minority and not a majority issue, especially over the last few years.
Hi Renee,
Have you ever been a day or two into a challenging multi-day activity when someone has unexpectedly tapped you on the shoulder and suggested that you discontinue and shift focus to something quite different? Isn’t that called ‘thrashing’? What if the first activity is never completed and never delivers anything of value? Isn’t that called waste?
Scrum Sprints fundamentally define an interaction cadence for the team and stakeholders to collaborate on product direction. I think it is instructive to look at Sprints as an enabler of that iteration where a regular cadence allows for easy scheduling (reducing transaction costs).
I have used Scrum for highly experimental R&D involving a lot of exploration and creativity where a lot of what you might call the ‘contents’ of Sprints (especially in terms of Sprint Tasks) we unknown and changed substantially a couple of days in as we learned rapidly what would not and what would work to achieve the Goal. What was stable was the Sprint Goal. Sprints defined a short period for which the team could focus on solving a substantive problem and seeing something meaningful through to a Done outcome of value without distraction or interruption that would have been highly wasteful.
Are Goals really changing unexpectedly and more frequently than weekly?
If so, is this an optimal environment for complex problems to be solved and for valuable increments of significance to be created?
Is constant change of Goal an optimal way to run a project, product development (or an organisation)?
As a former developer, I know that having the goal you are working hard towards suddenly change when you’re part way through something can be frustrating and demoralising.
What is it about the ‘commercial reality’ you mention that leads to people not being able to let a team focus on a stable Goal for a single week without interruption? Is there a dysfunction in that space worth addressing?
Scrum is about surfacing such issues so that we can do something about them rather than blaming the tool.
Hi Rowan,
Thank-you for your feedback.
I have seen Sprint Goals dramatically shift inside Sprints for BAU or maintenance related teams, or especially where teams are supporting multiple products (despite even if they have a single Product Owner). The commercial reality is you may need to get production working ASAP over your Sprint Goal, or respond to a big client proposal.
R.
Great post Renee, I have often wondered what the effect of continuous delivery has on the sprint timebox, have now got more questions than answers (which is normal *grin*).
This sounds like a team evolving from Scrum to Kanban, and that’s okay isn’t it?
Potentially. It just niggles at me somehow that I shouldn’t have to change method to get this solved, not that Kanban is really a method.
Eventually you’ll learn to work both in planned cadences and with event-driven work; in parallel and at the same time; and it is not even difficult.
What one need to show though is the cost of interruption. Event-driven can be very expensive both in terms of ability to complete planned work on time, and in terms of quality. All costs must be visible.
Of course your methods should evolve. Evolving method is key in all frameworks that include continous improvement. Scrum by the book is an excellent starting point, but is not necessarily what you end up with after a while. In the retrospective where you inspect and adapt the method, Scrum itself contains the seed to evolve away from Scrum into something else.
Eventually you’ll learn to work both in planned cadences and with event-driven work; in parallel and at the same time; and it is not even difficult.
What one need to show though is the cost of interruption. Event-driven can be very expensive both in terms of ability to complete planned work on time, and in terms of quality. All costs must be visible.
Of course your methods should evolve. Evolving method is key in all frameworks that include continous improvement. Scrum by the book is an excellent starting point, but is not necessarily what you end up with after a while. In the retrospective, where you inspect and adapt the method, Scrum itself contains the seed to evolve away from Scrum into something else.
Thanks Ola for popping in and providing your insight and thoughts.
Scrum is an okay way of working for some projects and a disaster for others. But either way it is NOT Agile. And it will never be “Agile” no matter how many times books, web sites and acolytes repeat it. IUf you don’r believe me then just read the Agile Manifesto with your brain engaged.
Scrum is not Agile. It might be a good way to orrganize work for some projects but no matter how many times web bsites and acolytes say “Scrum is Agile”it isn’t! At best it is partly Agile and partly Agile’s antithesis.
If you don’t believe me then read the Agile Manifesto with your brain engaged and see for yourself how well (or not) Scrum conforms to those four principles. Scrum enables responding to changing requirements while imposing a load of ant-Agile rules and procedures.