The Good, The Bad and the Ugly of Scrum: Or Telling The Emperor He Has No Clothes

July 26, 2014 — Posted by Al Shalloway

I am about to head off to the Agile Conference in Orlando.  At these times I always think about the state of Agile and am usually disappointed when I think about what is possible and what actually is present.  Oh, I don’t mean “if only the industry would do what works” kind of thoughts, I’m more thinking “if only consultants would recognize what works and what doesn’t.” 

I just started working with a small client (less than 100 people in the development side of things).   I was told they went with Net Objectives because we weren’t committed to a particular approach-that is, we were coming from the needs of the client and not attached to one particular framework or method.  The client didn’t think Scrum would work for them, an opinion shared by me as well.

However, it occurred to me, what a great consulting approach – always suggest Scrum.  Since it works when it is used properly, a consultant who recommends it can never be blamed for the recommendation.  I mean, if it works – great - kudos.  If it can’t be properly used, the client won’t follow the consultant’s advice so we can blame the client for doing “Scrum-but.”  Unfortunately, as often as not, doing Scrum properly is not the best thing to be doing – and is often essentially impossible without considerable unnecessary expense.  But no matter, when it fails, it’ll fail because the client didn’t do Scrum.

This is the Emperor has no clothes part.  Scrum is a good framework in certain situations.  Not so good in others.  And, no matter what your situation, is simplistic and leaves some things out it shouldn’t. 

Before I get into the meat of this blog, I want to be really clear – I like Scrum.  At least, I like it when it is used in the right situations and extended in the right manner (it always needs to be extended).  I don’t like when it is used in the wrong situation and really dislike it when I hear people promoting Scrum everywhere (e.g., they don’t tell you where it shouldn’t be used).   Some people call this bashing, but I call it being pragmatic and honest.  For example, I live in Seattle and drive a Lexus.  I love my Lexus – really.  Best car I’ve ever had.  But it doesn’t drive into the Puget Sound the way these ducks do.   It’s also not good off-road.  But saying my Lexus won’t go into the sound (more precisely, will go in, needs towing out) or off-road is not bashing it.  It’s recognizing the car’s limitations and loving it for what it is good for.  That’s how I feel about Scrum – it’s great when used properly and should not be promoted to work everywhere – because it doesn’t work everywhere.

Where Should Scrum Be Used

Scrum is a great framework when one can form and use cross-functional teams.   In smaller organizations this is not too difficult.  Scrum is often powerful for many parts of the development organization even when the development group is large and requires Lean and Kanban to fully implement Agile across the organization.   But it is a myth that all companies can (or even should) use cross functional teams.  All too often particular skills are in short supply (e.g., subject mater experts, architects, people who were around when the legacy code was written, ...) or are not needed full-time on a team (e.g., DBAs). While creating cross-functional teams to the extent possible is a great idea, it is not always advisable to do it completely.

What Should Virtually Always Be Added to Scrum

Even when Scrum is a good fit, there are several attitudes and practices that should always be used.  These are:

  • Test-first methods (e.g., ATDD or BDD at a minimum)
  • Explicit workflow – have the team discuss the best way for them to work and make it well known
  • Visibility of work inside the sprint – not just how work gets in, how it gets out or what amount is done
  • Manage work in process (WIP)
  • Be inclusive of management (no more chickens and pigs)

Where Should Scrum Not Be Used

An example where it is often difficult to use Scrum (even for small companies), is in mobile and applications with rich UX.  In these cases, the skill sets required are varied (often as many as 6 or so distinct skills on the development team).  Cross-functional teams here are rare, and many of the skills are only needed some of the time.  In this case a combination of teams and people supporting the teams (managed either with weekly planning or Kanban) is a better approach.

In Conclusion

Scrum should be a tool in your toolbox.  So should Kanban, the Kanban Method, ATDD, TDD, design patterns, refactoring, and many other things.  The toolbox, however, should be something you can take anywhere.  Those of you who know me know I believe that’s the Lean Mindset.  If you’re at the Agile conference next week, please look me up – I’ll be doing the dot game on Monday and a SAFeTM Executive overview on Tuesday and  hanging out in the open space much of the rest of the time.  Happy to discuss this, regardless of your view on the matter.

Al Shalloway
CEO, Net Objectives

Related Blogs




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