The lack of leadership and the focus on process in an agile environment

Last updated Apr 10, 2023 Published Feb 2, 2023

The content here is under the Attribution 4.0 International (CC BY 4.0) license

Recently listening to the podcast Agile for humans that I often listen to, as I like to understand different aspects of software development.

In both hosts have a series in which they answer questions from the audience, usually the episodes are fast and to the point, without much details or talking through the subject.

The episode “YDS: Should the Scrum Events Be Entertaining?” was a mix of bouncing ideas (in the short time both of them had) and trying to focus on an outcome for the audience and the conclusion was a straight: “they should be effective”.

In that sense, I would like to elaborate a bit further on the gaps left behind by both hosts and the superficial tone on things that are not that simple to answer.

We should be effective

Much of the critics around scrum are based on the focus on process over anything else. Martin Fowler blogged about the mess that the code base gets when scrum is adopted, he named the post “Flaccid SCRUM”.

Practitioners report that this happens on the daily basis and only using scrum will lead to no where far. Specially more senior people are critical about SCRUM. Emily Bache also share her toughts on that with a look at technical coaching.

Still, the SCRUM framework adoption and its popularity cannot be neglected. It is widely used across the industry [1].

Despite critics around the lack of technical practices, specially in the podcast, it seems that the SCRUM trainers also have a lack of team building. Once again the focus on the process is the highlight.

I do agree that meetings should be effective, but not treading-off the team healthiness nor that the meeting could be fun or a relaxed one. Being effective is different of having an outcome, an outcome with next steps should be the goal of any meeting.

Fun and meetings

Making such statement neglects the different approaches that we have in the industry to facilitate meetings.

For example, fun retrospectives is an example of that, retrospective is a meeting that can be fun and generate an outcome. It depends much more on who is facilitating and the skills at hand to read through the team and the dynamics in place.

It is not from today that people try to remove the “fun” from anything that is “professional” - it seems that there is a invisible sheet that marks this gray area between fun and professionalism: “if this is fun, it cannot be professional” or “if this is professional” it cannot be fun.

Despite the positive impacts that gamified approaches have, it also suffers from such early judgement. But, companies are using that day in day out to improve engagement.

SCRUM master is accountable for team effectiveness

Focusing on a single person for accountability should be considered harmful by default.

In the episode both hosts agreed that the SCRUM master is the one accountable for the effectiveness of them (whatever effectiveness might be in a given context).

Taking a step back and practicing some introspection, how would be a single person accountable for a work of a bunch of people? I do agree that a SCRUM master is the one playing the role of removing blockers and helping the team to progress. Therefore, the people who is in the team should be accountable for the team effectiveness.

Each individual should grow, maintain and explore the effectiveness of the team regarding the role one plays - we are there together.

We are adults, we should be proud of our work and be accountable for our personal behaviors that help the team to be effective. The industry of software, suffers for this call. The craftsmanship movement and specially uncle bob tackle that subject already.

The SCRUM master should be a team player that is there to play along, not to be the single point of failure.

Building software is more than only being effective

Having the SCRUM master as accountable for the effectiveness might shift the responsibilities that the manager should have. For the nature of the SCRUM, the process is built to split the roles in the people that “does the job” and the people that “manages” the job.

In that sense, one might feel that they are accountable for the team effectiveness, and it also leads to this simplistic view that the team as an entity is there just for output.

In the end, it is easy to forget that we are humans, we build software for people and we are more than the effectiveness we have or the outcome we produce.

Developing a meeting that is fun might impact positively the team in different aspects:

  • Creating a sense of belonging
  • Feel that the work that the team do is valuable
  • Building relationships among team players

Focusing in process and a framework to have the label agile is something that can be done with a few steps, the business will be happy because now they “are agile”. Or at least they think they are.

The real challenge of being agile (and not doing agile) is to focus on what matter the most, adding value in the end of the day.

In the tech industry, the value comes through the working software in production, impacting end users.

But a few want to accept this challenge.

In the end, adopting a process, is way more easier than producing quality software.

References

  1. [1]A. Podelko, “Agile Aspects of Performance Testing.,” in Int. CMG Conference, 2013.
Made with 💖 by @MatheusMarabesi