BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News Drinking the Scrum Kool-Aid

Drinking the Scrum Kool-Aid

This item in japanese

Bookmarks

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.

Rate this Article

Adoption
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

  • Good point

    by Louis Giokas,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Scrum is a good point methodology. It is not the end all and be all of product development. I worked on a spacecraft project in the 1970s where we used what today would be a scrum process. We had a monthly deliverable, and everything was tested on a daily basis. Frankly, the satellite launch was delayed, so we had the completed satellite on the ground and powered up. We also had the control center ready. Thus, the "user" community was well represented and the developers had consistent and constant feedback. We also had that well defined backlog.

    On the other hand, we had a well defined project with very well developed requirements and some internal configuration management and project development tools. There was a group that worked on that aspect of the development process and a group that developed the plan and product requirements outside of the "scrum" process. This is very much what Danny and Brian discuss. With BPM tools and software engineering tools an organization can create that deep backlog for the software engineers that is talked about. This is a way to let engineers be engineers and do what they do best.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

BT