Your Web News in One Place

Help Webnuz

Referal links:

Sign up for GreenGeeks web hosting
November 21, 2020 12:40 pm GMT

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

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 .

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


Original Link: https://dev.to/matmooredev/rant-big-failing-software-projects-are-a-failure-of-leadership-not-software-developers-91f

Share this article:    Share on Facebook
View Full Article

Dev To

An online community for sharing and discovering great ideas, having debates, and making friends

More About this Source Visit Dev To