Back in 2005, I had just finished working on my last XP team and about ready to begin work for a large defense contractor in San Diego (HUGE mistake!!).  I had some free time between jobs and noticed that Ken Schwaber would be in San Diego to teach one of the very early Certified ScrumMaster courses, so I signed up.  It is one thing to read about Scrum on the Internet (which is where most of the information about Scrum was found back then) and another thing to hear Ken describe how it works in person.

What I remember most about that experience was Ken’s urgency on the need for change in the software industry.  Over and over again, Ken emphasized that our behavior as software professionals has been contributing to most of the challenges we experience in our industry – late delivery, poor quality, broken commitments, low morale, bad relationships, staff turnover, low profit margins, lack of innovation, etc., etc.  Ken identified two factors as source of these challenges.  One, the willingness of software professionals to cut quality as management demands the impossible, aka deliver a squirrel burger.  Two, we would rather tell lies and give excuses, explanations and justifications for our shortcomings than confront the truth – we kinda suck at building high-quality software.

In the classic story of “MLB Tix”, Ken asked people to role play a scenario where a software team over-promises the head of Major League Baseball (MLB) a fully functional ticket reselling site before opening day of the upcoming baseball season (remember this was 2005 so ticket reselling did not exist then).  Unfortunately, the site is not ready on opening day and all Hell breaks loose.  Now a representative from the software team (unlucky CSM participants) have to explain to the baseball commissioner (Ken) what was going on.

Group after group gave Ken excuses, justifications or promises of a quick fix and each was sent back to their tables by an angry Ken Schwaber.  After six failed efforts, one person from the audience finally just asks, “OK, so what would you do in this situation?”  Ken’s response, “I would tell the baseball commissioner the truth.  We screwed up and we are sorry.  We want to make this right, so we will work with you until we find a fix.”  This response has stuck with me for ten years because of its simplicity – just be honest and commit to working with the customer to fix things.  That is what any customer wants to hear.

Here are the real big changes I have seen with Scrum since beginning in 2005.

1. Work is “done” or “not done”:  in old Scrum literature there was an emphasis on the hours left remaining on a specific feature (Product Backlog item) or engineering task (Sprint Backlog item).  Understanding time remaining is not inherently bad, but with the wrong mindset this often lead to micromanagement and conformance to estimates.  What helps people make this transition is to limit the size of Sprint Backlog items to no more than one or two days.  If an Sprint Backlog item is bigger than that, it needs to be broken into smaller pieces.
2. Addition of the Task Board:  every single Scrum Team has some type of visual control to help them manage their work.  Oddly enough, Task Board is not a practice identified in the Scrum framework.  Tobias Mayer calls the Task Board the “Heart of Scrum” and wrote a short essay on this topic in his book, The People’s Scrum: Agile Ideas for Revolutionary Transformation.  The really, really successful Scrum Teams have done away with the all that nonsense surrounding electronic Task Boards for simple post-it notes on a wall.
3. The end of pigs and chickens:  if anyone is unfamiliar with this fable, it is best illustrated by Mike Vizdos.  Jeff Sutherland offers a good commentary on how and why they created the original metaphor of pigs and chickens.  As of 2011, the metaphor is no longer officially part of Scrum canon.  Thank God this hokie story is fading into the past!
4. Scrum of Scrums: as Scrum began to gather momentum, teams and organizations began to use Scrum for larger and larger efforts with more and more Scrum Teams.  Unsurprisingly, coordination among Scrum Teams became an issue, so the concept of Scrum of Scrums was introduced.  Scrum of Scrum was ALWAYS intended to be a gathering of technical people meeting as a virtual team to solve problems, but somehow along the way Scrum of Scrums morphed into a status meeting between ScrumMasters.  Recent writing from Jeff Sutherland has suggested that the Scrum of Scrums is a real cross-functional team charged with the responsibility of making the product increment potentially shippable each Sprint.

10 years of Scrum articles

Top Ten Articles You Didn’t Read: Best of the Best

That Happened in 2005? Retrospective of the Big Moments of 2005

Mastering the Agile Mindset: The Next Ten Years of Scrum