Sometimes Twitter is just a bunch of crap and noise. Other times, stuff comes over that you just can’t ignore. After we published the State of Agile report, I had one of those moments. It hit me after one dude tweeted something to the effect of: “How in the world can a team claim to be doing Scrum if they don’t practice retrospectives?” I couldn’t let this one go. I polled our staff of professional agile coaches. Within an hour, 6 of them had opinions on whether you can proudly call your team “Scrum” or even “Agile” without conducting regular continuous improvement procedures. Here I’d like to share with you some of our coaches’ opinions and recommendations – then find out your take. (ADHD moment: If you are new to agile or wondering ‘what is a retrospective?’ here’s a good explanation). Take this as FREE advice from our professional coaches. Normally you pay for this stuff so IF you enjoy it, you at least owe me a LinkedIn share or tweet @VersionOne.



WHAT THE VERSIONONE COACHES SAY… “You can’t be ‘Scrum’ if you aren’t doing all of the practices of Scrum.” – Steve Ropa True. But I give this statement a big “So what?” Isn’t the goal of agility to create great software? If some part of Scrum doesn’t work for your team, should you do it anyway just so you can be Scrum?  In the words of John Pinette, I give this a “nay nay.” I recommend doing all of the practices to start with – and only removing or modifying practices when you find them to be unnecessary or even detrimental.

Ironically, teams usually come to that conclusion during the retrospective. You can be agile without retrospectives, but it’s a very, very rare team who can. I have run into a few. They’ve usually been doing XP for a while, and are always co-located.  Some teams did the retrospective because they were supposed to, but never really came up with anything new.  What they were able to do was to inspect and adapt at the drop of a hat. These teams also found that daily standups had become redundant.

“It’s the wrong question to begin with.” – Lowell Lindstrom

The question of whether or not a team can be “Scrum” is a red herring for a few reasons. First, due to the inherent inspect-and-adapt nature of Scrum, over time, no two teams will be identical and any given team may evolve in a way that makes one of the common or defined parts of the Scrum framework suboptimal. The classic example of this is task articulation and estimation in Sprint Planning, which many agile teams find is not necessary as they improve.

Second, there is no one person who can designate whether or not a team is Scrum, leaving any assessment to the discretion of the assessor. Across experts in the various Scrum communities there is a little consensus. This is due largely to the first point, i.e., the fact that each person’s opinions will be shaped by their experiences. And these are inevitably different. It’s worth noting that the original definition of Scrum didn’t even include retrospectives.

The patterns and papers from the mid-’90s, and Ken Schwaber’s first book on Scrum (2001) make no mention of retros. The focus was on the product with the Sprint Review at the end of each Sprint, but no explicit reference to the team’s PDCA. Similarly, the original definition of Extreme Programming (XP) did not include retrospectives. In 1999/2000 as XP was gaining in popularity, Norm Kerth was writing his book Project Retrospectives: A Handbook for Team Reviews.  Although focused on larger, longer projects and the difficulty of learning what really happened, the ideas resonated strongly with the XP community and we soon saw the practice added to the XP list. The Scrum community followed suit and in Ken’s next book on Scrum (2005), we see retrospectives become part of the framework as we know it today.

So, were teams doing Scrum from 1993-2005 not considered ‘Scrum teams’ because they didn’t do retrospectives? Of course they were; it’s a silly question. What we can say is that the Scrum community and its leaders have found that the most hyper-performing teams reflect on their practices with a tenacious attitude toward improving the way they develop. Most do this through the construct of the retrospective. However, doing retrospectives well is difficult and depends on a culture that values learning.

So, if my retrospectives suck and yield no improvement, then am I really any closer to being Scrum than if I do not do them at all?  I would argue: No.  Is a team who uses most of the Scrum framework but not retrospectives, integrating PDCA into their daily work as the Kanban community advocates, still a Scrum team?  I would argue: Yes. Any discussion centered on “being” Scrum or “doing” Scrum should explore whether a practice improves a team’s performance, the different scenarios and conditions required for a practice to thrive, and the substitutes that might make a practice replaceable.

“Retro is a key ceremony. You cannot be ‘true’ Scrum unless you follow the framework as it was designed.” — Jo Hollen

You can, however, be “ScrumBut”… and realize some value from your partial Scrum efforts. Going back to agile and Lean principles, the notion of continuous improvement is very foundational. Without retrospectives, I would be concerned about how the culture is addressing the principle of continuous improvement. Do such organizations have other methods through which they can incorporate team feedback and address improvement?

Maybe the more interesting examination is why do they NOT want to do a “retrospective” – or not think they need to?  I’ve seen where they were done as part of the process, but often I felt they were not very effective in many teams.

First, it must feel totally safe to bring up something that is not going well. Many cultures still want to immediately find a person to blame for the “problem.” If anyone feels unsafe, the retrospective will be superficial. Nothing useful will come from it, and the team will quickly find the retro a waste of time. Even if a team gets to the point of bringing up real issues, there must be a spirit of appreciation for the input – then real results and follow-through. If nothing ever comes of the feedback, it will quickly stop. Besides, if results are not implemented, then there is no improvement anyway (thus, another waste of time).

Or maybe the team feels that everything is fine. REALLY??? Nothing can be improved? (Maybe you should hire them for coaches then). Even the highest-performing teams will find things that can be improved. But, maybe every two weeks feels too often? Maybe they should do a health-check/status and a deep-dive examination every few sprints. Agile requires some form of engagement and commitment to continuous improvement.

“You can’t be ‘Scrum’ without the ‘Scrum’ ceremonies.” – John Krewson

You can be agile without the ceremonies so long as you’re adhering to the principles, but “Scrum” asserts certain ceremonies as part of the framework. Those ceremonies, retrospectives included, are intended to uphold the theory of empirical process control upon which Scrum was built. I refer to retrospectives as the “missing agile value” and have a blog post coming out soon to address this.

“Learning always precedes agile maturity.”  — Brian Irwin

As you’ll see in John’s blog post, from an organizational perspective, learning always precedes agile maturity. I’m also planning a blog post specifically about expanding retrospectives past the team level and embracing them at all levels in the organization, including (or especially) at the upper-management level.

To me, one of the most critical aspects of agility is learning; i.e., at regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Maximizing learning is also a key Lean concept. I think people tend to get so hung up on processes and how to do things that they forget why they’re doing them in the first place.  But to answer the question directly, if you’re not doing retrospectives not only are you not doing Scrum—you’re not really agile if you aren’t making time for learning. Teams typically stop doing retrospectives because they’re difficult. Once you’ve addressed the low-hanging fruit, it gets complex to address the real hard stuff (people issues, organizational dysfunction, etc.).

“Not doing retrospectives suggests the plan must be perfect.” — Michael Moore

I would say that this is not specific to Scrum so much as it’s one of the principles of agile to inspect and then adjust/tune.  This principle goes beyond agile even; I’m not sure I’ve seen any good improvement method that doesn’t include some sort of periodic reflection and adjustment, whether it be self-improvement or organizational. Not doing retrospectives suggests that there is no need for adjustment, which means that the team and plan must be perfect.  If they aren’t, however, this activity is essential to maximizing effectiveness. Of all the principles, this is the first that should be implemented, regardless of the method. From this principle, all other principles and practices are discoverable.

WHAT’S YOUR OPINION?  Can a team be Scrum or Agile without retrospectives? Join the debate by leaving a comment below. Better yet, subscribe to this blog; several articles addressing this topic are on deck from our coaches in the upcoming Agile Chronicles. We’d like to hear from you!

Join the Discussion

    • Peter Saddington (@agilescout)

      “Being Scrum” is much different than “DOing Scrum.”
      “Being Scrum” is a highly contextual idea, relative to how you “feel” or how you’ve “attached yourself” to the framework.

      “DOing Scrum” is far superior in my opinion.
      Scrum allows us to quickly execute. Regardless of your market. Services, products, software development. Don’t mattah.

      For us, we’d much rather practice Scrum… or practice (read: execute) on good frameworks, methods, techniques. Call it what you may… DOING is what the intent of Scrum was all about.

      • Pablo Osorio da Silva

        Although I agree with your point, I would express it exactly in the opposite way:

        It’s easy to DO Scrum, following some practices, having “post-its in the walls” and making some standup meetings. More difficult is to BE scrum, thinking in Scrum, feeling like Scrum, so whatever are your practices, it will fit perfectly to Scrum objectives! 😉

    • Bryan Merrill

      The Scrum Retrospective is one of the regular ways that the team learns to be self-organizing and practice team analysis. The absence of retrospectives at the end of each sprint means that the team is missing a regular opportunity to improve themselves and their productivity. Building great process is as important as building great product.

    • Ben Linders

      Agile Retrospectives help teams to reflect on their ways of working, and to continuously become better in what they do. Teams use retrospective meetings to “inspect” how the iteration (sprint) has been done, and decide what and how they want to “adapt” their processes to improve. The actions coming out of a retrospective are communicated and done in the next iteration. That makes retrospectives an effective way to do short cycled improvement.

      As teams become more mature they often discover multiple ways to improve then by only doing retrospectives. Actions may be decided and agreed upon during a stand-up or coffee break. Improvement ideas can be put on the task board by any team member at any time. They may adopt Kanban to manage their workflow and continuously find ways to improve themselves.

      High mature teams will still do retrospectives, but they will only do them when they provide value for the team. They will have a toolbox of different techniques and exercises that they can use in retrospectives, depending on the situation at hand and the current team needs.

      Co-author Getting Value out of Agile Retrospectives

    • David Babicz

      Can you be Scrum without retrospectives?
      No. You can not. They are just a rule of scrum per the scrum guide.
      That would be like asking if you can play real golf without using a golf club. You can play SOME sort of game that looks like golf that way, but it wouldn’t be golf, because that’s just a rule of the game of golf.
      Now, can you be Agile without retrospectives? Certainly. And that’s the difference. Agile is a culture and mindset, backed up by values and principles that don’t prescribe particular practices or methods.
      The only nod to retrospective in the manifesto – values OR principles – that I find is “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.” That could be a retrospective, or some other thing.

    • Matt Badgley

      It’s a fascinating question and series of responses. I say that because, I believe most people that have been fortunate to find and see value of retrospectives, well — we think they are very important. That said, I’ve seen teams that make the topic or discussion of, “hey this doesn’t smell right, is there something we should do?” A part of their daily activities, it’s what we want to see as coaches and as fellow team members — people seeing challenges and dealing with them.

      That said, I agree with what Jo talks about with respect to the fear of recognizing problems. There’s also the challenge that some folks have, including myself, in that they just are good at articulating their frustrations or observations — it just comes out as whining or emotions.

      Retrospectives provide a structure for which teams can work together in a constructive manner to identify opportunities to improve. Ben Linder’s book mentioned above is really good, as is Esther Derby’s and Diana Larson’s book on retrospectives. Other great resources are and I mention all this because there’s a ton of great resources and knowledge to help teams do retrospectives.

      I guess I didn’t answer the question, I’m kinda mushy like that. I think if teams are going to give Scrum a go, then they need to leverage the framework as it stands today adapt as they mature.

      It is a good question and the dogmatic and pragmatic responses are what makes the Agile community rich. We are always challenging each other to make it better. This is a great retro Andi, thanks for posting.

    • Jeff Sutherland

      The first Scrum team at Easel in 1993 aggressively removed impediments in the daily meeting (mini-retrospective) and addressed process questions in the sprint review (why did our demo suck?). This team was benchmarked at 10 times average waterfall performance and set the standard for Scrum teams in all my companies from 1995 when I left that team until today at Scrum Inc.. Ken and I framed Scrum based on this team. We have added emphasis to areas where teams tend to underperform and have broken out the retrospective as a separate meeting from the sprint review. We did not include the engineering practices adopted by this first team which where XP plus some sophisticated testing practices based on object-oriented component design and strategies for emergent architecture based on evolutionary theory. These latter Ken felt were too sophisticated for most software teams as they were based on chip design. However, some of the Google guys have figured out that extreme performance is based on these techniques. Wikispeed uses these approaches to build cars in one week sprints.

    • WKSH

      Hi there,

      if I would allow a team, that doesn’t want to do a retrospective, I would leave the path of scrum, as the retrospective is a key element. The team could still be effective and reach its’ goals and still be agile.

      So if this was a question in a test, what would be the correct answer?

      Best regards,

    • Andrea Keeble

      WKSH, I think if this was a test, the answer would be yes. A scrum team can and should choose the combination ceremonies that work best for them — whether that is scrum, kanban, lean, XP. Many teams borrow practices from several different methodologies… The advice would be to use the pieces that work for your unique processes and ditch what does not.

    • WKSH

      Thank you Andrea,

      is that ‘YES’ a dogmatic scrum answer?

      Because if they would decide to not practice the other scrum meetings eiter, the srum process would come to an end.

      So ,I am pretty confused.


      • Andrea Keeble

        No, the point is, there is no one right or wrong way to practice scrum. The most successful teams experiment with different ceremonies, inspect and adapt regularly. With each sprint you get better and better. If none of the scrum ceremonies work, then yes, maybe experiment with a different approach. I’d recommend some coaching guidance for your team. It has to work for you, not just do it for the sake of doing it. One of our coaches on this thread may also chime in.

        • Khalee


          That’s like saying there is no one right way to play basketball. Our team decided that we are going to take 3 steps between dribbling. It works better for our team. If no Scrum ceremonies work for a set of individuals then don’t call it Scrum… bottom line.

          I once worked at Eckerd, back when it existed. My boss said, “The Plan is A, B, C and D.” “Well, what if we don’t do C?” “Then, it won’t be a plan.” “Good point. I never thought of that.”

          It IS NOT Scrum if you aren’t performing Scrum’s MANDATORY ceremonies. It would be different if Retro was optional, but alas, it isn’t. There’s PURE Scrum, and some hybrid approach that most companies use, depending on where you are. The ScrumMaster’s job is to coach the best possible agile practices, while being flexible at the same time. You can be flexible with some things, others you cannot.

          • Andrea Keeble

            Hi Khalee, Good points. Thx for your comments. While I do agree, teams should follow the scrum ceremonies, not everything will work for everyone. On my team we make adjustments to our ceremonies every 2 weeks. We have adjusted the way in which we do daily scrums at least a dozen times in the last year. In retro, we brainstorm a few things that could go better and as a team we vote on 1 thing we call our “Kaizen thing” to work on for that next sprint. It has been working well. I think it really depends on the team, size of team (or teams), etc. as to how much flexibility there is. If everyone agrees to adapt, why not?

    • Jeff Sutherland

      Scrum derives from the Toyota Production System, specifically Lean Product Development which is based on two pillars, the focus on people and continuous improvement. This allowed Toyota to get four times the productivity and 12 times the quality of General Motors and force them into backruptcy. This is what Scrum is designed for. So if teams do not want to continuously improve why don’t they just stick to waterfall. It would be easier not to change at all.

      I see many teams that are flatlined, not improving at all. Then the question is, why have a Scrum Master or an Agile Coach. It is just extra overhead and from a management point of view a waste of money. Then we might as well dump the daily meeting. We could even do Kanban without a team, only siloed specialists, and claim we were Agile.

      The problem is when Scrum goes south as it did after I left one company as CTO, the revenue immediately declined from $50M to $25M and flatlined for the next five years. Smart management should probably bail out with the Scrum Masters and go find an Agile company.

    • John Krewson

      It seems that the community has overloaded the definition of Scrum. There’s “Scrum”, the set of “prescribed events” and artifacts set forth by the Scrum Guide, developed by Jeff (^) and Ken Schwaber. Then there’s “Scrum”, a similar framework described in the Agile Atlas, and then there’s “Scrum”, a mindset that relies on transparency, inspection, and adaptation. This third definition is (mostly) synonymous with Agile. So it’s a trick question: Can a team be Scrum without retrospectives? We’re all answering the question based on the definition we’re adopting at the time.

      In other words, the egg came first.

      • Steve Ropa

        @John, I disagree completely. It was the chicken that came first. Then the pigs told him to be quiet and listen.

        Actually, I agree very much with you point that we are all looking at Scrum through a different lens.

        @Jeff, if feels like there are two possible scenarios here. One is where management chooses to get rid of the retrospective because they see it as unnecessary overhead. I would fight that one tooth and nail. But if the team felt that they had reached the Gold Standard that your original team met, where they were inspecting and adapting at each daily meeting, so they decided that the retro wasn’t really doing anything they weren’t already doing, they would be well served to choose to drop the retro. To me the challenge remains whether they are dropping the retro because they aren’t acting on what comes out of it, so they feel it is “useless” or is it unnecessary because they have found other ways to “reflect on how to become more effective, then tune and adjust their behavior accordingly.”

    8 + = 10