Always Be ... Complicating?

In sales you should always be closing. Or at least thats what Alec Baldwin once said. In software development I guess you could be closing story tickets. But lately I've come to realize that the apparent goal of the business side is to mess with us.

In the days of waterfall developers spent weeks or month generating a design document to explain how they would fulfil the requirements coming from the marketing team. We were given a document just as big that took just as long to create detailing ever single little thing they wanted and in turn we replied in extreme detail. At the end it was damn near impossible for anyone to claim that they didn't know what we were making, how long we expected it to take and how many resources were needed to complete the task. Sure, our estimates could be off. And yes, the landscape could change making the current project obsolete. But it was quite difficult to be a few weeks from release and be in a state of complete chaos.

Then some engineers came up with the concept of Agile. Easy to get started with a project, easy to pivot, and easy to roll with the punches. The only issue is that it seems like the business side of many companies thought this also meant tossing out the long period of requirements generation, research, and design. We dropped the important milestone of accepting a major project and signing off that we understood it. We dropped giving our response in a way that project owners could say "Yes, that would fulfil all my needs." Minimal Viable Product took over where a solid and complete solution once was.

What was even more painful with this transition was the idea that the business side could come in and make demands mid project. Yes, that may have been the point of being able to pivot when changes were required. But the ramifications of this extremely jarring act may not always have been understood. "Drop what you're doing because we have decided on a new UX!" Thank goodness I didn't just spend the last few hours trying to figure out just how to make the design actually fit within our framework that doesn't do things the way you think they do /s.

When junior engineers ask me how I stay so calm under the chaos of our projects I remind them of two things. First, you get paid regardless of how much they change things. If you're hung up on the idea that you'll be creating this work of art then you're in the wrong business. In 20+ years of being a developer, the vast majority of the code I've written has been end of life'd or was immediately pulled once I stopped working there because replacing me would have taken a few engineerings. Whatever you write will be swapped out for something new at some point. No need to get hung up on it.

Second, the business side doesn't get it. They don't understand how we work. They don't get how a single meeting at the wrong time can derail hours of productivity. They don't get that constant change in one area can cause major changes in others. Some of the best managers I have had got it. They tried their hardest to make sure that the chaos that seems small on the business side but huge on ours wasn't as prevalent as we saw on other teams. But there was only so much they could do. There will always be a product owner that wants a flying toaster in the 11th hour and there isn't much you can do about it beyond look at it as another problem to solve.

It's your job to always be closing (stories). And it's their job to always be complicating the situation.

$ published: 2023-11-01 22:25 $

$ tags: #rant, #develoment, #agile $

-- CC-BY-4.0 jecxjo 2023-11-01

back