How To Get the Scrum of 2017 Today

July 28, 2012 — Posted by Al Shalloway

The More Things Change the More They Stay the Same

When I write blogs I think that many folks want to hear how I came to my conclusions.  But I sometimes wonder if that is true.  This blog has a long back-story, which, although I think others may find valuable, is not really essential for the blog’s bottom line message.  I therefore have written this blog in two parts: 1) the back-story of how I got here and 2) the bottom-line of the blog.  Feel free to just jump to the bottom-line if you are rushed or aren’t interested in the back-story. Comments about the value of the back-story greatly appreciated.

The Back-Story

I often tell people I am pre-cognitive impaired (that is, I don’t see the future).  However, I do notice patterns.  I see a light go from green to yellow and then to red.  I see another light go from green to yellow to red.  Yet another light goes from green to yellow to red.  Eventually, I see a light go from green to yellow and I say to myself – that light’s going to go to red shortly.  Pre-cognitive?  No, observant of patterns.  Having been in the software industry for 42 years doesn’t make me smarter – but it does mean I’ve seen a lot.  It’s also makes it easier for me to see patterns that happen over time. Over the last dozen years I have seen a pattern in the evolution of Scrum and thought I would share it.  

First, let me tell you a little about my vantage point.  Net Objectives’ was one of the early Scrum training companies.  In 2002-2006 we were also one of the largest in terms of the number of folks trained in Scrum (in the thousands, but not all as CSMs).  We still do a lot of Scrum training and still consider it a good, albeit, not the best, team method out there.   

In our early Scrum days, we conformed to the standard Scrum approach.  Unfortunately, after a few years we found that being a part of the Scrum Alliance slowed down our ability to teach advanced Scrum methods – which is why we left the alliance a few years ago. We, as well as several others, were threatened with losing our certification if we espoused new, non-approved, methods.  While I believe this attitude has been corrected in many ways, I also believe it has created a culture of slower to change than I have seen in other communities focusing on a particular method.  In my opinion, a focus on teaching any one methodology will have you focus on that method when, in fact, others (or aspects of others) may prove more valuable for your particular customer at hand.   We have found that it is essential to re-evaluate our methods and include new ideas on a regular basis.

This was not a new thing for us.  Net Objectives originally was a technical training company.  We quickly found that although quality development methods are essential, they are often not the primary challenge being faced by most teams.  We came to Scrum after having done eXtreme Programming for a couple of years.  We encouraged technical practices that are now prevalent in Scrum teams but were rare back then.

But it wasn’t just technical practices where Scrum needed to evolve.  After doing Scrum for a few years we saw that Scrum, while a good team method/framework, did not help many companies achieve agility across several teams.  We also found many companies where it was difficult to start Scrum because of the challenge of creating cross-functional teams.  The Scrum mantra that “it’ll work if you would only do it” didn’t obscure our feeling that there had to be a better, less disruptive way of achieving an Agile result.  Just because something can work doesn’t mean you don’t want to find a better way.  In Lean we found a solution to the first challenge, in Kanban we found a solution to the second.

Incorporating Lean and Kanban methods into Scrum was pretty straightforward to us.  Our president, Alan Chedalawada, and myself, have a long history of Lean (over 5 decades between us now).  Eventually, we abandoned Scrum as a starting point and used Lean as the context for all of our Agile work – putting both Kanban and Scrum within it.  This helped us solve many challenges we could not solve with Scrum alone.  The methods we use included shared backlogs, managing flow, and minimizing work in progress while keeping people productive.

We continue this path of adopting methods pulled from eXtreme Programming, Lean and Kanban.  Sometimes we come up with new methods, more often we borrow them from other thought leaders.  Years ago I often found this whole process to be very frustrating, however.  We would try things, have great success, tell other Scrum consultants about it and be reasonably ignored – or even be told to stop talking about the methods because “they weren’t Scrum.”

Eventually, however, many Scrum practitioners have adopted many of these methods seeing that they work and not worrying about whether they are part of Scrum or not. Unfortunately, this practitioner led adoption of new methods has resulted in Scrum evolving at a much slower pace than Kanban – whose evolution is being led by its thought leaders.

I am reminded of the old adage - “new good ideas are often first ignored, then ridiculed, then accepted as obvious fact.” So true, but unfortunately, a multiyear process. The question for practitioners, anyway, is how to get ahead of the game.  To show the pattern, I have created a list of practices that have passed through the ignored and ridiculed stage and have now been adopted.  Others are still progressing through these stages. I suggest not waiting until they are officially sanctioned by some Scrum organization.  Instead, even if you are using Scrum, start looking at where Scrum came from – Lean Product Development.  This too is ironic.  I’ve been claiming this for years and it was ignored, ridiculed and now accepted as obvious. 

Now, here’s the bottom line.

The Bottom Line

Practices Now Part of Scrum That Initially Met Resistance:

  • Teams should have explicit policy of what it takes to get something out of the sprint (done-done)
  • Teams should have an explicit policy of what it takes to get something into the sprint (sprint ready)
  • Don’t have a team member start a story if she can help someone else finish another one
  • Don’t tell Scrum teams lessons learned by other Scrum teams when they first start out.  Doing so hurts their ability to learn on their own
  • Stop talking about management as being chickens

Practices Still Being Debated That Are Slowly Becoming Adopted By Scrum Teams

  • Have an iteration 0
  • Manage work in progress (WIP) *
  • Use classes of services **
  • Allow pushing stories that haven’t been started yet out of the Sprint to make room for new priorities at the request of management

Practices I expect to See as Part of Scrum in 5+ Years

  • Use shared backlogs to coordinate teams instead of Scrum-of-Scrums
  • Explicit workflow  *
  • Scientific method *
  • Use relative estimation instead of Mike Cohn’s Planning Poker (James Grenning’s Planning Poker is also a good alternative)
  • Use Acceptance Test-Driven Development (ATDD)
  • The product owner is insufficient for getting requirements from stakeholders to teams when multiple stakeholders and multiple teams are involved
  • Starting with pilot teams without regard to the over-all value stream is risky
  • Attend to cycle time more than team velocity **

* these methods are core Kanban practices.

** this method is a common Kanban practice

BTW: If you haven't figured it out, the last two sets of bullet points will be in the Scrum of 2017.  Nothing stops you from using them now!

Resources to Learn more

Go to our Resources page.  There is days of material in webinars, articles, podcasts and more.

Lean-Agile at Scale and the Team: The Value Stream Series discusses how to achieve enterprise agility – one webinar at a time.  Three of these webinars are now available as recordings:

  • Lean-Agile: The Next Generation of Agile
  • Product Portfolio Management: Why It Is Critical for Agile at Scale
  • Team Agility: Scrum, Kanban, XP – The Essence of All Three.

You can still register for our next one on August 14 – Technical Agility: ATDD, TDD, Refactoring and Patterns

See the Net Objectives’ Lean-Agile Roadmap to see what we have found necessary to achieve Agility at Scale.

Want to improve your Scrum?  Take our Advanced Scrum course.

Much of what we teach in this course can be found at our Scrum Clinic.                      

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