Scrum Is Dead. Long Live Scrum. [Part 1]

There has never been a shortage of criticism around the Scrum method for agile project management. However there has been a recent spike in the churn and swirl, and it’s time for some perspective. Specifically this:

The old understanding of the Scrum landscape is dead, and a newer more relevant version is rising in its place.

However, with this jarring change, comes a lot of complaints, confusion, and cults.

1. Complaints over Scrum It’s hip to complain about Scrum. All the kids are doing it, and it makes you feel good. A couple years ago, Jim Shore was among the first cool rebels, saying “Rescuing Scrum teams keeps me in business”. His complaints boiled down to Scrum certifications, which give beginners a false sense of competence, leading to disasters that he has to clean up. The criticisms haven’t changed since then. Just a couple weeks ago, agile co-founder Bob Martin posted his thesis on the shortcomings of Scrum, which offered the same old critiques we’ve heard before. Several people offered their rebuttals, but I doubt that will stop the hen-pecking any time soon. Granted, some of the criticisms are legitimate. But I see very few of these hipsters stepping into the mire to make things better. I am much more impressed by gurus like Ron Jeffries or Alistair Cockburn, who became Scrum trainers because of the complaints, so that they could be a part of the solution. It turns out that Bob Martin and Jim Shore have been contributing to the upcoming Certified Scrum Developer program. This, it seems, is their noble attempt to fixing Scrum’s lack of focus on technical training, which confuses me a little…since they’re still complaining.

2. Confusion over Scrum Over the last week, Mike Cottmeyer has been asking some good hard questions about what Scrum really is:

  • “How can you certify something that doesn’t have a standard body of knowledge around it?”Actually, the official statement of the Scrum method is spelled out in the Scrum Guide. The problem is that it’s too prescriptive, and the ‘experts’ aren’t very good at explaining what that means. For example, I’ve seen several hyper-performing teams that don’t have a burndown chart anywhere. The official body of knowledge would call them non-compliant ‘ScrumButs’, but I would say the burndown is optional. As long as you some kind of empirical visibility into whether they will make your deadlines, you’re okay. Further exacerbating the problem is the exam, which offers a few questions that focus on the letter of the law, rather than the spirit. So, as in any complex field, there are good ScrumMasters and bad ScrumMasters, good PMPs and bad PMPs, good doctors and bad doctors, good lawyers and bad lawyers. When you have a disparity among experts certified in a complex field of many grey areas, then the market is the ultimate decider of who’s got it together. There is a reason why Mike Cohn is the best-selling author on Scrum: his examples offer the pragmatic flexibility the market wants.
  • “How can you certify a developer, when there’s no developer role in Scrum?”. The Scrum Alliance already certifies more than just the official roles in the Scrum method (i.e. practitioner, trainer, coach). A developer certification will be the first introduction of a scrum application role. There is a LOT of dialog happening around the Agile BA, the Agile User Experience Designer, and the Agile Portfolio Manager. But there’s no formal agile method that calls those roles out either. Yes, the market is yearning for practical knowledge on application of agile thinking to specific job descriptions. I get a lot of questions from people asking how to apply scrum if they are a graphic artist, or a tech writer. But, that doesn’t mean Scrum is confused about what it is. Scrum is still the same at its core. I think it’s perfectly reasonable for the stewards of a methodology to offer maturity around how to apply it to a given skillset. imageWhat’s even more ironic about all this is the ongoing complaints. It used to be “Scrum is evil, because it leaves out technical practices.” Now it’s “Scrum is evil, because it wants to promote technical practices.” So which is it?
  • “Shouldn’t Scrum focus only the IT field?” - Software people grumble about the Scrum Alliance’s stated mission to “transform the world of work”. However, I believe we could have the most mature IT department in the world, but still have that IT department reporting into a broken corporate culture. We’re seeing high-quality software evolving the fundamentals of human communication and learning at break-neck speeds, but we still laugh nervously at the sit-coms depicting bad bosses. You mission is your mission. My mission is my mission. You want to create a new set of expectations around what it means to be a software engineer. I want to create a new set of expectations about what it means to be a manager or executive. Scrum fits my mission, and it doesn’t fit your mission, that’s okay. Just don’t tell me my mission is foolish.

3. Cults Recently, Scrum co-founder Ken Schwaber stepped away from his activities at the Scrum Alliance and launched the Scrum.org initiative to focus on the software industry. Yes, there was some disagreement and some hurt feelings about how things played out. Yes, there is some confusion as to the differences and similarities between the two organizations’ products. It’s messy and confusing, and Cory Foy spells out all the sordid drama. Many have been left feeling like they have to pick sides.


But that’s what creative destruction is all about. One guy does something first, the next guy does it better. Another guy holds true to a niche, and another branches out. Then, you have a little consolidation of players and a few products being abandoned, and eventually the landscape settles. Already, the Scrum Alliance points to Scrum.org as the authoritative definition of the Scrum method itself. Furthermore, Schwaber is being featured as a headliner at the upcoming Scrum Alliance Gathering in Orlando. So, some reconciliation and consolidation is happening already. Unfortunately, it’s human nature to gossip about the drama, but that won’t be the ultimate determination of what the market will choose.

That’s my take on things. The old understanding of Scrum is dead. It no longer fits nicely into a the box you want it to be confined to. Instead, there is a newer more mature understanding of Scrum evolving. The Product Owner committee, the skill-specific applications of Scrum, and the transfer of ownership from Ken Schwaber to a democratic community are all examples. Scrum is adapting to real world constraints, in order to become more relevant to the real world.

Scrum is dead. Long live Scrum.

[Read the comments below, and then read Part 2]

12 thoughts on “Scrum Is Dead. Long Live Scrum. [Part 1]

  1. Hi Jesse,

    There appear to be some misunderstandings around the dev certification which may be leading to confusion.

    The Scrum Alliance, unless something has changed, killed the Certified Scrum Developer program. The work that Jim Shore, Uncle Bob and others were involved in was an exploratory session – whose work was ignored and thrown out. The only current program addressing Scrum Developers is from Ken Schwaber.

    Second, the discussion around “World of Work” isn’t about making your managers better. It’s about applying Scrum to Lawyers, and Financial Analysts, and Music Producers, and Film Producers, and Marketers. Organizational change typically impacts many areas of the organization – I agree with that. But saying that the Scrum Alliance should be focusing on these areas is out-of-bounds to me.

    Finally, the blog post where I mention the “sordid details” is at http://blog.coryfoy.com/2010/02/they-could-have-been-contenders/ in case anyone wanted to see more information.

    My take on all of it, as I mention in the blog post, is that things need to change, and indeed, they may be changing. I’m holding out until after the gathering to see what things have been going on under the covers. It’s a shame I have to do that – weren’t we, as a Scrum Community, promised transparency just a few months ago? But, there it is. I’m hoping good changes come out of it – but only time will tell.

    • Thanks for the clarification, Cory. I’ve added your very cool link into the post. Here’s my question though, if the SA isn’t going to be the one to apply agile thinking to lawyers, financial analyssts, music producers, and managers, then who will? Are tech workers the only knowledge workers worthy of agile thinking?

  2. Pingback: ..but if the Scrum Alliance Can’t Do It, Who Will? - Cory Foy, LLC - Agile Training and Consulting - Enterprise Agility Redefined

  3. Jesse, This is really a nice post and thank you for the insights you brought in here. I do not complain over Scrum as a framework after practicing Scrum in Offshore project management for 5 -6 years now. But in this context, which is offshore project development I always had to have my own version of scrum, because Scrum as it is failed. As you quoted, I see many versions of Scrum coming out in the industry, but as much as we criticized Scrum we use it as a baseline for the methods we practice.
    Right now with all these offshore and scrum and some other Agile experience I have , Im in the process of creating a Offshore Project Management framework based on Scrum which is really interesting.. :)

    • Thushara, your chat about tailoring Scrum served as no small inspiration for this post. Too many people out there are literally afraid to color outside the lines, but not you. I continue to be impressed at what you and Exilesoft have done tailoring Scrum for offshore projects. I only wish there was more dialog about Agile project tailoring, rather than chatter about “that’s not Scrum”.

  4. Pingback: Scrum Is Dead. Long Live Scrum. [Part 2]

  5. Hi Jesse, I think there is some value in scrum or iterative / agile processes. Many of the problems with scrum and agile come from the manifesto’s description. Example, People and Interactions over processes and tools. What this has meant for many companies is move away from processes and tools to a more agile (ad hoc) process or lack of process. Somehow no process gives groups the ability to produce more? Workflows that show process steps are abandoned to show more simplified states like new item-> In Progress -> done.. with no real tracking and reporting on what is happening in the In Progress areas. Teams are allowed to collaborate and decide because they are empowered. Are they empowered to skip code reviews, perhaps skip the testing on this item and agree between developer and qa person that all is good or just whatever they do is correct?

    There are benefits to agile approaches like small units of work which leads to quick feedback on whether you are making progress. However, what happens if you are not making progress… how do you know where you are? Do you need another scrum meeting? Does the scrum master have to walk around asking for progress updates because the tools arent used that tracked progress through workflows?

    Scrum has some issues that need to be addressed before it becomes viable which should include processes and tools to help. It may help companies that had nothing before in terms of processes. However to many companies with good sdlc processes think they can achieve more with scrum and they fail. You cant always rely on the people and interactions over well defined processes and tools.

    • Lance, It turns out that Scrum has become very viable. Forrester last year found that 35% of all IT projects are using formal Agile techniques, and nearly all of those are using Scrum in some fashion. Individuals and interactions are the actual biological units of any organization. Processes and tools are merely there to *support* those interactions. I strongly agree that nobody can do business in the real world without processes (e.g. payroll) and tools (e.g. email). However, when those processes and tools become the ends, rather than the means, the project manager has failed. If you’ve worked on projects that are using only ad hoc processes, that’s not Agile. If your teams have abandoned proper process stages in favor those than can not trace or report on actual progress, that’s not Agile, and certainly not the empirical process control that Scrum espouses. I think that’s what this post is about: the debate is not between Scrum or XP, but rather between bad Agile and proper Agile.

      Thanks for your perspective,
      -jesse

  6. Thanks for your response Jesse,

    I have a group that wants to move more toward agile/scrum. The workflow they want to use is Open, In Progress, Resolved, Closed. The thought is it takes to much to define the “in progress” into other steps like (in development, in peer review, in test, etc) because these are waterfall approaches and the update of the item as it works its way through is to much churn. With this thought, we dont know of any of the details about where the item is during the in progress step. Is there a hold up in development, is there a problem in QA. So instead of using the issue tracking tools and having these process steps, they want to move toward this simpler approach. I am in favor of simplification but at this point its almost like all we need is a sticky note on a white board that shows the item name, who is assigned, how much work is required is all that all we need to do is move it from Open, In Progress, Resolved. You dont even need an issue tracking tool for this. For many groups Agile and Scrum mean less process and more ad hoc approaches. This is why the Agile Scrum scenario is slowly dying. Agile/scrum is not being used effectively and properly.

    Sorry for my ranting.

    • Lance, I can understand your frustration. Bad project management comes in many forms, including Agile. Some key questions would be: “Team, how are we doing with the lightweight task tracking? Are we delivering all of our committed features in the iteration? If so, then we don’t have too much of problem. However, if we have difficulty delivering, then we need to ask why that is”. Since the answer is almost always related to communication, the next question would be “team, how do we improve communication and coordination? I have some process suggestions, which one should we experiment with first? Oh, and BTW, we are not going to do the same thing as before, because you agreed that did not work”. Just because we want to encourage self-organization, does not mean the team is permitted to be undisciplined. You have to coach them in the direction of the right level of tracking the right things.

      Feel free to contact me offline to chat in more detail: email (at) jessefewell.com

Leave a Reply

Fill in your details below or click an icon to log in:

Gravatar
WordPress.com Logo

Please log in to WordPress.com to post a comment to your blog.

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Connecting to %s