ScrumMaster Manifesto?

So a ScrumMaster Manifesto has come out. The details of it are below:


  1. Dedicated Delivery Improver
  2. Foster Continuous Improvement
  3. Help Continuous Improvement
  4. Empower Coach Deliver
  5. Nurtures The Team
  6. Transparent Team Helper
  7. Commitment To Excellence
  8. Empathetic Evangelistic Guide
  9. Resistant Persistent Dedicated
  10. Help The Team
  11. Awareness Then Improvement
  12. Agile Driving Force

Top 10 things a ScrumMaster usually forgets to focus on (but is not SOLELY responsible for)

  1. Redefining career paths and goals to be more scrum focussed
  2. Missing Product Backlog items
  3. Team issues aren’t being discussed because they are too uncomfortable
  4. Appropriate balance between end-to-end system test and unit tests
  5. Playing back the team’s progress against the proposed release plan
  6. All tests roll up into the continuous integration results
  7. Team members realize the benefits of refactoring
  8. Code is regularly peer reviewed
  9. Pair programming is being utilized
  10. Definition of done is being expanded
Seems pretty solid… what I find interesting are the following about this ‘manifesto.’
  • No ability to comment on the site
  • Doesn’t seem open to the community for edits. How can we continuously improve it?
  • How often does it get updated?
Seems like a good place to start for ScrumMasters.

32 Replies to “ScrumMaster Manifesto?”

  1. Seems like the definition of waste to me, and yet another reason to avoid scrum.

    The fact that it’s closed for edits seems pretty typical for that community….


  2. I had the privilege of collaborating with many other practising SM’s in the creation of this Manifesto.

    It was the outcome of an exercise run at the Scrum Gathering London 2011 by Paul Goddard. I beleive it’s been added to/grown/expanded/altered by it’s creator and the community since then.

    It’s my understanding that it’ll continue to evolve over time.

    Here is the bit from the bottom of the page you didn’t include

    “First created at the Scrum Alliance Global Gathering London, 11-13 October 2011

    This manifesto has been created by ScrumMasters to help other ScrumMasters become better ScrumMasters. Please share this with those who you feel would benefit from reading it. For the latest updates to this guide based on empirical feedback from the practising community, and to show your support, follow @ScrumMasters on Twitter.”

      1. The session I was was in was a series of games, some of them commonly used by SM’s to help PO’s create and structure backlogs, to generate thoughts and idea and eventually the group came to consensus on the original version.

        This was the original version, since then I believe others have evolved it in a similar matter.

        It’s certainly not a locked down artifact and I think it’s a marvellous conversation starter for SM’s and highly useful for those looking to understand what we do.

        1. How would a full time scrum master be different from a full time project manager that knew how to do their job correctly?

          I’m curious….also do you see having both on the team or just one or the other?


          1. Most PMP’s are usually too occupied kissing _ss usually to do what would be classified as “their job correctly”. How long HAVE you been at this ? Geeze.

  3. @Jordan

    This came from the SM community, a group of self organising individuals that helped to create something that might help to inform those that wished to understand.

    It’s a shame you’re so dismissive of Scrum and the manifesto, what are the experiences you’ve had that have led you to that opinion I wonder?

    1. Don’t you mean ‘self-agrandizing’? What is your mail-order diploma worth exactly in the real world. Not much!

      Please, leave software development to the pros with real education and experience.

  4. Hi Peter,

    As James says, my idea behind this artefact was from research which backed up my concern that lots of new ScrumMaster were compromising the role (and thus compromising their teams chances of getting the most from Scrum) either through mis-understanding of the role or a lack of investment in the role.

    As this was only born a few months ago, I am completely open to moving it to a site format which is more open for comment – with the intent being that it’s not static, it will change as the community decides it should. London 2011 was a starting point for it, and I created a site in the simplest way possible for me at the time.

    If you can direct me to a simple way to open it to comment, I’m all ears (as I’m not up to speed with the sites that allow that).

    1. Since anyone with budgeting authority would ask, and Scrimshire didn’t answer can you answer:

      How would a full time scrum master be different from a full time project manager that knew how to do their job correctly?

      Do you see having both on the team or just one or the other?


      1. >How would a full time scrum master be different from a full time project manager that knew >how to do their job correctly?

        Project managers are charged with managing a project, rather than facilitating people. The job role of “project manager” encourages a sense of sole responsibility, and removing risk from both customers and delivery teams which is the exact opposite of what a ScrumMaster should be doing.

        >Do you see having both on the team or just one or the other?

        I have never seen a Scrum team get anyway near self-organisation whilst a project manager was still on the team. If Scrum was really thriving i.e. the customer was working together with the team on a daily basis, there would be no need for a project manager.

        1. BTW the reason I said “thanks for sharing your opinion” is so that it’s clear that those are your opinions, even though you state them as facts.

          Maybe you just have never worked with a good manager?

          Ultimately I find this very self serving; a Group of Scrum Masters, who have a vested interest, get together, and create a “manifesto” that says Scrum Masters should be full time!


          What’s next, a Maid Manifesto, where all the housemaids say that should be a full time job too? After all there is so much to do, dusting, sweeping, eradicating dysfunction….

          While on the subject, I doubt coding is something your full time scrum masters would be doing, so they’re really not part of the team anymore, there just mickey mouse managers but without the skillset.

          I’ve noticed that the tone of scrum masters almost always comes across as preachy, sanctimonious or condescending. I pity folks who have to work with a scrum master like that, or a manger like that.

          Do they teach that oratorial style at Scrum Master school, or does it just naturally attract people with those traits?

          So much to ponder,

          1. I find it quite amusing that you replied to your own reply, purely to provoke a destructive argument. Sorry, I’m going rise above that.

  5. My apologies to Paul, James and to you Peter. I appreciate that you posted this Peter, I think it’s VERY useful. Thank you Paul for putting the effort into having it take shape. And James, thanks for clearing up the record straight about it’s provenance.

    But really, for someone who says I should “stop astroturfing” because I’ve called out their points as indefensible, it should be fairly obvious that one of their aims is trolling, and not reasonable discussion.

  6. Pingback: ScrumMaster Manifesto? | Agile | Syngu
  7. Unfortunately this article focused primarily on 1/3 of the SM’s job. They have a service to the Product Owner and service to the Organization that also deserve two separate articles.

        1. Could that be said of the Agile manifesto? Would such a change have had such traction without it? Would we be writing this blog without it?

          I agree they are not the bible. It wasnt intended to be, just as a reference point to for stumbling or inexperienced ScrumMasters (of which there are many from my experience)

          1. And that’s fine. I have no problem with it being a wayfinding device.

            When we started the whole kanban thing, David and I discussed ‘Do we need a kanban manifesto’. We arrived at the answer ‘No’ because it would have just added to the feeling that kanban somehow competed with Agile.

            The danger I see here, Paul, is that there are many who don’t understand the differences between Agile and Scrum. The ScrumMaster manifesto will do one of two things (or both):

            1. Give people the idea that Scrum has now superceded Agile


            2. Further cement the best practices in your manifesto and things people must do in order to successfully pull-off an Agile project.

            The problem is, and we run into this problem all the time with kanban, this: When you write down things that appear to others as the bible – it is the bible. Whether you wanted it to be or not.

            For the record, I rather like most of the 22 things in the two ScrumMaster Manifesto lists. But others will see them as edicts.

        2. Agreed. I think if the Snowbird folks had said, here are some ideas, see what you might be able to do with them that’d be one thing.

          Calling them sentences would also have been fair; calling them quatrains seems self important and calling it a manifesto seems downright pompous and bloviating.

          This lack of humility is pervasive and turns off everyone with brain cells to knock around.

          We need to reboot the agile stuff completely; no more manifestos, no more preachiness, no more talking at people;

          We need people to talk TO people not AT people

          1. Jordan,

            One thing about Snowbird. Many of those people were very well meaning at the original meeting. The Agile Manifesto isn’t all that bad – it can be divisive and preachy – but at the time that strong statement was rather necessary.

            Since its signing, some of the signers (but not all to be sure) have become very wealthy and their egos highly inflated. When we see their pompousness now, it reflects on the original manifesto. And perhaps that’s unfair.

            The more frustrating thing is that the couplets in the manifesto are largely ignored by Scrum as a business. The business of scrum has, in my opinion, negatively impacted the success of Agile by replacing the good ideas in the Manifesto with best practices created to support corrupt certification processes.

            One thing I agree wholly with you on, the least followed part of the Agile manifesto is “People over Process.” Scrum is very much focused on the process. Which is very sad.

          2. It isn’t that bad, but it isn’t that good either…

            Of the 4 “quatrains” — err, phrases, the last one, is completely irrelevant to most software development.

            The penultimate one is also of moderate use. So at the end of the day, there are two good sentences in there.

            I wasn’t at Snowbird, so I can’t speak to their motives. There is only one original signatory that I have ever met on more than one occasion.

            Whatever their original goals were, it quickly turned into a money seeking machine, and that is where we are at with it.

            Have you seen the post on my blog related to Kanban? I’m curious to know why you kanban folks took something related to manufacturing and redressed that up as a software engineering methodology.

            Software is a creative, not a manufacturing process…

            Although I agree with you that the Scrum certs are corrupt, I’m highly suspicious of “Kanban University”. This seems like cert oneupmanship.

            The market was fooled by XP; fooled by Scrum; will they allow themselves to even try Kanban? I’d love to be convinced that Kanban is great but so far what I see is similar to the scrum marketing trend and it’s main selling point being that it’s not scrum



          3. Additionally, and I think you’d agree, that the original “agile” — XP/Scrum etc was aimed at the issues they were facing in the 80s and early 90s. Not the issues we face to day in the 2010’s and 2020’s.

            I think that is a huge factor that is totally lost on most people.

            Maybe in the 80s there were a FEW cases of “too much documentation” but today we have way to little.

            Collocated team? Scrum was invented when fax machines were state of the art. We’ve come a long way since then, but the agile methodologies have not.


  8. Jordan,

    I did a talk last October which basically said that kanban will be corrupted just like Agile has, Lean has, SixSigma has. It’s an inevitable progression when good ideas come into contact with both enthusiasm and the profit motive.

    I have no affiliation with Lean Kanban University, but I can tell you it’s initial goals were to be an antidote for this type of progression. I don’t see that ideal as sustainable.

    For me, a kanban or a personal kanban, is a board that shows people what’s going on. Nothing more, nothing less. I have told clients of mine to stop using kanban and to use other visualization tools when kanban wasn’t the right fit.

    I also very much agree that the Agile Manifesto was a liberation movement from a certain type of oppression that was rampant in the 80s and 90s. I assure you, that oppression has not disappeared. Unfortunately, it’s kind of like organized labor and mandatory dues payment. Unions may provide some benefits some time, but they cost money and add bureaucracy all the time. This is how I’ve seen certification corrupt Agile.

    Nonetheless, I will not be jaded enough to throw out not only good ideas but good history simply because people have been bad actors. Nor will I dismiss all attempts to make work more effective and enjoyable because of this idealistic entropy. Nor do I necessarily thing this entropy is bad.

    Humans cannot know perfection, therefore it is better for us to see the imperfections and always attempt to improve.

    I seek to improve agile, not to bury it.

    1. What’s worth keeping? I don’t see anything new in agile that is worth keeping.

      Iterative and Incremental approaches existed long before agile, and they are still effective.

      To me “agile” is Iterative and Incremental + Sloganeering + The Hard Hard Sell + Demonizing the opposition + Anti Capitalist Leanings (no titles) EXCEPT Ironically when it comes to profiteering on it.

      Maybe I’m missing something, but what is truly innovative from agile?

      Sometimes it’s better to build a new house than to keep fixing up one that has considerable problems.


Leave a Reply