In the era of software development and testing that we are living in, phrases like Agile and Scrum have become standardised/self-imposed in our subconscious. Just like our morning coffee. 

The fact that we work Agile and use frameworks like Scrum has become so mundane as getting up in the morning and rolling off our beds. But getting accustomed to a particular behaviour/habit does not mean it benefits us. Let’s just take a moment to think about the vices we perpetuate daily.

Don’t get me wrong, I am not against Agile, under no circumstance. To be frank, I am a big fan of everything an Agile mindset can offer us, but I think we should take a step outside of the “bubble” that we know very well. To be more on the point: we do daily’s, plannings, refinements, and demos, so we are Agile!

Unfortunately, if we take a closer look at some teams/projects and look at these with an honest eye, we can see that many teams are at this level, and the word Agile has a terrible reputation, like those annoying meetings many of us have on our calendars.

Hopefully, I did not lose YOU, so let’s dive into some possible solutions/good practices that could help us improve and see the areas where we could pay more attention to.

As a slight disclaimer, everything I propose as food for thought in the lines below is subjective and is my personal opinion.

Let’s go back a bit in history and see why Agile frameworks emerged

Agile as a concept emerged out of necessity. It was the IT industry’s response to customer requirements and changes in the market. It is essential to understand that just as the emergence of Agile was a necessity given by the business context, the evolution of the way of working under the “Agile umbrella” is also necessary. Let’s look at how many frameworks have emerged: Scrum, Kanban, Lean, and XP (and we didn’t even get into the scaled ones like Scrum of Scrums, LeSS, and SAFe).

The evolution and emergence of frameworks are natural, and we need to keep an eye out for new or tried methodologies because it is very likely that many other groups have already experienced the problems/issues you have in your team. There is a solution out there, you just need to find/study it.

Let’s not get “hung up” on a name

Labelling a team as a Scrum team that applies Scrum but only uses parts of the framework is about as useful as putting the name “George Clooney” on my forehead and expecting fame.

We should focus more on emphasising the proven and  helpful practices and eliminate the techniques that don’t help as quickly as possible. I think it’s more important to have a process/framework tailored to your team/context than to use a “by the book” framework that helps you with some practices but drags you down with others. Moreover, I firmly believe in being open to trying different approaches/techniques with the desire to improve the daily life and output of the team. Have you tried something, and it worked? Great, keep doing it. You tried something, and it didn’t work? Throw it in the bin and move on to the next experiment. Fail fast and fail often.

Feedback is vital

And I’m not just talking about customer feedback. I would focus more on input from the team. We should all strive to create a context where everyone can express their opinion freely and without prejudice. A key element would be Retro meetings. Out of comfort or possibly other circumstances, we can fall into the trap of repeating the same type of Retro “N” times, hoping it will give the same result as the first or second attempt. Let’s not be afraid to try more variations and types of Retro’s to keep up the flow of information/feedback.

However, receiving feedback is only the first step. Setting action items based on the input received and following up on these action items is essential in maintaining an influx of valuable ideas.

Try to get the most out of the meetings you set

Let’s take a few examples:

  • Daily’s tend to “drag on” for a while due to technical discussions. Encourage your teammates to take these discussions into smaller break-out sessions.
  • Refinements can be improved with the 3 Amigos technique. To take your practice to the next level, keep changing the 3 Amigos teams and mix up people with different seniority levels.
  • Sprint demos need to be tailored to the audience. More technical details can be presented if the people attending are more tech-oriented. If people are non-technical, then focus more on the product side.

Don’t push the team with preconceived ideas

What makes perfect sense to me can often be a “burden” to the team. We must keep an eye on the team’s pulse and foster an honest environment where anyone can say, “I don’t like X because Y and would like to propose Z because W”. These elements should be discussed and evaluated.

Set some standards

Although our working environment is very dynamic, it is still good to set some standards. Let’s return to the roots of a work activity, namely the Tasks we work on. What I have seen that improves the workflow a lot is to have clear tickets formatted similarly (with description, acceptance criteria, notes, links, etc.). Each of you can set up some templates the team can work with here. Of course, these fit nicely into a clearly defined DoR (Definition of Ready).

Let’s be human

Let’s remember that we are people, and we work with people. We are not machines that respond to the same stimulus in the same way every time. We have better days, we have worse days, and we have to take that into account. Remember that trust is built slowly with honesty and transparency but can be lost instantly.

Way of working

For newly formed teams still in the Forming stage, setting up some “guidelines” can help. These can incorporate our expectations towards each other, who is responsible for what, how many reviews you need on a PR and many more. Think of it as a set of ground rules. These can go a long way in alleviating conflicts in the Storming stage, and you can set a baseline for team behaviour.

Lastly, let’s remember to connect with the team and grow relationships. This is one of the most challenging aspects of the new remote/hybrid working style. Like all good things in Agile, we can only find the ideal recipe through trial and error. Some options could be coffee break calls, online games, or a meeting where you chill and chat.