Why I Care About What Scrum Can and Cannot Do (informal)

January 31, 2009 — Posted by Al Shalloway

On the Lean Agile user group there has been a running debate on what Scrum is and why should we care.  I wanted to explain why I cared about what Scrum is.  This is essentially a post I made there earlier today.

I bother because people coming to Net Objectives have a poor appreciation for what Scrum is and what it can do.   Most of them have tried Scrum and are having problems with it.  The rest recognize they want to go Agile but don’t see how Scrum can apply to their entire organization.

The fact that people are confused about Scrum should not be surprising.  On this and other recent threads, I have heard several different definitions of Scrum:

1)      Scrum is what it was originally described to be

2)      Scrum is what it was originally described to be and includes improvements to its practices over time

3)      Scrum is what the creator says it is

4)      Scrum is what Ken Schwaber says it is

5)      Scrum is what those who have the authority to say what it is  (Scrum Alliance)

In the original book on Scrum and in all of the papers on the origins of Scrum, Scrum is a methodology to do software development.  While not saying it is only about projects, every example in every article / book I’ve read about its origins are about a project – so it’s a reasonable inference to think it is about projects.  The second definition means to take what we started with and include improvements.  Even when discussing scaling (e.g., Scrum of Scrums) it is about coordinating teams in large projects. Personally, the second definition, with the associated improvements to Scrum’s practices is what I take Scrum to be.  

Things diverge from here pretty quickly however.  This is particularly relevant to large organizations that have multiple product lines.  Once you get into multiple product lines, it is critical to do proper product portfolio management.  I have seen the impediments affecting the teams using Scrum in this situation have a larger impact on the teams productivity than anything the team is doing themselves.  This typically comes from overloading the teams and having them work on multiple projects.  Some of you will say – “they aren’t doing Scrum because Scrum says to have people on _a_ team, not across teams.”  This is _my_ point.  What has to happen to get people on one team is not discussed in anything I’ve read in the original Scrum.  Merely telling people to do what they should (a la The Enterprise and Scrum) is not enough.  Since they don’t understand why they should be doing this, they are stuck and don’t know how to get out.

I would be fine with “Scrum is what the creator said it is.”  Jeff Sutherland created Scrum. In an attempt to expand Scrum and solve some of the issues mentioned above he expanded Scrum and called it Type B and Type C Scrum.  I suspect he did this to avoid the confusion of calling three different intents one thing (from projects to product portfolios). But he got pushback from Ken Schwaber –“ there is only one type of Scrum”. 

Unfortunately, Ken is not consistent with himself.  I once described Scrum as something that existed at the project level and Ken corrected me to say Scrum was a team methodology.  Later he said it was an enterprise methodology.  Furthermore, if it’s all Scrum and we have to do daily scrums, then executives in large organizations who are trying to coordinate the direction of the products to be built within the organization should be doing daily scrums.  Clearly, that’s not going to happen.

Finally, is Scrum what those in authority say it is?  Does this mean the Scrum Alliance? Mike Cohn, at Agile 2007 said the Scrum Alliance shouldn’t specify what certification meant because what Scrum is is changing and certification would make it static (ignoring the fact that you could easily change certifications).

So, given that sometimes we hear Scrum is about the team, sometimes about the organization, sometimes it’s fixed, sometimes it isn’t, sometimes there are three types and sometimes it’s all Scrum, it shouldn’t be surprising that people are confused.

This is exacerbated by the fact that the Scrum Alliance for years promoted that being a Certified Scrum Master means you actually know how to do Scrum. Most people have forgotten, or never knew, that the CSM course was originally intended for professional coaches teaching teams how to do Scrum.  Everyone going into the course already knew what Scrum was.  It was about teaching them how to coach it.  People coming out of those early courses were mostly able to be good Scrum Masters.

As Scrum got to be more popular, the bar for who was coming in was lowered.  But not the hype on what a CSM meant. CSM courses range from being intro to Scrum to being actually about being a Scrum Master.  Depends on who you get as to what you’ll get.  It is almost certain that you’ll have a wide variation in who is there – making teaching a good class difficult.

The Scrum Alliance has taken no responsibility for putting Certified and Master together.  I am not going to condemn them for doing such a masterful (pun intended) job of promoting themselves.  But I am not going to be quiet while the industry suffers from the misunderstanding it causes.  They also clearly do not want an open conversation of what Scrum is or what the effectiveness of the programs are as several dignitaries (including Scrum Alliance Certified Scrum Trainers) have been thrown off the discussion lists (one I know even being defrocked as a CST but later re-instated) for dissension.  Thus, the Scrum community has been exhibiting command and control of their ideas – something I do not think is a good thing. And is incredibly ironic since Scrum is about just the opposite of that.

But, back to why I care.  For whatever reason, people are confused about what Scrum is and what it can do.  People don’t understand the difference between using Scrum at a project level and people using Scrum at an Enterprise level.  In the way that Scrum has found XP engineering practices to be useful at the project level, we have found Lean practices to be useful at the enterprise level.  Following an understanding of Lean principles would be even more useful.

Therefore, I care that people are not properly prepared to use Scrum, nor do they know the limits of Scrum without additional practices and principles being included in it.  I understand that Scrum does not preclude such stuff, but in the confusion about what Scrum is, people don’t recognize they need it and it is forbidden to talk about it on the Scrum Development group.

As an expert in Scrum and other Agile methods, I feel compelled to give people an alternative to what works in some cases but not in others.  As a minimum, I want people to know what Scrum can help them do because those who make their livelihoods at Scrum are not being explicit about it.  Some have accused me of “bashing Scrum.”  I prefer to think of it as educating those who haven’t tried it yet and don’t know what it can or cannot do.  Helping people is my goal – not protecting any Agile or Lean method.

I care because that is who I am.  I am not saying I care more than others.  I am saying that our business model leads us to working with many people who have undertaken Scrum believing it can do more than it can – or in many cases, more than they know how to do it. I am not saying experts can’t use Scrum alone or that they don’t know when to expand Scrum to achieve what they need.  But our clients aren’t experts.  They are looking for guidance.  Some of that is pointing out limits of popular methods. I am not focused on getting people to use Scrum effectively, I am trying to assist people in developing software effectively with whatever works.

Our preferred method of engagement with a company is to do an assessment.  To discover where the real problems are.  Is it at the team, the way teams work together?, the way teams on different projects work together?, the way products are selected to be worked on?, the project planning cycle?, the lack of well-defined teams?, … ?  The list goes on.   Applying Lean-Thinking to the value stream of a software development organization (not merely one product but all of them) gives great insights into how to move forward.   When Scrum is appropriate, as it usually is, we show them how to do Scrum or help them move forward with it if they’ve already started. 

I agree that fighting over what Scrum is, or what Scrum can do, is tiresome.  I just wanted to say why I cared.  Most of my posts are not for people who understand Scrum or Lean.  It is for those people who are not sure what Scrum or Lean or Agile is.  Our upcoming book Lean-Agile Software Development: Achieving Enterprise Agility, attempts to lay out what a good Lean-Agile set of principles and practices would be.  It incorporates Lean as the context for Agile.  Virtually all of Scrum’s principles are incorporated in the principles of Lean Software Development.  Lean, and hence, Lean-Agile, is very clear that the context for the methods described is for achieving Enterprise Agility.  Methods to achieve that involve agility at all of the levels underneath it, but within the context of optimize the whole.

The bottom line is – people are confused about what Scrum is.  I am not really trying to lay blame.  I went to lengths describing this just to make it clear why this confusion should come as no surprise.  Given the confusion, I believe that someone who has helped teams do Lean, Agile, Scrum and software engineering practices should speak out. 

Alan Shalloway
CEO, Net Objectives

Subscribe to our blog Net Objectives Thoughts Blog

Share this:

About the author | Al Shalloway

Al Shalloway is the founder and CEO of Net Objectives. With 45 years of experience, Al is an industry thought leader in Lean, Kanban, product portfolio management, Scrum and agile design. He helps companies transition to Lean and Agile methods enterprise-wide as well teaches courses in these areas.



        

Blog Authors

Al Shalloway
Business, Operations, Process, Sales, Agile Design and Patterns, Personal Development, Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Cory Foy
Change Management, Innovation Games, Team Agility, Transitioning to Agile
Guy Beaver
Business and Strategy Development, Executive Management, Management, Operations, DevOps, Planning/Estimation, Change Management, Lean Implementation, Transitioning to Agile, Lean-Agile, Lean, SAFe, Kanban, Scrum
Israel Gat
Business and Strategy Development, DevOps, Lean Implementation, Agile, Lean, Kanban, Scrum
Jim Trott
Business and Strategy Development, Analysis and Design Methods, Change Management, Knowledge Management, Lean Implementation, Team Agility, Transitioning to Agile, Workflow, Technical Writing, Certifications, Coaching, Mentoring, Online Training, Professional Development, Agile, Lean-Agile, SAFe, Kanban
Ken Pugh
Agile Design and Patterns, Software Design, Design Patterns, C++, C#, Java, Technical Writing, TDD, ATDD, Certifications, Coaching, Mentoring, Professional Development, Agile, Lean-Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Marc Danziger
Business and Strategy Development, Change Management, Team Agility, Online Communities, Promotional Initiatives, Sales and Marketing Collateral
Max Guernsey
Analysis and Design Methods, Planning/Estimation, Database Agility, Design Patterns, TDD, TDD Databases, ATDD, Lean-Agile, Scrum
Scott Bain
Analysis and Design Methods, Agile Design and Patterns, Software Design, Design Patterns, Technical Writing, TDD, Coaching, Mentoring, Online Training, Professional Development, Agile
Steve Thomas
Business and Strategy Development, Change Management, Lean Implementation, Team Agility, Transitioning to Agile
Tom Grant
Business and Strategy Development, Executive Management, Management, DevOps, Analyst, Analysis and Design Methods, Planning/Estimation, Innovation Games, Lean Implementation, Agile, Lean-Agile, Lean, Kanban