loading...

Rant: big failing software projects are a failure of leadership, not software developers

matmooredev profile image Mat ・5 min read

Proceed with caution sign

Yet again I've found myself in the middle of a death march project:

a project which is believed by participants to be destined for failure, or that requires a stretch of unsustainable overwork

There are many reasons for this:

  • We have to meet a specific deadline that we have no influence over 🚩
  • Success depends on many different teams coming together and everything going according to plan (with everyone focused on "we don't want to be the one who misses the deadline" rather than the project as a whole succeeding) 🚩
  • We are not doing any usability testing 🚩
  • Decisions about what we are building are rushed and poorly communicated 🚩
  • The company has no separate QA function, or any kind of quality standards about what can and can't be released 🚩

A big part of the product work fell on my team, and it's complex. We are changing the business model at the same time as integrating with a new 3rd party system, in a short amount of time.

How I and my team responded

When I joined this team they had already split the work into milestones, with the first one being getting a simplified end to end journey in place. This gave us a kind of walking skeleton, but it was very far from a minimal viable product.

When we got this far, I re-estimated the remaining work (which was still quite unknown, but we had a better understanding than when we started) and discussed the estimates with our product manager. We concluded there was absolutely no way we would meet the launch date. Even if the team worked on it full time, with no other distractions, with no holiday, no sick days, we would miss the deadline by weeks.

We raised this problem to our overlords. They did promise to do anything they could to support us, but of course they stopped short of actually changing the strategy and ending this madness. At this point, half the company was committed to this and there was no questioning the overall approach. 🚩🚩🚩🚩🚩🚩

By this time we had already reduced the scope of the project to the point where it was impacting the usability of the product🚩 and we were anticipating various manual support tasks we would have to put in place for launch.🚩 The design we actually wanted to build was assumed to be version 2 or 3, which will be completed months after launch (if at all).

Some interventions

Because we couldn't cut scope any further, and we were unwilling to change the deadline, our only option was to bring in more people. I was pretty sceptical of this because often adding more people to a failing software project just makes it later.

Initially 2 new developers joined our team, one who had previously left the team, and one who was new but had some familiarity with the domain and experience working with the 3rd party system. Me and a technical architect also got more involved in hands on development. A couple of weeks later we were joined by 2 other experienced developers from a software consultancy. 1 of these had worked with the company before so they were familiar with the codebase, and the other I had worked with before at a different company.

The degree to which we could realisticly change our fate depended on how much we could parallelise the work so that people could work relatively independently. I split the work into 5 workstreams and asked for volunteers to feature lead each one. This was essential for me as the tech lead because there was no way I could keep up with all these things happening at once.

Each feature lead was initially working with 1 other engineer, and was responsible for planning the tickets within their workstream, and setting milestones for us to track our progress.

I spent an afternoon talking to the feature leads one by one, making sure they understood the work as it was currently scoped, and what was uncertain about it. We then set up a weekly catchup meeting with all the feature leads to discuss blockers and uncoming issues. I also suggested the head of engineering could optionally attend these in order to more directly support me and the team.

This approach has been partly successful but it's not a silver bullet. There is still considerable overlap between the workstreams and communication is a challenge. Splitting up the team like this has also limited the interaction people get with the rest of the team and created worries about silos forming.

A lot of my time so far has been spent facilitating decisions and coordinating. I've also been trying to encourage the team to collaborate on a QA plan, in order to make the most of an internal group of non-technical volunteers who will be our last line of defense against releasing something that doesn't work.

I'm meeting regularly with the technical architect supporting the team who has recently been helping with the development, since even with the extra people we had more work ready to start. Next week we've agreed to swap places, so he will be able to advise more on the big modelling decisions that affect multiple streams, and I will be able to help assist with one of the streams that is falling behind due to sickness and unforseen requirements.

At this point there is maybe a 50% chance we will be ready to launch something by our deadline.

Opportunity cost

During the last few months, we haven't been able to work on other product improvements, and the changes we've made in the last few months are not valuable on their own, because none of these code paths will be used until launch.

We had to stop all bug fixing (causing the backlog to become unmanagable again) and postpone work we had planned to improve resiliance of the system in some critical areas like logging in and paying for things. As a tech lead I do not currently have the space to set up sustainable development practices and build a sense of ownership around the product.

Human cost

This project put a lot of pressure on the team which in my opinion was completely avoidable.

2 team members of my team have left or are leaving, and the morale is pretty low amongst those remaining.

We have been doing regular "health check" surveys of how the team are finding things and things like autonomy, connectedness, and believing that we're doing the right thing consistently score poorly.

Almost all of the team are in England so this is coinciding with a month long national lockdown.

I personally haven't seen any friends or family for months. I'm burned out (again) and I'm sick of this company and how it's run. This week I was discouraged from even taking holiday and at the same time I'm supposed to be grateful they allow "flexible" working. Fuck. This. Shit.

"Proceed With Caution Sign" by State Farm is licensed under CC BY 2.0

Discussion

pic
Editor guide
Collapse
190245 profile image
Dave

Interesting. I did type out a whole host of reasons and my logic - but that's probably boring. We can get into the weeds with that happily, if appropriate.

Have you considered approaching management with "these are your problems, give me the power and your complete backing to fix it, or I walk" ?

I more or less did that twice in the past... one employer said "jog on"... then 6 months later closed their office. One, gave me the power (and more importantly the backing) to sort it out. 6 months later our turnover is up threefold, though I can't claim anywhere near all of the credit there, there are other reasons at play too. But at least it's a turnaround.

Collapse
tomcools profile image
Tom Cools

I have to agree with Dave here. I've also been in projects like this and I have burned out in part because of these 'fixed unrealistic deadlines'.

Now I make sure the teams are as efficient as they can be, with the power we have. Beyond that, my job ends with reporting to management and helping them come up with viable solutions.

But management problems should be handled by management. Don't hesitate to push it to them.

Collapse
190245 profile image
Dave

Not quite what I meant but yes.

In my current situation, I went from Senior Dev to Lead/Architect with Dev Manager thrown in, practically overnight.

Yes, management problems should be fixed by management, but sometimes we (as developers) have to step up and be a manager. Someone has to take the reigns.

I've always said I didn't want the HR headache, and for a long time, that's held my career back. Now I have that headache, and honestly, it's better than being in Mat's shoes.

Collapse
matmooredev profile image
Mat Author

I haven't been as direct as this, no. I can definitely present problems and ask for backing to fix them, but I probably won't go so far as making demands.

So far I've basically been told that everything will get better after this nightmare project has launched and the dust has settled. I am not really sure if I wait that long though, given the amount of organisational chaos surrounding it. Our CEO is on his way out so any promises made now could be reversed as soon as the new one comes in and we change direction again.

Honestly I'm just looking for some stability and control over my work. I don't actually want to go down the manager path.

Collapse
aminmansuri profile image
hidden_dude

I haven't seen this sort of failure in recent memory.. mainly because long ago we adopted the philosophy of giving developers the power to estimate and set targets. It doesn't make everyone happy, but it makes us able to meet targets.

I think if your management is so messed up you have 2 options:

  1. Wait for them to fire the manager
  2. Brush up your resume and find a better place to work

If you have no patience or hope I recommend #2. Why sink with the ship?