This is Part 2 of a 2-part post.
In Part 1 I provided some context for my post inspired by the book “Scrum: The Art of Doing Twice the Work in Half the Time” by Jeff Sutherland, including a disclaimer on why you might not like this book. If you are experienced in Scrum methods, please look at Part 1 before reading this post. If you don’t have any Scrum experience, please look at Part 1 before reading this post!
Why I Loved This Book!
With my career focus on realizing business value from IT investments I’ve seen so much “business value leakage” and even many outright project disasters. As such, I’m inherently a believer in agile approaches, and wonder why they are so slow to penetrate enterprise IT organizations.
Scrum draws heavily on the principles of Lean, with aspects of Iterative Development, Rapid Application Development (RAD) popularized by James Martin, and is one dimension of the Agile movement. The book is very much a history of Scrum–and a compelling history it is! If we are to believe the author (and his credentials are stellar!) many major projects that were waaaaaay off track were brought back on track using Scrum.
I’ve always believed in the mantra, “Deliver value early. Deliver value often” and this is inherent in the Scrum approach. What surprised me most about the book is that Scrum can be and apparently is being used in a wide variety of projects and businesses, well beyond the world of software projects. In retrospect, this makes sense. With the pace of change we all live under, the ways social media and Web 2.0 technologies enable rapid experimentation and the rise of ‘customer experience’ as the key perspective, the notion of rapid delivery of value in a series of short “sprints” makes sense.
Dr. Sutherland has an impressive background–from Top Gun fighter pilot with over one hundred missions over North Vietnam, to receiving a Doctoral degree from the University of Colorado Medical School to systems development and the co-father of Scrum. He is a great story teller–his many anecdotes and experiences are highly relevant and compelling. The book is well-organized, with each chapter ending in “The Takeaway.” Apart from the anecdotal evidence in favor of Scrum and the sheer logic of his arguments, Sutherland presents mathematical evidence of the cost of ‘context switching’ so prevalent in the way IT organizations run today, and in the prevalence of misguided multitasking that is robbing us not only of quality, but of lives, as people try to drive and text or conduct phone conversations at the same time.
Jeff gets into a topic I feel quite passionate about because I see it very frequently in my clients–we are all working harder than ever and generally getting less done! This is an insidious behavior–creating the delusion that we are getting things done, while the reality is that we are simply busy–trying to get so much done that nothing of value is really getting done–or that we are unable to distinguish between the valuable and the urgent.
The book reminds us of what we are all acutely aware–detailed ‘waterfall style’ project planning creates a lot of work and delivers an illusion of reality that almost never pans out.
The Trouble With Scrum
Other than the inevitable learning curve, there are some very real problems with Scrum–or more to the point, with the context in which Scrum is applied. These include:
- The IT project funding model. There’s an age old aphorism about crime, “If you want to understand a crime, follow the money.” My corollary to this is, “If you want to understand dysfunctional behaviors around IT, follow the money!” Most funding models drive dysfunctional behaviors. With regard to Scrum, funding models are often not set up to fund in increments, and business sponsors feel that if they don’t sponsor the whole project up front, they may be left ‘hanging’ with additional needs and no resources to support them. Sponsoring the whole project up front typically means building the project plan and securing project resources–with the implication that you know exactly what you are going to deliver and how you are going to deliver it–which flies in the face of Scrum. I believe there is merit in adopting a Real Options approach to funding business initiatives, and that this might align quite nicely to Scrum and other agile methods.
- The shortage of skilled Scrum Masters and Product Owners–roles crucial to Scrum success.
- Resistance to organizational change. It is ironical that even though we know that waterfall approaches don’t work very well, we at least we are familiar with those methods and feel like we have control (even if that is largely fantasy!) we are reluctant to try new methods, no matter how compelling the evidence might be about the value of those methods.
- Clarity of what types of solutions best lend themselves to Scrum, and what to stay away from. I hear this quite a lot, and have to say I’m actually rather skeptical that Scrum can’t be applied to most, if not all, business problems and IT solutions. However, I don’t have the experience base to support my skepticism–reader feedback welcome!
Implications for Business Relationship Management
Regular readers of my blog will know that since co-founding Business Relationship Management Institute in early 2013, many of my posts have a Business Relationship Management (BRM) spin, so I want to explore the implications of Scrum on the BRM role. Having teed that up, I have to admit that I have many more questions that answers. I’ve had many discussions with BRMs about Scrum, and this is what I’ve learned so far:
- Some BRMs have no idea what I’m talking about when I raise questions about Scrum.
- Those that do are generally enthusiastic about the concept but are having a hard time nudging their Project Management and Solution Delivery groups into adopting Scrum methods.
- A few actually have Scrum ‘experiments’ going on, with generally positive results.
I’ve recently kicked off some research among the BRM community and will share my findings through this blog and other channels. If you have some experience and would like to participate in the research, please let me know directly, or via comments on this post.
Graphic courtesy of Axis Agile