Awhile back, I got into a rather heated discussion with someone who was a firm believer in “textbook Scrum” and insisted that because the Product Owner is part of the Scrum Team (according to the biblical Scrum Guide) that they simply must be involved in every retrospective with the team, no matter what.  This discussion reminded me of the trap that many people fall into when they shift from traditional, structured, waterfall or stage/gate approaches into Agile development practices — they assume that there’s one process to rule them all, one way to do things, and anyone who does anything different is a heretic and deserves to be burned at the stake for even suggesting that sometimes it might be better for the team as a whole if the Product Owner isn’t invited to a particular retrospective.

Now, don’t get me wrong — I think that Product Owners, in general, should be very involved with every aspect of their teams’ work — from stand-ups to demos to retros, and everything else in between.  I think that the standard practice should be that the Product Owner is invited to the retrospective as an observer and occasional active participant.  But I do not believe that anything in the Scrum Guide or any other alleged “definition” of the right way to do things should be followed to the detriment of the teams’ success and improvement.

Dogmatic application of any standard process is inherently anti-Agile, for the following reasons…

Individuals and Interactions First!

The very first value statement in the Agile Manifesto tells us why this is — if we really are “Agile” then we are supposed to value “Individuals and Interactions over Processes and Tools.”  How does a dogmatic application of some specific view of a particular methodology supports this value statement?  The answer, quite simply, is that it doesn’t.  Sure, it makes us feel good to tell someone the “right” way to do something, and it makes some companies a hell of a lot of money in their consulting services to come in and tell you how it’s “supposed” to be done.  But the simple fact is that, if we really do value individuals and interactions over processes and tools, then we should dogmatically reject any process, procedure, tool, or consultant who comes in and tells us that there is some “right” or “wrong” way of doing things — unless they assess the impact on the teams first.

Now, this isn’t to say that the Scum Guide itself is inherently “wrong” — that would be rather hypocritical of me, given the prior paragraph, now wouldn’t it? — but rather that the principles and process described in the Scrum Guide, or in any prescriptive description of any methodology, should be viewed as a suggestion or a recommendation, or at worst a starting point from which you can learn and build and adapt your own successful ways of working.

You Have to Start Somewhere

There is certainly value to be had in looking to prescriptive definitions like those found in the Scrum Guide — they provide us all with a common understanding of the component parts of what that particular publisher or consultancy has defined as “Scrum”.  It enables us to have intelligent conversations using such jargon words as Product Manager, Scrum Master, Stand Up, Retrospective, and other terms that have only contextual meaning within the world of Scrum.  It also provides those who need guidance and assistance in establishing the foundation for Agile practices with some clearly-defined, specifically-actionable, and proven steps to take and ceremonies to implement to achieve their goals.

These are absolutely noble reasons for the existence of Agile consultancies, training programs, and books that offer prescriptive solutions without context of the business or the teams.  After all, you have to start somewhere and without these prescriptive tools and resources, every single team who wanted to move to Agile practices would have to reinvent the wheel.

Once You’ve Started, Adapt and Adjust

But there is a large risk associated with these prescriptive and proscriptive definitions of what “Scrum” is and what it isn’t — we see blog posts, Tweets, and other discussions every day that demean those who would do “Scrumbut” because it’s “not Scrum.”  Now, many “Scrumbut” behaviors are also remnants of old behaviors and reflect Agile anti-patterns — but they should be demeaned because they conflict with Agile principles and not merely because they conflict with some definition of Scrum.

The simple fact is, if we opening adopt the values of the Agile Manifesto, we’re required to discard and prescription or proscription of process, tools, or interactions if they wind up getting in the way of success.

• If having the Product Owner at the retrospectives is disruptive, or causes team members to shy away from being open and honest, then the Product Owner shouldn’t be there.
• If the teams are co-located and setting up a single demo/review meeting so that each team member shows off what they did is difficult, then it’s not the end of the world to have the Scrum Master or even the Product Owner present the results of the sprint to the stakeholders.
• If your team is distributed around the world such that there’s literally no time that works for a daily standup meeting, then do it over email or use any of the number of online tools to coordinate status reports.

The entire point of being Agile is that we are able to and willing to respond to change — not just change in the market, and not just change in the requirements, but changes in the process that we use.  Adhering to some dogmatic worldview about what is “right” and “wrong” with your processes simply gets in the way of our primary goal — delivering quality software frequently in incremental fashion.

If you’re following Scrum just to follow Scrum, then you’re missing the entire point of Agile development.