How a software development team can handle management battles

Here’s how it usually goes. A project manager or product owner relays word from someone higher up the corporate food chain that a piece of software needs to be delivered by a given date. The reason behind the date might be known, it might not.

The project manager, in turn, informs the software development team that the code must be delivered by that date. Typically, the software development team pushes back, and complains that the deadline is unachievable for a variety of reasons. That’s when the back and forth starts.

The game begins

The software development team counters with a new, later date. The project manager responds with a sooner date. The two sides continue to suggest dates until finally both parties settle on one to end the negotiation. And even then, the date doesn’t necessarily have any bearing on reality.

The project manager can relay the new date to the power-that-be, while the development team now has an impending deadline that could be possible to attain.

Then the real action begins.

The game continues

As the software development team plods away to make the fiction real, they might work nights and weekends. Many times, the team goes into a forced march where nobody is happy. Finally, the grueling toil comes to an end.

The deadline might be met. If it isn’t, at least the project manager can go back up the food chain and tell a story to the upper management about the sacrifices team made from the extra hours on nights and weekends to get the product out.

Hopefully, upper management is satisfied and at the same time, hopefully, the software development team doesn’t see a mass exodus. Many times, they do.

Sure, there is a type of developer that thrives under continuous pressure and unyielding demands, but most have lives and they want to get back to them. As a result, they look for greener pastures.

And yet, despite this back and forth and the frustration between management and the development team, the sad part, is that it doesn’t have to be this way.

There’s got to be a better way

While the above example looms large on the landscape of dysfunctional software development processes, there is hope for a more humane, productive approach. As with any dysfunction, the first place to start on the road to recovery is to admit that you have a problem. If you’re at a company that plays out far to similarly to the example way of live I’ve already described but it works for you, read no further. You have what you want.

However, if this doesn’t work, maybe you need to admit it and look elsewhere. In most cases, your current employer won’t make a drastic change to its entire operational paradigm. Instead, you’ll need to make the change and move onto greener pastures. However, the trick is to make sure the pasture you move onto is truly greener than the one you’re in now.

Yes, Agile is a solution if you follow it in spirit and practice

So, the question then becomes, what does a greener pasture like? To start, consider Agile Software Development methods like Scrum, Lean or Kanban. The four key values and 12 key principles of the Agile Manifesto should be at the heart of what a successful development team follows. And if there is a company that shadows these methodologies, then maybe you’re in the right place.

The folks that came up with Agile Manifesto recognized years back that there was a dysfunctional and counterproductive relationship between developers and other areas of the business. They understood that most of the issues stem from a distrust of developers, poor communication at all levels of an organization and the predominance of long timespans between ill-defined deliverables.

The Manifesto authors got it, and in my opinion, really did come up with a better way.

The 12 principles offer a way to make software that is contrary to legacy processes. This is the good news. The bad news is that talk is cheap.

A lot of companies out there say they do Agile and do anything but. It’s like a wedding band that says they can play “Master of Puppets” by Metallica only to find that they play a watered-down version of the tune that appeals to old Aunt Ethel. The spirit is lost; the rendition is ineffective.

To really do Agile, it requires a relentless commitment to both spirit and practice. There are companies out there that walk the talk and then there are companies out there that do nothing more than just talk. The trick is to be able to tell the difference.

Make a wise choice when moving on

Before you make the leap, ask those on the ground at the new opportunity what it’s really like.

Ask them how many weekends and late nights they’ve worked in the last 90 days. Ask them about the length and success of their sprints. An ongoing number of short, failing sprints is an indication of my example scenario disguised under the cover of Agile. Ask them how much power each developer has to just say no to unreasonable demands.

Playing this isn’t fun. It never was and never will be. Yet, it’s a game that’s played over and over, in a variety of manifestations under the guise of many “Flavor of the Week” development methodologies.

Many people play the game but never know they’re in it. But, once you do become aware that you’re part of the folly and dysfunction, you have a choice.

You can play. Or, you can opt for a better game, one that allows you to realize your full potential as a software developer in a positive and constructive manner. You can make great code that not only inspires you but inspires others as well.

Or, you can keep exchanging one bad date for another. The choice is yours.