This is the second part of our series about agile and scrum. In part 1, “Doing agile, using Scrum”, we have been looking back at the past and learned about the evolution of the “agile” idea behind the “Manifesto for Agile Software Development”. Let’s see what we can do to bring the values and principles of the Manifesto to action in our professional lives.

How would you, for example, implement the principle “Deliver working software frequently, from a couple of weeks to a couple of months, with a preference for a shorter timescale.”? Probably by using short implementation phases and iterations and then releasing it.

Or what about “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.”? Frequent retrospectives could do the trick.

You will most likely find well-established solutions for each of the principles.

For a development team, in the best case, practices (like DoR, DoD, short iterations, frequent releases, estimations, etc.) are not chosen randomly but follow specific needs. Since agile practices and agility reach back several decades, experience proved that some work great in combination. Agile methodologies or frameworks bundle such combinations.

As you can imagine, various methods fit the different needs, types and sizes of projects. As a nice metaphor, the “agile umbrella” covers a repertoire of agile methods and frameworks - each fulfilling a different purpose.

The key idea is that all of these are based on decades of experience and approaches of professionals. They reviewed their approaches used so far, agreed on general values and adapted their working style.

Scrum - does one size fit all?

Scrum is probably the most widely spread and best-known method under the “agile umbrella”. It is a good example of a set with bundled practices.

Though Scrum focuses on self-managed teams and their efficiency, it respects agile values and principles by applying suitable practices.

So, the first insight to be shared is that Scrum is not just a “trendy idea” - it is based on over thirty years of professional experience and is still evolving. The Scrum guide defines the complete Scrum framework - which also uses the principle of “inspect & adapt” and is updated itself.

At that point, it seems to be too good to be true. All the knowledge and cleverness in one framework - what could possibly go wrong?

The definitions of all roles, events and artifacts are mostly easy to understand. They are applied to software development projects (and also other kinds of projects) and then FAIL. We will provide some of the “dirty real-life examples” in the third article of this row soon.

But why does Scrum fail? Why are there critical voices?

One explanation can be that, most of the time, we are not aware of the principles behind Scrum.

There are many discussions about the waste of time with all those events and Scrum not being able to come up with good results. But such conversations do not come up at a point where we check prerequisites:

• Is it the right approach to develop the product or for this project?
• Does the organization’s culture allow an agile approach and self-managed teams?
• Do we know WHY we chose Scrum and what principles stand behind the framework?
• Do we know WHAT shall be achieved?

The early adopters of Scrum were at a different state of mind and focused on what does not work and changed it.

You won’t succeed with Scrum if you assume to be successful by simply applying the Scrum Guide. There is no guarantee. Even if you consider the prerequisites, it will feel heavy and hurt sometimes. Which is a good thing - we mustn’t ignore or be annoyed about. It allows improvement and, in some cases, even to choose an alternative to Scrum or other agile methods.

So, in the end… or rather at the beginning…

Organizations should choose wisely what fits their needs - not what is “en vogue”. So Scrum shouldn’t be the default answer for each development initiative.

In the upcoming article, we will have a deeper look into the realities of project teams and common pitfalls or misinterpretations.