Consistency and Culture
The Keys to Agile Development Success
By Aubrey Wade, Originally Published March 2022 with Firebrand Marketing
Yes, Even Good Projects Can Go Bad
Software development can be complicated. Projects can go off the rails and it’s not always from lack of effort, ability, or even experience. The teams can sense it, and people may even say it, but it’s hard to pin down a solution. This can be particularly problematic with large, scaled projects involving hundreds of developers, maybe even from multiple organizations. The stakes are high, which amps up the pressure.
Perhaps you’ve been involved with one of these projects? I’m sure we all have! And I’m here to bring you hope, and to share the story of how we recently worked with a client to course-corrected a 350-person project — and not only made amazing product, but REALLY made something — AMAZING! Among technical challenges, when I joined the project, I found it plagued by low morale, slow progress, misalignment of processes, and increasing politics of blame. I found people not talking, not sharing, little collaboration, the quality of work was not where anyone wanted it and people were not happy. Everyone wanted change and no one could make it happen, everyone told me change couldn’t be done here. I wanted out and with the way the project was going, I was not alone.
Spoiler alert!! In case you don’t finish this article, today the project is progressing with three active trains, a robust plan with a solid roadmap, high levels of trust, robust processes and growing, shared best practices. Our client is happy and we’re talking about expanding the program. Want to find out how we made it happen? Let’s jump in.
The Path to Progress
When the project is as big as this one, it can feel like it takes hundreds of steps to steer the team back in the right direction. But even with a project this big, I like to categorize the solution into two buckets — culture and consistency. From there, depending on the size of the project and the scope of the problems it’s having you might find yourself with several sub-steps, but the buckets to consider remain the same. Let’s have a look:
1. Culture
Organizational culture is a shared set of values among those employees, so when you bring multiple organizations together, it’s no surprise that there may only be a few values that are actually shared. In fact, some new behaviors can be quite jarring, leading to conflict among the project teams and stakeholders. For instance, some work cultures use competition to drive innovation, while others use collaboration. Depending on the circumstance, either approach can have merit, However, in this case, the challenge we faced as an agile team is that competitiveness permeated to a personal level, impacting the team. Because the developers were looking to impress, this manifested in them taking on too many points in a sprint or not sharing when they were falling behind.
Psychological safety
Our first aim then was to establish psychological safety. That means making it okay not to know the answer, to ask questions without fear of judgment or repercussions. No doubt this takes time, but it’s important to come with an ear to listen, not a ready answer. One way to do this is to make it clear that it’s perfectly fine for people to ask “dumb” questions. Just establish the baseline goals, processes, actions, and timelines so they are clear. Asking dumb questions not only clarifies understanding but it gives permission for others to ask their questions. It allows them to be vulnerable. So, celebrate the questions because those are a sign of psychological safety.
Transparency
The second part of culture is the need for transparency. Agile development just can’t function without it. The daily standup is the perfect place to encourage this and to discuss roadblocks and progress. The scrum master can set the tone here, fostering a collaborative culture so they have clear visibility into the status. Get that right, and you’ll start to feel the barriers come down as people share the problems they face.
Ask dumb questions and hide nothing. Simple enough.
2. Consistency
The second area we addressed was consistency. Again, this had two primary elements to it — defining the roles and following the process. This project was suffering from a drift away from proven best practices. No-one could explain why, it just became the norm within the project — the way it had always been done there. Immediately, that should be a red flag, because best practices are exactly that — codified solutions to problems encountered on earlier projects. Don’t repeat the mistakes of the past. After all, there are plenty of new ones to make!
Know your roles
On a large agile project, it’s important to define the roles and responsibilities for each team member. No-one can know everything that is going on, and how to perform each task. But if you tightly define their area of responsibility, and it’s distinct, then people can take ownership. This is essential if you want to hold people accountable. There are things they should know, like the status of a ticket for example, if it’s in their remit. And there are plenty of other areas where people should feel comfortable saying “I don’t know but will find out”. With an absence of process, it may seem like a vacuum of accountability — if everyone seems responsible, no one is responsible, roles get blurry, you end up with a lack of accountability for the core responsibilities and create friction on the overlap.
Take the time to set up the team and walk through the responsibilities. It will give everyone confidence and avoid conflict down the line. Even if the project is in-flight, it’s recommended to take a pause and reset. That may seem to those on the outside like a backward step, but for the devs on the project, it’s foundational. Trust me, you’ll move faster together once the team is aligned.
3. Follow the process
There’s a temptation on a major project to try to do everything at once. Surely a team of 350 people can find the time to add this feature, or migrate that product too? This should only take a sprint, right? Sound familiar? Why don’t we write a Shakespeare play, and make me dinner, too — I like my filet medium, while we’re at it? It just doesn’t work that way and the team will end up doing nothing well.
The solution here is to stick to the best practices. We call ours the ‘Product Mindset’ and it’s rooted in practical agile. We know it works — for teams of different sizes, for different types of projects, different technologies, with teams including clients. It’s the Nexient Way. And even for me, the Product Mindset is really the People Mindset. When we focus people to do the right things, the right reasons, in the right order and build it the right way, our clients win! But none of this works if the people are not aligned and don’t believe they can. But whatever your process — stick to it and hold yourself accountable. I once had to hold my client’s feet to the fire to hit a deadline, even though they begged for more time. I could have given in, and the project would have slipped. And that’s how all projects slip — one deadline at a time. Instead, they got it done, admittedly not to the standard they wanted, but learning the discipline was more important. Guess what, at the next agility assessment, they nailed it. That felt good.
Know who’s doing what and stick to the process. You can do that.
4. The Pivotal Moment
In the end, this project did bring me to tears but not from frustration. There was a moment when all our senior project leads came together from multiple groups and several organizations. We call it the Jedi Council, because at heart, we’re nerds like that, but it was the top brass. And guess what? Someone asked a “dumb” question. And they got a straightforward answer, with no recrimination, eye rolls, or backhand comments. They could because they had the psychological safety to ask, the answer was forthcoming because we were being transparent, their role was clear and so it was safe to ask, and we were following our protocols.
At that moment, I cried. I was actively on the call and had to mute. I cried on a call because I knew we were on the right track as a collaborative team. We were doing something that many people in the org told me would never happen. (See, that’s me being vulnerable to you too).
So, my goal here was to give you hope! Don’t give up!!! Be the changemaker for your teams and the people and teams you love and good luck out there! You’ve got this. Focus on getting the culture and the consistency right and the rest will follow — and may The Force be with you.
