The Holy “Scrum” War blog by Brian de Haaff argues that those who claim Scrum will save your company are wrong.
Brian explains that while the religious fervour some people have for Scrum is something to be respected, we should also understand why these "Scrum zealots" exist. He provides two key motivations:
#1 Engineers like to build stuff
Where would the world be without inventors and engineers? Likely still in caves hunting and gathering. Engineers have built the world we live in and the ones I know well are driven by making stuff that matters. Scrum is a great way to help keep engineers focused on building. It provides a framework that prioritizes delivering real, working, business-quality software sprint after sprint. It’s rewarding to get things done and cross items off the list and Scrum ensures that there is always a long list and always a next item to complete. Scrum guarantees that there is a never ending to-do list.
#2 Engineers don’t like to be yelled at
Let’s get real. No one likes to be yelled at. And Scrum helps engineering managers and engineering teams avoid being yelled at for not being able to predict when their work will be done, because Scrum is not date driven. Scrum suppresses the notion that “dates matter” and provides a way for engineers to methodically move from one feature to the next without the pressure of delivering work by a certain date.
While Brian acknowledges that Scrum is a proven method for defining and managing how a product is engineered, his key argument is that Scrum does not provide the necessary input to building a great product or a great company.
I think the real challenge with Scrum begins when it is broadly described as a way to innovate or deliver great product. Great product starts with the “why” includes the “what” and is delivered through the “how.” Scrum is a fine method to use for delivering the “how.” It’s a way to bring efficiency to the development manufacturing facility and works well in some environments.
However, Scrum does not explain the “why” which is the strategy behind how a product is going to win in market by being lovable.
One of the principles behind Scrum is that it won’t magically supply the “why.” Ken Schwaber explains in Agile Project Management with Scrum that the vision must already be there.
The minimum plan necessary to start a Scrum project consists of a vision and a Product Backlog. The vision describes why the project is being undertaken and what the desired end state is.
Without the “why”, Brian asserts “Scrum can get in the way of this if engineers are always focused on the tactics of what’s next.” Ilan Goldstein shows in this post at Axis Agile that without the product vision, teams do end up focusing on things they know such the “what” and “how”:
With the eagerness to just jump in and start building ‘stuff’, new Scrum teams often put all their attention on the ‘what’ (the Product Backlog) and the ‘how’ (the Sprint Backlog). This is like putting the cart before the horse, as before we even consider the ‘what’ or the ‘how’, we need to seriously consider the ‘why’. The ‘why’ is not found in the Product Backlog or the Sprint Backlog but rather in a separate axiomatic artefact known as the Product Vision.
Brian concludes that before drinking the “Scrum Kool-Aid” it’s important to ensure you’re not blindly looking to Scrum as a cure-all:
There is no doubt that Scrum is an important movement and that it is having a positive impact on engineering team productivity everywhere. Yet, it’s still simply a dev methodology and not a panacea for building meaningful companies and delivering great product. It’s only 33% percent of the equation when it comes to delivering product.
Scrum will not save your company or the world, so beware the knock at your front door. The zealots are coming.