As the title suggests, this article is about two different aspects of Scrum. Part one deals with Scrum not being agile and part two deals with Scrum vulnerability.

Before going into more detail, a brief disclaimer: Everything I raise in this post (and in blogs in general) are my personal views and do not represent the views of my current employer, my former employer or any future employer.

Scrum is not agile

I guess a typical reaction to this headline would be “How is that possible? Scrum is not Agile? Wasn’t Scrum the first agile software development process?” In short, Scrum claims to be an agile process, but unfortunately Scrum is far from agile. I’ll tell you why.

Let’s take a quick look at the Agile Manifesto. It says it values “individuals and interactions over processes and tools”. Let’s take a quick look at what the word agile means. According to the Oxford Dictionary, agile means “able to move quickly and easily.” It is not a coincidence that the term Agility was chosen to represent higher thinking in the Agile manifesto. In fact, one of the main ideas behind agile is that it is extremely difficult to move quickly and easily in many software projects. This is not the case for a brand new project, but over time many projects enter a situation where sustainability is simply not possible. To prevent this (and other problems), the Agile Manifesto and the principles behind it provide several high-level guidelines. These guidelines are not specific well-defined processes or tools, and they allow for many different implementations. I suspect that both of these attributes (advanced and allowing different implementations) are entirely intentional. The overall goal is not to provide a panacea, but rather to help peers avoid many of the pitfalls of software development that the authors of the Agile Manifesto have experienced firsthand and which fall into these categories.

Now let’s look at the Scrum guide (written by the two authors of the Agile Manifesto). Compared to the Agile Manifesto and Agile Principles, this guide seems rather lengthy. Surprisingly, the entire guide does not mention Agile once. I’m not sure if this has always been the case historically, but if the author of the Scrum guide doesn’t claim Scrum is agile, then we’ve done the first part of this blog post. I don’t think that’s the case, so let’s move on. The Scrum Guide is about a framework that contains “roles, events, artifacts, and the rules that bind them together.” In other words, it is a very specific and well-defined process. This sounds neither agile nor agile (remember: “interactions between individuals and processes and tools”). It’s very ironic and obvious. This is where the whole Scrum movement should stop. But it didn’t, to the dismay of a growing number of software developers around the world. Every time a Scrum project fails, it is not because of an underlying flaw in Scrum, but because Scrum is not implemented correctly. That sounds like a good segue to the second part of this article.

Scrum is fragile

This part is very short. I think WordPlay (Scrum being Agile/Fragile) is interesting, but aside from that, it perfectly describes one of the things that really bothers me about Scrum: whenever a Scrum project fails, it’s because Scrum wasn’t implemented correctly. You can read a lot of these projects. What does it mean if a large number of intelligent software developers don’t get Scrum right? This means that the whole framework is fragile. This is another major argument against the use of Scrum. If it is difficult to use, what is the appropriate framework?

Well, it seems Scrum might actually provide value with the help of expensive consulting and coaching, as well as training and certification. But it is unclear whether this is of value to software development companies and the hard-working software developers or those providing services in and around the Scrum ecosystem.

Personal view

Finally, I’d like to talk about my personal views on software development, Agile and Scrum. In my opinion, a very important part of quality software development is maintaining a simple prioritized task queue. A weight is a combination of the value the task provides to the customer/developer and the estimated effort to implement the task. Some developers are born that way. For teams and companies that are not in this situation, Scrum provides a fairly expensive and inefficient implementation of priority queues. Let’s be frank. Software development is a very difficult and complex job. Are we really surprised that so many projects fail? The field is still young and we have a lot to learn. This is crucial: we need to learn from past experiences, both failures and success stories. Here, we all fail. We are not using the wrong process or implementing the right process in the wrong way. We just got caught up in the rat race and couldn’t take a short break to see and learn from what was happening around us, even before our time. Our responsibility is to extract knowledge, experience, and wisdom from the many resources that are readily available to us: many books, articles, and videos on software development, and last but not least, the Agile Manifesto.

Original: http://www.dennisweyland.net/blog/?p=43

By Dennis Weyland

Translator: Queena

—— send benefits ~ recently will be previously translated articles, sorted into PDF.

Reply in the public account background: 002 can be picked up oh ~

The content of PDF will be updated in the future, please look forward to it!