Convincing "agile" managers of the value of planning

Question

Became tech lead of a startup a few months ago. Even by startup standards the codebase is poor, I don't feel any pride in working with it.

Example: the dev team took three weeks to update static text in the footer of the site and even then they gave up after 80% of the pages. Updating the footer's 'reusable component' breaks some of the templates, they can't tell why, even though they've been working with the code for months. The original contractors are of course long gone and left no docs behind.

I've gotten buy-in to clean stuff up, write stuff down, and reduce technical debt. But, of course, first we have to build a new feature, which will take at least two sprints, involve the whole stack, and used as a basis for bigger features. The codebase seems full of abandoned, half-finished features, so I got buy-in for one of the devs to spend five days exploring the code and coming up with different approaches, rather than just going with the first idea in someone's head.

On day three of five, product manager asked the dev for progress - short answer was "here are some things we could do, but haven't a clue which are any good yet as the code is a mess, had to deal with a site outage on day two, I needs more time". That evening the manager junked the spike and replaced it with a "prototype", based on one of the ideas. In doing this they, the product manager, made several technical decisions on the spot, pulling rank on me, the tech lead. From this and other incidents, I'm pretty sure the "prototype" will quickly end up going live, after a quick "does this look OK to you?" test on the dev's Macbook.

I get the whole "agile startup" thing. I get the relaxed attitude to risk and the need to get something, anything, into the hands of users last week, and worry about the consequences later. I don't mind having rank pulled on me.

But this seems the worst case of "Agile means make it up as you go along, learning from our mistakes is for losers!" I've seen. I was explicitly told "we're a startup, we're not into this investigation ****". "Research" was spoken like it was a dirty word.

Old hands may spot this is a classic case of the product being poor because the processes are poor; possibly from the org culture being poor.

How can I convince the manager there's value in some planning and forethought? Or, perhaps, should I be convincing myself that this is what this agile startup "should" be like, swallow my professional self-discipline and pride, and roll with the hacking?

Answer 1

Money! Try explaining that every unfinished feature, every untested add-on takes away more man-hours that have to be paid. Startup or no startup, piling up problems is never the way to go.

Try making an example case of how you would organize fixing a specific problem and present that to the management.

Answer 2

I think that if they want to work this way, they need to understand that they're taking on technical debt, and features will get more expensive and the whole system will become unstable and buggy unless they invest time in refactoring.

Sometimes the biggest unknown is what the customer really wants, the easiest way to discover it is to deliver a prototype. You try something, and probably throw it away in a month, not because it was badly written, but because nobody really understood the requirement.

Try analogies - a restaurant can cook faster if they don't bother cleaning and tidying, but after a while they can't move for dirty dishes, and before long they get cockroaches and the customers get food poisoning.

Try estimating how much longer each task took because the existing code is a mess.

Or, don't give them the option. The restaurant doesn't give you the option of a meal on dirty dishes. Everyone refactors messy code as they find it, and it's just part of the cost of the feature.

Or, you continue as you are and hope someone buys the company before the code becomes unusable. If you can predict how long this will take, it's a workable strategy for a start-up.

Answer 3

Ah Agile, the notion that you should build a toilet before figuring out whether it is going in an outhouse in a forest or the bathroom of Bill Gates.

I have seen startups do this successfully, but that was when there were 1-2 original developers who wrote every single line in the codebase. You could give them the url of an error as well as the error itself and they would instantly know where to look for the problem. You are starting off with contractor code and the contractors are long gone.

However, as soon as they moved to 3 people, especially if that third was an outsider they had never coded with before, they had to start documenting and implementing processes. Two programmers on a team are effectively a pair as long as they are communicating. Three leaves gaps.

You seem to be well beyond that stage.

In particular, this line is worrying.

Example: the dev team took three weeks to update static text in the footer of the site and even then they gave up after 80% of the pages. Updating the footer's 'reusable component' breaks some of the templates, they can't tell why, even though they've been working with the code for months

You cannot easily update static text a footer? Even basic HTML/React components are so badly put together that they break if you change the text? And it doesn't change all of them?

I think this should be at the core of your case to management. A static footer change should take all of 5 minutes. While you have not spent the entire three weeks on it, even spending 2-3 hours on it is absurd.

I would find 5 features/updates in upcoming sprints, give a number for how long they should take, and then track how long they actually took. Translate that into dollars based on your salaries.

Even a non-technical product manager should understand that a footer change should not be overly difficult.

One day your code is going to crash and you won't be able to find the problem. Depending on what it is your company does, that could be lethal. You have to estimate this risk for yourself, I would keep my resume ready for expeditions into the unknown.

Answer 4

In my experience, asking for refactoring time in the only purpose of refactoring, just isn't working. It will always be at the bottom priority of your PM, and there is no reason it should be otherwise: it doesn't bring cash, and a startup usually have very, very tight cash flow. Additionally, refactoring a code you didn't write and don't master, is very difficult thus expensive. And on top of that, you can't guarantee the new version won't be obsolete at some point.

However, as a technical lead, you have your word to say on development processes. In order to fight technical debt, and also to fight some of the bad development conditions you have (not having code knowledge, not having proper Q/A, being interrupted and scope changing), you can orient the development team to focus more on quality and knowledge acquisition:

• Inflate estimates on feature development to include tests, fighting with codebase, (minimal) documentation and refactoring time.
• Educate developers to best practices through e.g. reviews or pair programming
• Test manually and automatically, without asking for PM to do so.
• Don't ask for any hire, and oppose hiring. Hires need to be trained. You have neither time or code expertise, just don't for now.
• Try to resist scope change if possible.

Make sure you have conditions to refactor small things that you identify needs to be rewritten on your way to shipping features, and that at least new code is solid. This is a leaner way to handle change, and make sure that eventually the team will master most of the code, will ship faster and will identify more precisely necessary code rewrites.

Answer 5

The team appears to be unable to work Agile. Agile works with the right people, a good tech lead who is able to give clearly defined goals/tasks to junior staff, and you have good review processes in place. Drawing on history of failures may be good enough circumstantial evidence for some change. You may be most successful if you pick one area of the development cycle and change only that via a new process, rather than attempting to demand complete process change. My thoughts with the limited information available: it looks like no one in the team is a domain expert in anything, they all do a bit of everything? Perhaps change this. The code also appears to be badly written. Why? Is there a code review process? even if the developers are inexperienced, reviews should catch it. Have to draw the line on reviews and not let bad code go through for time sake. Letting bad code commits is not Agile.