Agile teams are becoming more and more popular in these days of extended and standardized digitalization forced, in many cases, by the pandemics. However, in this age of remote work, distributed teams, and time zones that stretch across multiple continents, it can be sometimes more challenging to implement agile successfully. We recently had the opportunity to interview Pablo Ruiz-Muzquiz, CEO and co-founder of Taiga and Kaleidos.
Pablo has a broad experience in working with agile development teams. He has participated in the design and development of more than 30 large technological projects. And he promotes new productive, sustainable and committed models with a positive impact on society.
As an expert in agile, we asked him quite a few questions on the matter from which we’ve selected the following for this article.
You can watch the answers on the video, listen to the podcast or read the written interview below.
Watch the VIDEO INTERVIEW or listen to the PODCAST on Spotify or on ivoox.
Q1: Has the pandemic affected agile or agile teams in any way?
Well, absolutely, yes. I’d say that two things come to mind. The pandemic has seen agile teams cope with it better than what I tend to call fawl agile teams. So false agile teams, and of course, non-agile teams. Why? Why is this? Because they are better prepared to deal with changes. Agile teams are great at embracing change.
But even agile teams are affected by the pandemic. I mean, we all have been affected by the pandemic. We are proud of being super agile, but how agile teams have been affected?
Well, I’d say in two ways, mostly:
First, we have been forced to quickly find new effective ways to communicate and negotiate both purpose and work. During the pandemic, that has been most challenging.
And also, constantly be sure not to default to the ideal liturgies and those empty habits that we always have.
Due to the pandemic exhaustion, when you have that context, or that mental load, you tend to just go on rails, right? But agile doesn’t work great when you go on just on rails. And so that tends to bring less of conscious processes, like you’re not evaluating what you’re doing. And that is something agile really treasures. So I think agile teams, even great agile teams, have been experiencing that problem.
True agile teams that were prepared to change and that were always evaluating and analyzing how they’re doing things or why they’re doing things, probably have been sort of enjoying these forced situations, better than those non-agile teams or agile teams that were not mature enough.
Q2: How can agile help an organization to be more innovation driven?
To be honest with you, this idea that agile brings innovation to organizations: I don’t think that’s true, necessarily true. I think agile is good at managing expectations around waste management. Agile is a lot about how to minimize waste, which is so tedious to deal with.
However, innovation management doesn’t happen just because you are agile. Perhaps people are saying: “wow, what is he saying? They’re so connected!” Not really. There’s some correlation, but there’s no cause-effect. Now, since agile embraces change, rather than seeing it as a troublemaker, they treat change as a problem.
Agile embraces change. Now, you could argue that agile teams and organizations that are agile are more keen to be adaptive, and prioritize based on evidence and perceived value. When you have to deal with change, you have to prioritize. If you have agile techniques, you are best suited to identify what really was giving you more value. That’s a nice tool to have, in terms of innovation. But you won’t get innovation, real innovation without the incentive and the resources, of course. Agile can only hope to make the most out of what you’ve got already.
It doesn’t create new matter when there is none if I can use that analogy. It will transform with a lot of effectiveness what you’ve got into the most innovative driven process. But it doesn’t give you innovation for free. You need, as I said, incentive, motivation, resources… without that, agile is just like a very efficient technique, but you need more than that. And I think organizations and teams need to be aware of this. There’s a correlation. But if you want innovation to happen, make sure you inject energy into the system. And of course, you have to be agile. But you need more than just that.
Kiri substitutes our teammate, Andy, when he’s not around.
Q3: Can remote work be effective for agile teams?
Sure, it can. I think provided that they don’t forget the Agile Manifesto principle that says “individuals and interactions over processes and tools”, then that’s key to keep in mind.
Now, remote has its own challenges, and you cannot underestimate them. At the same time, there are advantages, and you’d be a fool not to benefit from them. So there are pros and cons.
I mean, the pandemic gives you extra corners, just because the context is so exhausting.
But for me, remote work won’t be effective for agile teams, if there’s no natural order on how to approach your teammates, depending on what you need from them. And remote communication does sometimes struggle with that. Agile is about reducing waste. And dysfunctional communication creates tons of waste.
Remote work, honestly, can quickly lead to a surplus of meetings, little to no reflection, or documentation and numerous chat interruptions. It’s a tendency that we have and I think that quickly leads to waste. Waste is the main enemy of agile.
Also, our fear, my personal fear, is that remote work will tend to over engineer tools and processes. And that’s a risk of business. You will try to rely too much on automation, tools, processes, workflows,because communication between people is not that great. So we tend to default to automation. That’s problematic, if it’s not done right.
Kaleidos team during a remote meeting.
Q4: What are the biggest challenges for multidisciplinary teams when it comes to using agile methodologies?
People tend to believe that diverse teams, cross-domain and multicultural do just automatically thrive in an agile context. But that’s not right. There are some specific challenges for those teams. And this is something Kaleidos has experienced in the past, experiences this day and will surely continue to experience in the future. And that’s okay. We don’t have an issue with that. We prefer diverse teams with these challenges that not having diverse teams, and having other challenges.
Two challenges come to mind immediately:
First, you need to understand each other’s mindsets within the team, so there’s little lost in translation. Because that happens a lot. What one person might perceive as absolutely critical, others might not even consider worth their attention.
The idea of team commitment ranks high in agile methodologies. And that commitment won’t ever happen if the different perspectives are not connected through. It could be a shared vocabulary, working team agreement —we like those a lot in Kaleidos— and, most importantly, a respectful approach to everyone’s contribution to the team. Without that you don’t have team commitments.
“Understand each other’s mindsets within the team, so there’s little lost in translation.”
I’ll give you an example. This is classic design code misunderstanding: designers, coders or visual designers, engineers… This misunderstanding always leads to two different criteria on what quality means. For example: quality is a perceived value of an output, something deliverable. If two people coming from different perspectives, see different aspects of quality and they are not connected, that’s an issue. And that will happen in agile. Agile really needs quality to be part of the process and having different perspectives or quality is a challenge that needs to be addressed.
And second, different perspectives tend to create small ghettos in teams. And ghettos tend to create private workflows, like some old black boxes. It will inevitably end up in pseudo waterfall iteration-like processes that are very rigid. And a collateral effect of that is that the product is going to be always sort of a work in progress.
You know what you are actually developing. One has these big picture sites, and you won’t have real progress metrics. So it’s very important that these cross-domain teams, which are amazing to watch when they are really working great together, have specific challenges and agile doesn’t just sort them out for free to them. They need to address them, specifically. And then everything works great.
Q5: Which are the most common issues that teams face when trying to implement agile in organizations?
I think that there are many. We’ve seen so many. You know how we know about those? Because people using Taiga; they come to the product and they like the tool. They like what Taiga has to offer. A lot of people do want Taiga to be their first agile tool. Because it’s so intuitive.
And then they will ask for features. They will come and say that this is a great tool for agile, but they tend to ask for something they feel Taiga lacks in terms of agile. And through those petitions, through those feature requests, we see those challenges; we see how they are approaching agile, and we learn a lot from those. We’ve actually written a lot around this in the past.
I like to, basically, just show people what they’re asking, and then tell them why that could lead to the wrong outcome. They’re unknowingly asking for non-agile processes. So basically, when we spot this, the underlying problem is that they like the vocabulary; they like the liturgies, the habits, and they dress what they are doing in agile terms, but they’re old habits are still there.
You know, the way they treat teammates, the way they perceive value, the way they prioritize, help middle management to factor in how different hierarchies still apply. When nothing around that changes, you have the appearance of being agile, but at the core, it’s not agile. It’s difficult to spot when you’re going into agile, it’s very difficult to spot that you are just fooling yourself.
“…the underlying problem is that they like the vocabulary; they like the liturgies, the habits, and they dress what they are doing in agile terms, but they’re old habits are still there.”
And the biggest problem with agile is not other methodologies or techniques; the biggest problem we have in agile is dysfunctional agile. Dysfunctional agile is terrible. It’s people believing they’re agile when they are not agile. And in different teams, we’ll try to keep old habits in a different way. But if nothing truly has changed, at some point, they will feel something’s broken. And the issue I have is that they think agile is not for them;they think agile is not working. We don’t know whether agile would work for you or not. You have to apply agile correctly. And the Agile Manifesto is there for you as a beacon. Just watch that beacon. It’s about keeping those old habits as a comfort zone. That typically poses the greatest challenge for teams entering this agile mindset.
Interested in dysfunctional agile? Watch our webinar on dysfunctional agile. Pablo talks through the most common mistakes he’s encountered in agile.
