I’ve heard several references recently to the Scrum Canon. I went searching and I’ve not been able to find it. Is it one Ken (et al.) three books? Ken and Jeff’s most recent Scrum Guide? Does it include the ideas that Mike documented in Agile Planning and Estimation? … Is what the majority of CST’s are teaching at this moment in time? In end I don’t think there is a Canon and its absence doesn’t matter. We can all agree on the basics: three roles (PO, Scrum Master and Team Member), Four meetings (Planning, Daily Standup, Demo, Retrospective) and three artefacts (Product Backlog, Sprint Backlog, Burndown Chart). Beyond that is the art of what makes a team truly successful Scrum Practice (in no particular order):
- User Stories
- Planning Poker
- Release Planning
- Engineering Practices
- Cross Training
- ….even approaches to Scaling
I teach about all of these in my CSM courses, but none of these is core to Scrum. None is required. Why not? Scrum is incomplete it gives you enough information to get started and says you should improve from there. Its not a straight jacket and it welcomes other ideas/practices. I get concerned when people seek a complete methodology as they discourage diversity, outside thought and even thinking for yourself. So practice Scrum but don’t assume it or any other toolbox has all the answers. Sample from the buffet.
Mark Levison has been helping Scrum teams and organizations with Agile, Scrum and Kanban style approaches since 2001. From certified scrum master training to custom Agile courses, he has helped well over 8,000 individuals, earning him respect and top rated reviews as one of the pioneers within the industry, as well as a raft of certifications from the ScrumAlliance. Mark has been a speaker at various Agile Conferences for more than 20 years, and is a published Scrum author with eBooks as well as articles on InfoQ.com, ScrumAlliance.org an AgileAlliance.org.
Mark… I would suggest that the canon of Scrum is Ken and Jeff’ Scrum guide. Several have written things that augment Scrum, that’s fine… that’s not the kind of stuff that I would expect to be in a body of knowledge. As you mention… that stuff is not required to do Scrum.
You asserted that we all agree on the three roles, the three artifacts, and the three ceremonies. At the Scrum team level yes (5-9 people)… I would agree, but still reserve the right to bend or change even these. The problem with Scrum is not at the team level. It’s at the enterprise.
The three roles, three artifacts, and three ceremonies are woefully insufficient to do agile at scale. The Scrum answer to scaling? A scrum of scrums? That is not sufficient either.
We say that Scrum scales… but my opinion is that it only scales in very specific types of organizations… ones that organized in a way to support the rules of Scrum. Most organizations are not organized this way. In most organizations the value stream goes far beyond the single scrum team.
Significant transformation is required… not just at the team level… at the org structure level… for the PMO… for senior leadership… for the strategy group… for marketing… for sales… for HR… not to mention the individuals on the team that don’t currently have the skills or desire to become specializing generalists.
Here’s the challenge… we say that Scrum scales, but most people but aren’t fully aware the level of change that will have to take place across the organization to make it sustainable. They try Scrum and it fails, and they blame Scrum. It’s not Scrum’s fault… but in our zeal to evangelize Scrum… I think we have generally overstated it’s applicability.
A two day course, while valuable, does not prepare you for this. Not yours, not mine.
What I would like to see added to the canon of Scrum is context and domain applicability. Are we talking about a Scrum team in a large enterprise, or an organization that is going for end to end agility? I think it is irresponsible to say that Scrum scales without establishing context. I think it is irresponsible to say that Scrum scales without giving guidance on the kinds of additional information you might need to really make it work.
I guarantee you’ll need more than three roles, three artifacts, and three ceremonies. That was the point of my tweet that you commented on 😉
Thanks for the post. See you in Salt Lake?
Mike
Mike – We’re in broad agreement, a 2 day course hints at the basics of doing Scrum well at the team level. Scaling is an art form and each artist advises something slightly different. At this stage Scaling isn’t well enough codified to be part of any canon (Scrum, Lean, Kanban, …). We know that we need more than the basics of Scrum. Maybe in 4-5 yrs it will be clear what the successful patterns were. My original reaction was to your comment about the “Scrum Canon” (which I hope never exists).
There is lots of good ideas on how to scale Scrum and some it even comes from the usual suspects.
Back to revising our creativity presentation and paper for Salt Lake City.
Cheers
Mark
I never said a canon couldn’t evolve 😉
But anyway… I have recently come in behind two struggling Scrum implementations with clients that have been beating their heads against the wall to apply the 3x3x3 formula. Putting in some simple, non-Scrum, scaling constructs has helped them be more successful.
I don’t think anyone did it on purpose… but we somehow gave a lot of people the idea that this team based method scales out of the box… and now you know my opinion on that. Most Scrum folks I know are extremely dogmatic on the 3x3x3 and I think that can be harmful…
I attended a talk by Ken at Agile 2007 that point blank made the typical 3x3x3 SoS scaling argument. I just think that is really bad advice… I wouldn’t want to be held to things I said 5 years ago… but at the same time, so many people hold onto the this scaling pattern, I find it very frustrating.
I find it sad that people require a canon, or assume there must be one for Scrum to have validity. Maybe Mark is right, and there isn’t one. How freeing that is!
As I see it, Scrum is even less than Mark outlines here (e.g. burndown charts are unnecessary). I wrote something called Simple Scrum a couple of years back: https://agileanarchy.wordpress.com/2009/09/20/simple-scrum/ which is intended to capture the spirit, or essence of Scrum, focussing on framework and principles over dogma, and viewing Scrum as an abstract class that can be implemented in any context.
When I teach Scrum, I don’t talk about such things as planning poker, release planning, etc. as I don’t believe they are relevant to the Scrum mindset. In a two-day class I believe it is more important for people to understand the Why of Scrum. The rest will follow. But without the mindshift all the practices will likely be superficial, and will be discarded when the going gets tough.
To Mike, I think you are approaching Scrum with the mind of a project manager, and I don’t think it helps. Scrum is NOT some new form of “managing”. It is an entirely new approach to work based on the principle of self-organization. When people struggle to “scale Scrum” it is because they fail to understand that principle. Self organization does not work when consultants, coaches and managers try to take charge. I wrote about team-led scaling here: https://agilethinking.net/blog/2008/04/09/scaling-scrum-the-alcoholic-perspective/ I still stand by the basic principle outlined in that article: Trust and Let Go.
And, rather than looking at the “3x3x3” thing as dogma, it can be thought of in a more values-and-principles fashion as:
Roles: Why, What and How
Meetings: Frequent, regular and appropriate conversations for the context
Artifacts: A way to visualize requests and work in progress
Free your thinking, and forget canon, dogma, rules and ScrumBOKs. Focus on the Scrum framework and principles. This will still be Scrum. Better, it may be effective Scrum.
My biases are with Toby.
Make it work if it’s important to. Fail if you want. It’s up to management whether they care enough.
The market will sort things out over time.
On the other hand, as individuals hired to address point problems we do our best to be pragmatic. and via agile values doesn’t that mean we can roll out change incrementally? its just a discussion with the client about urgency and importance.
To some Project Managers, Scrum is neither simple nor complete. It is also perceived as non-consistent (I know because I get to talk to many Project Managers through PM Hut).
The thing is, many Project Managers want an authoritative website explaining the role of each Scrum member, how Scrum works, and how to manage a project through Scrum. Mostly all what is written on Scrum is written on blog posts by people who practice Scrum (who may or may not have the same view on Scrum).
PS: I have published an article on Scrum a couple of days ago, the 4 questions that should be asked by a ScrumMaster, I hope you’ll have the chance to read it (and maybe comment on it).
There is no authoritative definition of Scrum (not even the Scrum guide). Scrum is meant to be incomplete that’s the whole point. Its a framework for getting started on improvement but the framework alone doesn’t solve any of your problems. It just a simple tool to help you discover your problems. How you solve the problems is up to you. For instance most teams want to go faster with higher quality. In that context I find TDD a useful tool, etc. There are other tools for other contexts (hence my ScrumMaster tales series), but not all the tools are applicable in every context.
Cheers
Mark
Well, I know a couple of project managers that do not want to lose control over the work and the people. As Scrum teams are self-organizing and cross-functional, the pm’s feel that they will not have to do anything anymore after having set up a Scrum team…
I’m comparing Scrum with a picture frame and canvas – it defines the borders of the picture, but it let’s you complete freedom to paint an abstract, surreal, cubistic or whatever picture – but it’s important that you paint the picture.
However, there are – from my experience – some “must have’s” of Scrum: The backlog, the sprint board, the difference between user story (what) and task (how), the rhythm, the role specifications, the self-responsible work which is not controlled from outside, the self-reflection on product and process. These are – for me – the crucial success factors that lead to a non-overspecified product, a motivated team, a continuous improvement.
Hardy – These PM’s maybe in for a surprise – control was an illusion and all the planning in the world won’t allow you to plan for what really happens in a project.
Aside from User Stories which are useful, but not required we largely agree on your list. Instead of User Stories think focus on building small vertical slices of an application. User Stories are just one example of that.
What I like about the rest of your list is it focuses on principles out of which the practices follow.
Well played.