#Aryxe Talks: Agile team dynamics, culture shift & collaboration

Agile visionaries put great trust into teamwork being essential to good software delivery. In agile teams, “we” is heard much rather than “I”. There’s this idea of sharing an exciting adventure and building something that genuinely matters and will make a positive impact. 

We have learned by now that there’s no secret recipe to building a perfect agile team. Some teams implement scrum, some kanban, and some come up with their own mix of frameworks and custom tailor the approach to their needs. 

To better understand agile team dynamics, what agile transformation means in terms of company culture, and how empowered teams work better, we have decided to sit down for a chat with Aleksandra, one of the Managers on the Aryxe team, who’s been heavily involved in our own agile transformation.

Can Agile be helpful in any business area?

I won’t be able to give you a straight yes or no answer. The reason for that is that while Agile was created in response to the rigid, linear process of Waterfall, the Waterfall approach still works with certain types of projects and shouldn’t be discarded by any means. When you have the desired end product that is known, clear, and understood, and you have formally approved project plans, Waterfall will work well with this. 

Agile is better for projects with more dynamic requirements and those where change is expected. 

What I like about Agile is that instead of going all in on a “big-bang” launch, your team delivers work in small, valuable increments. They have sort of a natural mechanism of coping with and responding to change swiftly. Communication flows differently in Agile, too. When working with the traditional approach, you contribute to the project and then throw it over to whoever is next in line to work on it. In agile, you collaborate with cross-functional teams, using open communication and *lots* of trust in the ability of the team to self-organize. 

Going back to your question after this quick detour, I’d say that many companies can benefit from Agile practices. Still, we ought to remember that pushing for Agile adoption no matter what, will not and cannot work. Instead, there needs to be an understanding across the organization of what agile will bring and why you want it to work.

In the series Staying Agile – Part 2/4, you point out that “Scrum can increase employee productivity and happiness, improve product quality, significantly reduce time to market, and enhance stakeholder satisfaction.” What’s your main advice for companies who are new to using Agile? What challenges should they look out for?

Software development teams most frequently use the scrum I’m referring to. Still, its ideas and principles can be applied to all sorts of teamwork and projects. This is precisely why scrum is so popular. With its set of meetings, roles, and artifacts, Scrum helps materialize the agile mindset by supporting and reinforcing the Agile core values and principles. The framework is heuristic; it is founded on the principle of continuous learning and adaptation to fluctuating factors. Scrum teams acknowledge not knowing everything at the start of a project. They expect and welcome changes because they are quick on their feet. 

Companies that have just decided to use Agile often go with scrum because the framework itself is relatively simple. Its rules, roles, and events are easy to understand. In addition, it has a prescriptive-ish approach, which will help remove ambiguities initially while still granting enough space for companies to spice it up with their preferences. 

One challenge I’ve seen is that scrum could take time to fully understand – mainly if a team is accustomed to a traditional model. The scrum roles, communication styles, and frequent meetings with dedicated agendas could be somewhat of a cultural shift in a company. If not handled with caution, scrum can quickly go wrong solely due to a “clumsy” introduction to the team. 

Still, the long-term benefits of scrum should outweigh the learning curve. So my advice for companies trying to implement scrum, or any other framework, is to take their time with it and find someone who’s already done it and can help guide their team. 

How to decide between traditional and agile project management?

You’ll want to consider the size and nature of the project(s) you’re about to take on, the size of your team, the approach your team has been working with thus far, and a potential cultural impact in case you are changing that up. There’s also the clarity of requirements for the project, the risk level analysis, and the scale of scope change.

It’s a lot to consider, but it’s better to make the right call than to figure out 3-months into the project that you’re using an approach that doesn’t work for you. 

I think it’s safe to say that you should be just as agile with the framework you choose as you are with your product. Going by the book by all means will likely undermine your progress. So, experiment, take the time to check in on how things are going, what’s working for you, and what, on the other hand, isn’t. Don’t force something just for the sake of consistency. Instead, mix it up and take whatever you need to make your team better and more efficient. 

How do you measure success in implementing Agile? 

Metrics – never an easy subject! I’ve seen projects where no data was tracked, making it very hard to tell whether you are or aren’t on track with whatever you are doing. And yet, there have also been projects where metrics and numbers are used almost like ammo, pitting teams against each other and forcing an ongoing competition in how many story points one can complete. 

Both approaches aren’t practices I’d suggest to anyone because it genuinely doesn’t have to be so extreme, one way or the other. 

You’ll need to determine which metrics will work for you and your team. The number of items in a “Done” column doesn’t paint the whole picture. You should have a combination of agile metrics and business metrics and consider your team succeeding in agile only when there is a balance between the two. The business metrics will focus on whether your product/service is the right one, built at the right time, and for the right market, while agile metrics will help you measure and assess aspects of the development process. 

Metrics are a piece of the big puzzle we call team culture. Metrics will give you insight into how the team is doing and provide measurable goals. It would help if you didn’t fall into the trap of being obsessed. Instead, focus on balancing quantitative and qualitative feedback to drive change. 

In Agile, there’s frequent mention of “empowered teams” – Could you share your thoughts on what an empowered team really is and how to get there? 

Agile teams are self-organizing and cross-functional, which means that rather than being directed by someone on how to complete their work, they choose how best to accomplish it. It all comes down to nourishing an environment where employees feel like they have control over their work; they are empowered to be vocal about their ideas and don’t hold back when sharing feedback because they are open to change.

To me, this makes all the sense in the world, and it’s maybe because I’ve experienced it directly. Imagine being a Customer Support Agent for a second here. You log on for your shift, and your Supervisor assigns a batch of tickets for you to work on, followed by another batch and another one – and you soon lose the sense of any control because you are seen merely as an executor of whatever action needs to be performed. So think again; logging on for your shift and then taking the tickets you’ll work on by yourself will make you feel different. It will be a sign of someone trusting you, and you will slowly but surely strive to learn more, improve and continuously grow. 

I mentioned the team being cross-functional in agile – another great way to empower the team. Continuous mentorship and shared skillsets are crucial in agile teams. Teammates are encouraged to learn from one another and mentor each other.

Agile frameworks work together with cultural values. If your organization lacks the cultural default, the leap to becoming agile could quickly turn out flawed.

Every team can benefit from certain practices; this isn’t necessarily linked to agile teams. Teams perform better when they can shape decisions together instead of executing someone’s firm choices. It takes great effort to instill and reinforce a culture of accountability. Still, it will never fail to lead you to improved trust and a shift in company culture, leading your team to improved performance.