Yes, Even Good Projects Can Go Bad - Cross posted here (written in 2022)
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.
Comments
Post a Comment