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 ?
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.
I work with "Scrumban", a mix of Scrum and Kanban.
We have:
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
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:
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."
