The Holy "Scrum" War
One of our generally mild-mannered beta customers caught me by surprise recently when he said, “Scrum zealots are like vegans and barefoot runners who keep trying to convert me.” Now, before you read on, you should know that I am dev methodology agnostic and have been in orgs that have used just about every approach. My ears simply perk up when a methodology takes on a religious fervor, for or against. These are the signs of a potential holy war.
I have spoken with over 75 companies in the last few weeks about Aha! and half are using agile scrum practices in engineering. Another 10 percent or so are considering moving to scrum. I think scrum is seen as the pinnacle of methodologies by some companies, especially those that failed with a previous approach and are now trying to “go agile.”
I have seen this fervor firsthand. I was recently in a company where the program management team was trying to convince everyone of the virtues of scrum as a fix-all. They were even trying to convince marketing, PR, and legal that they should use scrum as well to manage their work.
Regardless, I appreciate people with conviction around scrum and understand why some teams feel so strongly about it. I think the MythBusters-like devotion for scrum should be respected and better understood. I think there are two key motivators for it:
#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 is 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.
We should appreciate scrum for what it is and what it can deliver. Scrum is engineering-centric. Great companies are customer and product-centric.
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 is 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. Great product managers have a product vision and a goal first approach to what they are trying to deliver. They are good at assessing the market environment, customer needs, and their company’s capabilities. This thinking then informs the roadmap and sets business-driven product imperatives that the roadmap and features should map to. This thinking must come become before the “how” and scrum really has no role in figuring this out.
It is also important to point out that the “why” is best worked on in a collaborative way between product, engineering, design and other functional leads. Scrum can get in the way of this if engineers are always focused on the tactics of what is next.
Scrum also has little to do with the process to define the “whats.” The agile methodology discusses the point where sprints are groomed and user stories selected, but it does not cover how to actually capture customer-focused user stories which define “what” is going to be built or how they should be prioritized. These need to come after the “why” and be clearly articulated to drive engineering efficiency.
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 is still simply a dev methodology and not a panacea for building meaningful companies and delivering great product. It is only 33 percent of the equation when it comes to delivering product.
