Do you practice Scrum strictly after its rules or are you going a more pragmatic way, picking out the bits that suit you/your environment best, maybe mixing it up with other methodologies ? In other words, do you bend Scrum to suit your environment or do you change your environment to suit Scrum ?

Which way you think is the better ?

  • 3
    Pragmatic, always, in everything, is the right answer.
    – CaffGeek
    Commented Jun 15, 2012 at 21:41
  • 5
    Not an answer but worth a comment in my opinion, to mention that in the end note of The Scrum Guide is written: Scrum’s roles, artifacts, events, and rules are immutable and although implementing only parts of Scrum is possible, the result is not Scrum.. Commented May 18, 2015 at 16:38
  • 5
    We Tried Baseball and it didn't work. Very good short article by Ron Jeffries relevant to this. Imho All the examples of "Pragmatic Scrum" are teams that want to be cool and agile but lack either delegated power or the internal discipline.
    – Nathan
    Commented Aug 7, 2016 at 20:38
  • 1
    As far as I can tell from reading PM.SE, "pure scrum" is redundant. Scrum is a little like communism; everyone is convinced that they are close to Scrum, but everyone else in the universe is deceiving themselves through the "ScrumBut" heresy.
    – MCW
    Commented Aug 8, 2016 at 11:20

9 Answers 9


Scrum and Agile are loosely-defined. Every company implements it differently depending on how much they can "tolerate." I've worked on projects where we don't use sprints, and other projects where we break down stories to hourly items.

The best way to implement it is to use whatever practices benefit you, and leave whatever doesn't. While some "puritans" may complain that it's not scrum, reality dictates that unless people get benefit out of it (or see benefit in the process parts of it) they won't want to implement it.

  • +1 - "Use whatever practices benefit you, and leave whatever doesn't."
    – jmort253
    Commented Mar 18, 2011 at 5:25
  • 4
    Changing practices without a solid understanding of the underlying principles leads to an ineffective process. Pick-and-choose is very different from inspect-and-adapt.
    – Todd A. Jacobs
    Commented Dec 26, 2012 at 14:19
  • 1
    The only thing I'd add is, when you break the rules, try to understand why you are breaking them and make sure you continuously review whether breaking that rule is achieving the improvement you thought it would.
    – Ben
    Commented Apr 8, 2013 at 10:03
  • 4
    Since when is scrum loosely defined? Only XP is more prescriptive... Commented Apr 9, 2013 at 13:52
  • @aclear16 I've worked on seven different teams across three companies. No two teams (even within the same company) used scrum the same way.
    – ashes999
    Commented Apr 9, 2013 at 15:12

I work with "Scrumban", a mix of Scrum and Kanban.

We have:

  • Daily meetings
  • Sprint review each month (but we don't have the sprint planning, neither sprint/product backlog, because our work load is on-demand)
  • A board showing the tasks ("Not assigned", "Working", "External", "Done", "Parking lot")
  • Theses tasks on the board shows the work load of each person, the priority and the deadline of the tasks
  • Technical meetings (when needed)

This mix fits exactly what we need. So pragmatic is the way.

  • Which tools do you use for your Scrumban practice? Commented Feb 16, 2011 at 13:26
  • 1
    We just have a cork-board and post-its. as tasks income a post-it is added to "Unassigned Tasks" area. Each person has a row on this board. When someone is working on that task, s/he put the "task post-it" on his/her named line on the column that represents the status: "Working", "External", "Done" or whatever fits your project. It also can be done on Excel table and shared to your group by Google docs. PS: different post-it colors represents different priorities.
    – Johnny
    Commented Feb 16, 2011 at 15:39

Both ... since schedule, budget and requirements of the project come first, not the methodology, Pragmatic Scrum wins in terms of what you use at that time, on that project.

Strict Scrum is still important, however, because you need an "ideal" ... a crystal clear idea of exactly how you would be doing things if time, money and requirements were flexible and you only had to worry about sticking to strict scrum methodology. "Knowing better" is the most important foundation skill necessary for making optimal, pragmatic adjustments to strict Scrum in order to succeed in the face of actual scheduling, budgetary and specification constraints of the project. Strict Scrum informs Pragmatic Scrum; Pragmatic Scrum is what you use, but it's not random or completely ad hoc.

Be extremely careful about getting attached to "Strict Scrum" ... hopefully, you mean "evolving ideal" or "evolving state-of-the-art"... there might be different ideals ... it is important to understand different approaches, different philosophies -- if you don't understand a different philosophy that others are using successful, there is a problem with your approach to learning ... it doesn't mean that way is better than yours, it means that you are dufus with a brick for a brain who doesn't want to bother to learn how other people think, doesn't want to advance. A lot of "strict" fundamentalists should either be put in prison or a nursing home -- they are dangerous because of their rigidity. Approach this material as a martial arts master; learn from many different masters; never stop learning ... Scrum is a part of an artform ... it is continually being developed; it's riff that is constantly being improvised ... it's not a rock that crystalized and can't be changed


My general answer is start with Vanilla scrum and change your environment only when those changes PROVE to deliver better throughput, quality and team work.

Vanilla scrum is a receipt that works. It is a complete system of practices that help you achieve greater throughput, higher quality and more joy. I and many of our coaches tell folks to first implement vanilla scrum to see how it positively affects your whole system. Also, we ask teams to see where the pain remains that keeps you from getting the cost of iterating down.

A great way to do this for a new team is to have them run daily sprints for a week. (I learned this from a team at in Vancouver - Agile Vancouver's 2008 "Much a do about Agile" conference.) The great thing about doing planning and retrospecting daily is that it teaches you the practices very quickly. It also forces you to keep your planning time down to less than an hour and drives learning very fast with daily retrospectives.

When you are a novice at Scrum, the benefits of the individual practices and the overall receipt are hard to see apart from each other. The fast daily feedback loops shine lights on your problems. But, the extremely fast pace forces you to live with these pains for at least a week. Now we all know that it is so easy to rationalize or justify the difficulties/problems away, but if you don't let that happen you can use that pain to continue to make major improvements in the quality, throughput and value. And, most organizations need to make those strides, as they tend to increase the scale, complexity and distribution of their agile efforts as the proof pours in.

So, I totally understand making a hybrid version of scrum like Scrumban. However, I only support Hybrid efforts in teams that have shown the visibility, transparency and metrics to prove their changes. Adjustments to vanilla scrum should be put forth as tests. If the tests yield better results, you should keep them and hybrid it. If they do not yield better measures, you should not. Of course this begs a strong technical infrastructure, like Rally or AgileZen to manage metrics reporting:) It also requires a team that can reflect and retrospect on the qualitative measures.

Again, Hybrid for better results not to satisfy your long, linear and late current behaviors. Way more on this topic on our blog from Ed Willis - "In Defense of Half-Assed" - Part 1 & Part 2


Pragmatic - Agile methodologies were partly designed to overcome the challenge of applying a rigorous methodology (e.g. PRINCE2 in the UK) to a notoriously unpredictable situation (software development), as spelled out in the original Agile Manifesto - http://agilemanifesto.org/

Applying any Agile methodology in a rigid fashion drives a truck through that underlying philosophy, and if anyone tells you that following the process is more important than getting the job done then you should treat anything they follow-up with with the utmost suspicion.


Most of the teams I work with use pragmatic Scrum.

The areas I typically like to be pragmatic about:

  • Commitment — I believe its important to have some clear goal/commitment, but its more important to actually over-deliver and deliver as much as possible every sprint, than to meet the commitment. I dislike the over-planning some teams get into just because they fear commitment. (Scrumban helps here btw)
  • Scrum Master — I believe a Team Leader can drive an effectively agile team if he/she is an effective Team Leader. And for sure, a team/organization can be start experiencing agile iterations using Scrum, and consider how deep into the Self-Organized world they want to go later on.
  • All stories done by end of sprint — I believe this might be a bit hard for many enterprise-level teams. There are two reasons to do this — one is to actually have something shippable. If so, either finish all stories, or use latent code patterns to allow some stories to be "half ready and dormant". The other is to serve as a container forcing the team to collaborate and focus instead of spreading all around. I believe that a limit on the number of open stories is a more pragmatic approach than disallowing any open stories. Many teams use longer sprints due to this limit and others, which is horrible.

Bottom line, I believe pure Scrum is the best way if you can adhere to it. But I'm not assuming any team can/wants to go there. The question is what is the best road — is it the road of most resistance, or least resistance. probably least resistance won't drive you to improve much. so somewhere in the middle.

Did I say I'm a Kanban consultant ;-)


Depends on what you'd like to achieve.

Imagine that your goal is be to improve your body shape. You got a recommendation from well informed source, that it takes 30 minutes of daily workout routine to achieve this goal within 3 months. Each day you skip it this period is extended by 2 days.

Most of the time most of people hate exercising.

So, would you workout everyday to achieve the goal quickly OR workout only the days that you feel you want to?


As there is already an answer offering scrumban, I would like to vote for it as well, because while doing scrumban you can take tools from scrum and kanban which fit you and leave all the other behind. It will guard you from the waste but still can be strict and constrained not to run it to the wall. Check this site which provides all the information about scrumban: www.aboutscrumban.com


Agreeing with all of the above, I think that the key word is: "The Scrum Guide."

Remember that: Guide.

Most of the essential principles of this guide have to do with communication. Communication has always been vexed with an "apples and oranges" problem when the various parties who are communicating don't realize that they're not actually speaking the same language. The guide identifies a number of "stakeholders" in any relevant business process, tags them with formal roles, and guides ways in which these roles can usefully interact. There's a lot of good business value in that abstraction, but always remember that it is "an abstraction." It isn't gospel.

Every actual business situation has plenty of things to deal with that "the Guide(s)" could of course never anticipate, and ... "that's where you come in."

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.