Why Scrum makes you happy

Whoever has worked in an environment where the Scrum methodology is consistently implemented, has already experienced it. Everyone else can simply believe me when I state: Scrum makes you happy.

Naturally, everyone will find an aspect that appeals most to them: Be it the possibility of continuous improvement or the fact that, in the ideal case, one can always deliver those items that the user and the client truly need.

But, another interesting question in this context is what science actually has to say about the topic. One of the most important researchers in the area of happiness is Mihály Csíkszentmihályi, who achieved fame by his description of the “flow experience” that he observed with extreme athletes or surgeons, among others. Csíkszentmihályi described flow as “being completely involved in an activity for its own sake. The ego falls away. Time flies. Every action, movement, and thought follows inevitably from the previous one, like playing jazz. Your whole being is involved, and you're using your skills to the utmost.” Succinctly stated , flow is characterized by complete absorption in what a person does or, as Csíkszentmihályi puts it, “completely focused motivation.”

Education researcher Felix von Cube picks up on this approach and attempts to explain why people try to achieve flow experiences. He attributes experiencing flow to people satisfying an innate instinct. Why do people climb mountains, why do they research, why do they test their limits? Where is the evolutionary advantage of such behavior? Cube's answer: It is the instinct of curiosity.

According to Cube, curiosity offers an evolutionary advantage, as it forces people to create known from the unknown, security from insecurity and thus to constantly expand their own comfort zone. Because of this, people are programmed by nature to experience flow as happiness.

So how does Scrum as a methodology for software development ensure that a team continuously experiences flow?

In my opinion it already begins with how a traditional product backlog is structured within the Scrum process. A product backlog is comprised of user stories prioritized from top to bottom by the product owner. Those stories at the very top contain a high level of detail. The further one moves toward the bottom of the backlog, the more vague the requirements within the user stories become. The team works through the backlog along exactly this path, from top to bottom, from iteration to iteration.

Here, experiencing flow leads to a certain addiction to exactly this “kick”, which also explains why climbers want to climb ever higher mountains – or why Scrum teams strive to constantly increase performance and thus are able to handle more and more complex tasks through continuous improvement.

It becomes apparent here that creating known from the unknown, security from insecurity is inherent to the Scrum process. From iteration to iteration, the team dives every deeper into the backlog, increasing its potential and experiences flow as a group by striving for a “zest for performance.”

There are, of course, two requirements for this to happen:

Thus, the goal of an agile organization is to assemble teams according to the task at hand. It doesn't always make sense to use the most experienced developers for every project, as they can quickly feel that demands are too low. This restriction also applies vice versa.

For this reason it makes sense to sell customers not projects, but a team tailored to fullfil a client's requirements – complete with the appropriate methodology. In this way it becomes possible for a team to constantly experience flow during its work for the client, or, in other words, moments of happiness while striving for continuous improvement through the satisfaction of curiosity.

Who wouldn't want such a team?