Agile Scrum: the burnout/boreout factory

“Agile-Scrum”: this makes the new hype sound like an insult, which is probably not a good idea considering a lot of companies use the Agile Scrum method as part of their rejuvenation and revitalization programs.

Behind the provocative title, reality is more nuanced. The purpose of this article is to pinpoint some of the risks and incoherencies in the Agile-Scrum model, and why it can fail to achieve its true benefits in the actual business world.

Agile-scrum methodology

Scrum is one of the methodologies of the Agile approach. In short, Agile is a pragmatic project method based on an iterative cycle of development which adapt and increment itself following the changing needs of the business. To differentiate traditional project methods from the Agile approach the following example is frequently cited. If you need a vehicle to go from point A to B, traditional project methods will often construct the best possible vehicle, like a car for example. There will be a clear deadline for the delivery of the vehicle, but in the meantime, you’ll have to keep walking. With the Agile approach, intermediate products will be quickly constructed and delivered. If you don’t have a highway and the distance is short, why construct a complex vehicle? The Squad will swiftly build a skateboard that business will be able to use with immediate results. When business requirements evolve, the Squad will build a bicycle, then a scooter, a motorcycle and finally a sportscar, if needed.

This is the strong point of the Agile approach: it is pragmatic and business oriented. The Scrum method is even more result oriented. The Scrum jargon seems to flow out of a Marvel comic universe, with its Squads, Chapters, Tribes and Guilds. But besides this geeky image, the real strength of Scrum is that it focuses on the work to be done, whereas traditional project management methods concentrate too much energy on reporting to upper management with less involvement in the work needed to move the project forward.

At its lowest and most important level, the Scrum method is organized in Squads of 5 to 7 collaborators working in “Sprints” of generally 2 weeks. Within a sprint, a Squad must achieve a predefined objective, from the conception to the testing and delivery. Of course, you can’t deliver a full product in two weeks, so the Sprints are just small parts of a greater project. Objectives are set by the Squad members and are presented and monitored during daily standups of 15 minutes.

On paper this sound ideally: we have empowerment, demonstrable results matching concrete business needs and multiple talents gathered together, continuously challenging themselves to improve the products and their skills. In reality, you just have a method; you still need the right people to work with it.

Critical view on Agile-Scrum

Scrum methodology requires strong involvement and constant initiatives from collaborators. Those profiles are not easy to find in hierarchically organized enterprises like many in Belgium and France. Initiatives are not part of corporate values, as they are expected only at manager level. This is not a written rule, but it is the reality. To develop an entrepreneurial spirit amongst all collaborators, you need a flat structure with result-oriented wages.

Even then, it is not certain a Scrum methodology will keep delivering high value results on the long run. One of the problems lies in the 2-weekly sprints and the story points that assess the Squads effort. If a collaborator really wants to go for it and do the best she/he can on constantly repeated short periods, it will not take a year before you get a burnout in your Squad. Humans are not machines and their quality vary for multiple private and professional reasons. If they feel they are constantly monitored every 2 weeks, they will experience a lot of strain. Frustration will grow when they realize their effort is not valued at its right level.

The other side of the coin is that humans learn and adapt fast. If they see their effort is evaluated on story points during each sprint, they will lower the sprint deliverables and raise the story points linked to the sprint. All the activity will slow down and on the long run, you’ll get demotivated, short minded and bored out collaborators. Exactly the opposite result you expected with the Scrum methodology.

The 2 week-based approach contains also the risk to lose the overall picture. Important projects can take months or even years and not every task can be broken down intelligently into a 2-week sprint. Some need months or even years of development and follow-up.

Besides those obstacles, there is also a fundamental contradiction between the freedom claimed by the Agile-Scrum methodology and the reality linked to deadlines. Almost every development is linked to deadlines, except eventually in R&D departments. The presence of deadlines implies retro-planning and a more waterfall-oriented structure. To effectively meet the deadlines, little freedom is left over for creative empirical freeriding.

Conclusion

In a project environment, the Agile-Scrum method should be used alternating with other more serene ways of work. Use the Agile-Scrum method when you really need a sprint during a limited period. As you can’t go through life sprinting all the time, you should alternate the trills of adrenaline bursts with more reflective periods. The human mind needs these periods to recover energy and learn from past experiences.

As for non-project teams, the use of the Agile-Scrum methodology should be limited to what it is meant for: project mode. Building an enterprise culture on this method can be counterproductive, especially when only few collaborators have the maturity to work independently. Imposing such a dynamic and creative system in a company with strong vertical structures could be a disaster. The first step should be to work on the human aspects of the enterprise. Strong cultural believes in competitivity is holding back collaboration skills between colleagues.

Punctual Agile-Scrum initiatives could be good examples to demonstrate the strengths and effectiveness of internal collaboration between members of different teams. The positive human experience together with concrete deliverables can create a constructive working climate with new perspectives for people who feel their contribution is not valued at their true worth. But this change must come from the collaborators. If it’s imposed, most of its effects will be gone.

Because, at the end, it’s not about methods, it’s not about tools, it’s about humans. How they interact, how they grow and how they add value to the company.