5

So I just started to read into Scrum and did the (free) online assessment. Somehow I can't stop thinking that Scrum is a contradiction in itself. Even though the Scrum Guide never uses the word agile, it is often referred to as such:

Scrum is an iterative and incremental agile software development framework for managing product development (source)

However, solely the term agile to me at least has a very flexible and adaptive tone. Adapting to the situation, getting rid of fixed structures and rules. Scrum however has very rigid rules on how to work (Daily Scrum, Scrum Review, Team size etc.). Isn't that somehow a contradiction?

  • 4
    Agility means adhering to the values and principles of the Agile Manifesto. It does not mean doing whatever you like and calling it "agile." – Todd A. Jacobs Feb 10 '18 at 14:01
  • 3
  • it is agile within its boundaries ... scrum is agile because of its Strict Rules which u have been forced to follow – user666 Feb 12 '18 at 14:42
  • @ToddA.Jacobs I strongly disagree. I explicitly changed the wording from "Agile" to "agile". The "Agile Manifesto" did no patent the word agile. – rst Feb 13 '18 at 8:36
  • 1
    @rst Agile development is about embracing change (and by extension the iterative development and emergent design models), not being freeform! All agile frameworks encourage an inspect-and-adapt cycle and tight feedback loops, but if you're looking for permission to do "whatever feels right" you won't find support for that in any agile (or "Agile") methodology. A methodology needs some rigor to be repeatable; that's not a lack of adaptability, but rather a requirement for any expectation of consistency and a repeatable cadence. – Todd A. Jacobs Feb 14 '18 at 1:02
7

Scrum works well as a starting point. From the Scrum Guide:

although implementing only parts of Scrum is possible, the result is not Scrum.

There are a few takeaways from this. Notably:

  1. Scrum itself is immutable. If you're being fully Agile, you likely cannot do (true) Scrum (all the time).
  2. It is possible (and frequently a good idea) to only implement parts of Scrum. "Scrumban" is a common example of this. Just because this is 'not Scrum' does not mean it is bad.

Scrum is a framework. Like any framework, it is a tool. And like any tool, its worth comes from knowing how, when, and if to employ it.

Rigidly following Scrum, no matter what, is antithetical to Agile.

Using it as appropriate based on the situation is not.


EDIT: I should note that the above is from a theoretical viewpoint (which is what I believe the OP was asking for) and therefore is working under the assumption that the Team has already matured and is otherwise being productive with Agile practices. An "ideal", if you will.

An approach I've frequently seen suggested is for a Team just starting out with Agile/Scrum to begin by following everything by the book, strictly to the letter. Then, as the Team grows used to the process (and begins to understand it), they start to take more and more ownership of the process. Until, finally, once the Team fully understands the 'why's behind the process, they are given free reign to modify it as needed to fit their organization.

For what can happen if this 'customization' stage is attempted too early, see We Tried Baseball and It Didn't Work.

  • Why the downvotes? – Sarov Feb 12 '18 at 14:04
  • 3
    I downvoted. I don't think you have answered the question fully or within the spirit demonstrated by the post immediately below you. I also think the OP has marked your question as "answered" because it fits their pre-conceived ideas of Scrum not being Agile. If we are to argue that Scrum is not Agile then we also have to argue XP, Crystal, Kanban & all other frameworks are not Agile which means we are left agreeing that "nothing is Agile". No framework reflects the Agile values is the inevitable destination & that frankly is nonsense and a complete mischaracterisation of the values. – Venture2099 Feb 13 '18 at 14:26
  • 1
    We both know, and can read plainly, that OP wants to classify anything they like as Agile. Any attempt to provide context, structure or planning will be rejected by the OP as anti-Agile and all based on a cursory glance at the Scrum Guide and an online assessment. You have not dealt with this; you have obliquely pandered to their view (IMO) and secured yourself a top answer which I don't think reflects reality. – Venture2099 Feb 13 '18 at 14:28
  • @Venture2099 I don't think I managed to convey my point effectively, then. I did not mean to say "Scrum is not Agile". I meant to say "Rigid adherence to Scrum is not Agile". And, yes; "Rigid adherence to X is not Agile"; whether X be Scrum, XP, or just about anything else. Even the Agile manifesto itself states that there is some value in the items on the right, and thus rigidly focusing on, say, working software at the complete expense of comprehensive documentation would be anti-Agile. – Sarov Feb 13 '18 at 15:10
  • 2
    I didn't vote up or down, but I have a problem with "rigidly following Scrum". Most problems with Scrum are improper applications of the framework. Of course, you're right that people can take the parts they like from one or more frameworks and adapt it to their needs, but the ones who are most eager to do this are frequently the ones who most often lack any sort of repeatable methodology to their processes at all. In my experience, this usually results in Epic Failure™ of the first degree, but YMMV. – Todd A. Jacobs Feb 14 '18 at 0:54
6

(bold emphasis mine)

However, solely the term Agile to me at least has a very flexible and adaptive tone.

You are taking a specific term and applying your subjective definition.

  1. There is no Agile(tm)* methodology or framework since it is a philosophy of 4 values and 12 principles.
  2. Not having any structure is known as "cowboy" coding/agile and results in many of the same issues as traditional, Taylor-ist, project management.
  3. The Scrum framework is one of the foundations for the Manifesto for Agile Software Development.
  4. Misunderstandings and ignorance continually propagate such misinformation.

I just started to read into Scrum and did the (free) online assessment.

What source?

Perhaps a chat would be beneficial.

*Although Sarov changed the casing, the point remains valid and exemplifies a common misunderstanding.

ADDITIONALLY

As a framework and not a highly defined method, Scrum is very flexible and adaptable.

Scrum ... functions well as a container for other techniques, methodologies, and practices.

Focusing on self-organization allows the Scrum Team and Development Team to choose the techniques, tools, approaches, etc. that empower them to create a product of high value and quality.

  • Yes, I really didn't want to compare it to Agile(tm) but to the "philosophy" of being agile. What I really don't understand are all those courses (At least in my country) many schools offer to learn Scrum. You can go for months into different Scrum classes. I really don't see the point. – rst Feb 11 '18 at 15:39
  • Looking at the definitions of agile software development and Scrum, how specifically do you believe that Scrum does not support or is counter to the agile philosophy? There are plenty of "Scrum" training companies, schools, and consultancies out there. Sadly too many either ignore The Scrum Guide or prescribe specifics as part of the framework. There are a lot of techniques out there that many use and that can be the value of some of these offerings: learning more tools, approaches, etc. to use and avoid. – Alan Larimer Feb 11 '18 at 22:30
  • @rst I failed to tag you in my comment above. Also feel free to drop in the chat.. – Alan Larimer Feb 14 '18 at 2:54
2

How can any software development methodology be "agile", if the compiler/interpreter has strict rules about acceptable syntax? Since we live in a universe governed by pretty laws of physics, we have to accept that there will always be rules that we're stuck with. We cannot do "whatever we want", we innately accept certain restrictions to our abilities, and work within those restrictions to accomplish our goals and desires.

The goal is understanding what is most important and then putting focus on that. The Agile manifesto intentionally says that the items on the left are more important than those on the right; not that the items on the right are undesirable.

Scrum, likewise, has a strong focus on what is important. Through experience, its creators have written down what they think is most important when developing certain types of products, and left the rest open for their users to fill in.

The key to using Scrum is to start by asking: "Is what I am trying to accomplish the same as what the creators of Scrum meant for it to accomplish, and do I value the same things they do?"

If the answer to both is yes, then you will find that Scrum isn't all that restrictive. It might have rigid rules (though not nearly as rigid as your compiler/interpreter), but those will not bother you much, because they happen to be rules that you should want to follow if you want to focus on what is important.

If the answer is not yes to both, you shouldn't be using Scrum, because you feel constricted. You will be focusing on different things as your rules are, which will lead to conflicts and confusion. This isn't a problem with Scrum not being Agile, but a problem of you using the wrong tool for the job at hand. Remember: people are more important than processes. I'm sure the creators of Scrum would agree with you that you shouldn't use a process that isn't helping you.

It's like cooking. Are you more Agile for throwing some random things in a pot and claiming it's food, or if you find the proper recipe for what you are trying to make and follow it? Only one of the two focuses on what is important. You can claim recipes aren't Agile because they are rigid, but if you focus on what matters, you'll learn soon enough that they are useful regardless. Even if, through experience, you realize the perfect cake requires two spoons of cinnamon instead of one. It's not like the writers are going to bust down your door to force you to follow it.

0

Rigidly following Scrum indefinitely is a bad idea and as you rightly point out, would not be Agile.

However, rigidly following Scrum until you understand it is a very good idea.

There are a lot of concepts in Scrum that take a while to understand and it is easy to fall in to the trap of adapting that which you are not used to or do not recognise the value of.

I suspect that part of the reason the Scrum Guide is written in such an inflexible way is that organisations often adapt Scrum from day one and if things go badly state that "Scrum has failed".

  • 1
    Please support the conclusions in your opening statement. What makes using a single approach indefinitely a bad? How would that violate the agile philosophy? (Note the lowercase "a" because Agile is a industry created term.) – Alan Larimer Feb 10 '18 at 16:03
  • It's a fair point that following Scrum indefinitely would not necessarily be a bad thing. However, I would say that would preclude any kind of experimentation, which is an important part of the Agile approach. Also, I use the upper case A in Agile as that is what is encouraged in the Agile forums I follow. Force of habit! – Barnaby Golden Feb 10 '18 at 19:22
  • As a framework, there is plenty of room for experimentation. Of course one must still work within the roles, events, artifacts, and rules. Looking at eXtreme Programming there is less flexibility for experimenting because it is a more rigid system. XP requires Test Driven Development, User Stories, Pair Programming, etc. Scrum would permit such practices, and teams should be encouraged to try them, but they are not required because perhaps there is a more effective and efficient way for that team to work the product. – Alan Larimer Feb 14 '18 at 3:23
-3

It is a great question.

I will try to make my answer short.

If you need to have a successful project then you need to have these meetings or to have all of the documents that substitute these meeting (and do not forget the communication part to distribute the documents).

Note:- documents include. Status reports and consolidating them, also sharing them Requirements and updating them and sharing. Management reporting. And many more documents and other practices.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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