Ask HN: How to deal with un-agile agile development? | Hacker News Reader

Ask HN: How to deal with un-agile agile development?

4 pointsbaalimago5 comments

We have a giant slow, highly coupled monolith which is unfriendly to work with (to say the least). And on top of this, some new management has decided to fully adapt agile development, which means user stories.

I were originally hired to help microservicify and modernize the monolith so that we could diversify the workload and scale development horizontally. This started off with stabilizing the monolith and get rid of any bugs, so that it later could be deprecated. But I don't really see a way forward now with these new strict LeSS ideas:

* We can't develop new features on the monolith since all the hacks and duckttape over the past 10+ years has made it impossible to make any reasonable progress (management is very clear that we'll add nothing more into the monolith)

* We can't microservicify or refactor the monolith since it wouldn't add any value in the form of a user story (the functionality already exists, after all)

* We can't develop new features as microservices since they lack the underlying infrastructure (all state is still owned by the monolith)

I wish the best for this company, but the current direction is so frustrating I simply wish to move on to some other company which allows for higher velocity, in any direction. Any advice?

You are going to have to modify the monolith to open up access to the state via an API.

If there is a new feature X to develop and want to put it it a microservice what you do is carve out a small part of the system that would include X into a microservice, replicate the function of that subsystem and add feature X. If you always think of refactoring as the short path to implementing a feature (at some point it is) there is not a conflict between refactoring and putting features in.

The idea that every change has to come from a user story is a toxic idea in project management that will kill your project. The fact is the system has needs of it's own that have to be addressed if the system is going to take care of the users. For instance nobody begrudges that the server has to be plugged into the wall or that an employee has to go to the hospital if they have a heart attack.

You get pushback sometimes when you have a complaint that "the build takes 40 minutes", they will ask, "how does fixing that benefit the user?" and you reply "if we made the build 10 minutes the user would have had the product six months ago and would get features four times as fast".

Somebody has to hunker down and be an advocate for the system.

This. I think the technique is called the (monolith) strangulation pattern.

WRT Agile, you need some tech debt stories to break open the monolith and set up for strangulation. Then some more stories to pull out a part of the monolith that is likely subject to the most product-driven feature evolution.

Then, and only then, will you be able to entertain small feature increments from product owners.

Tell them you'll need to earmark 20-30% of each sprint (or every 4th sprint) for tech debt / refactoring

If you're in the right position, advocate for agile as a target and not a thing you declare and suddenly are. You become agile, and maintain agility, but you do not just switch to agile.

For working with the code, you may find Michael Feathers' Working Effectively with Legacy Code helpful. I definitely learned a lot about cleaning up poorly (or badly) modularized old code with few tests from that book. It may help you find ways to improve the monolith, replacing the hacks and duct tape, in ways which enable micro services (if they're appropriate).

> but the current direction is so frustrating I simply wish to move on to some other company which allows for higher velocity, in any direction. Any advice?

Maybe find a company that better fits your ideals?

Trying to reshape management culture from an IC position is an uphill battle, to say the least. Either embrace what they’re giving you and do your best within it, or move on to some place that fits better. You’ll never find a perfect fit, but you also don’t want to be stuck somewhere if it’s just making you more and more disgruntled.

Sometimes, the company is right, but just goes about it the wrong way. Why not stay and help them? You'll get great experience managing what could be a disaster! I know, we like to design everything pixel perfect on our screens, but the world is not like that. Errors and mistakes are why we all have jobs.

Reply on news.ycombinator.com