Strict or pragmatic Scrum?

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."

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

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

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 ;-)

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.

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.

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

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.