How to improve our developer retention and development output?

Question

I am a mid-level developer at a small company of about 15 people, and I am (aiming at) leading a team of 3. I am concerned that my team suffers creeping disinvestment in the project and company overall, for understandable reasons. Our company is failing to build a developer friendly environment, partly because of human resources problems, but in my opinion mostly because of project management problems. To be fair and square, I stay because I like difficult challenges when it comes to fixing what's broken. Recently, there also have been some change in the C level mindset that make me feel optimistic about suggesting change.

Speaking here just of our team of 3, we have responsibility over maintaining a codebase of just over 150.000 lines of code, representing basically the backend of a single product with sub services. As an example of our technical debt, over half of this code is written in deprecated language version (Python 2.7) and the tasks to migrate to newer versions have planned for over a year and spread out over 6 months; we yet haven't managed to successfully push it. Our last sprint was half full of bugfixes, which isn't unusual. Our code crash often and many of these crashes don't even reach the backlog. I introduced unit testing, but our coverage is low and not improving. We have systematic reviews, but they are not efficiently finding defects. We are pushed to release early and often, but it may require synchronization with other teams to release in sync and that alone has caused much trouble and discussions. It takes several minutes to test and our continuous integration bot responds in 2 hours time, with results sometimes subject to interpretation.

We use Scrum terminology, although we do not implement Scrum entirely. We have the rituals, but many freedoms are taken with the work organization - from urgent crashes popping in the sprint, tasks specified mid sprint, no Scrum master, and more. Developers reported the CTO to impose technical preferences to them despite their objections about it being optimal.

The previous lead asked for a team swap, someone working on a branch of our team is in sick leave (and I know this is work related), someone left before, and someone plans to leave in January. All of this occurred in just our team, over a 2-year time span.

There are contextual explanations to this catastrophic scenario, in the history of the company, in the specificity of our product, in the lack of experience of our managers when it comes to managing software projects, and in the disinvestment and spite of developers themselves; but I am more interested in solutions than analysis, following the axis of 1. developer retention and 2. development value output:

• I would like to put the nose of the management in the problem, but I have no idea what to bring with me. What are good measurements of where we are and how much we improve?
• What are good pointers in terms of project management for a similar situation? I'm not looking for a shelf solution like Scrum, but more like guidelines and small incremental changes to the organization that might lead to improvement.

Answer 1

If the people causing developers to leave or underperform are not under your control and are not listening to you, you can't do much. Urging developers to stay against their own interests will not work.

You can't fix bad management from below.

Answer 2

As the question stands, it's really broad, as you're covering several different aspects such as "how to handle tech debt", "how to handle bugs mid sprint and also here", "how to motivate developers in such an environment".

There's no magic bullet. As Cornelius Fichtner reminds on his PrepCast, we must eat an Elephant one bite at a time.

There's so many items around motivation (your item #1) that there's a specific tag for it and it's really hard to pinpoint something. In any way, worth learn more about how Intrinsic motivation works.

For value delivery (your item #2) You'll need to use a common language between C-level and the development team. The 4 Key Metrics offer a simple albeit powerful set of aspects to measure, understand where you are and where you want to go.

Besides, in such a complex (and potentially frustrating) environment, I'd suggest to dedicate some attention not only to observe where you are now but on the trending over time. You may have 5% testing coverage today and this might be really frustrating... but you have to think that last month you had 2%. The trending (and most importantly, the positive trending) is a real motivator. When talking to the development team, you might want to show the uptrending rather than raw numbers.

Either way, setting expectations is key - everyone must be aware the team will need to take one step back (i.e. reduced or no business delivery for some time) to be able to take some steps forward in the future.

Answer 3

What are good measurements of where we are and how much we improve?

From a Kanban perspective, I'd suggest lead time, and from a Scrum perspective, I'd suggest velocity/throughput. Lead time is the amount of time it takes to get a piece of work from 'just started working on it' to 'ready to go live'. Velocity is how much work you can accomplish within a given time period. Really, these are just two separate ways of visualizing the same thing. It might be useful to have separate measurements for both, though, depending on your management's taste. YMMV.

What are good pointers in terms of project management for a similar situation? I'm not looking for a shelf solution like Scrum, but more like guidelines and small incremental changes to the organization that might lead to improvement.

Frame challenge: You should be looking for a shelf solution... for now.

Check out the Shu Ha Ri mentality. The first step, Shu, is where you follow a guideline/process/coach precisely. You don't need to worry about understanding the why in this stage - you just need to concern yourself with the what and the who and the when and the how.

The second stage, Ha, comes in only after you have mastered following your process by the book. Once you've completely mastered the process's mechanics, then you start asking 'why' and start trying other, related processes (e.g. ScrumBan), start tweaking the variable parts of your defined process (e.g. Sprint length).

Then, finally, the Ri stage is when you've mastered the what, who, when, how and why. At this point, you can start making whatever sort of changes you think are necessary, based on your understanding.

Trying to jump right into the Ri stage is how you get this.

That being said, if you need to, feel free to start with incremental changes instead of wholesale - just make sure that those incremental changes are all going towards the precise by-the-book process, because you're still in the Shu stage the whole time. Don't worry about trying to improve on Scrum until you've first fully tried Scrum. Whether that takes one meeting with management with a month of trying it out as-is, or five years of incremental changes.

Answer 4

Well, as a well-seasoned programming expert, I would add that it is entirely possible that you do not yet appreciate the true nature of the technical challenges which your teams might actually face.

Your present language-version might indeed be more-or-less incompatible(!) with the "version of the superficially-same language" in which this system was originally written. Yes, "the foundation also moves."

Worsening the situation is the fact that every application intrinsically relies upon *third-party libraries" which your team did not develop, but which are also obliged to re-adapt themselves to an ever-moving target.

About a year and a half ago now, I had to lead a team through the unpleasant experience of re-engineering a very old (sic...) "OsCommerce"-based system from PHP-5 to PHP-7, literally to give the company enough time to decommission it. We wound up changing about 40% of the total source code in that system ... just to keep it exactly where it was. (And we had to re-tool a great deal of the logic to bypass what some language-designer somewhere had decided was now "deprecated" – or outright removed from the language.

The Python system architecture is more forgiving, but the ugly principles remain: "your system is not the only one at play."

Answer 5

As I'm sure you know, entire books have been written about these topics! I have been reading and presenting about the research literature on teamwork for years, and believe it provides clear answers for you: empower the team to run itself, and focus more on principles (like the Agile Manifesto) than process. These have been shown empirically to improve job satisfaction, reduce intention to leave, and improve measurable performance in the long term. My approach is here (free and open source): Self-Directed Agile.

However, since it sounds like you have been running Scrum for a while, the first steps could be just letting the team adjust the process to better meet its needs. In each Retro, ask the team if it wants to change some part of how it plans, tracks and accomplishes its work. Then let it make changes one at a time. At the next Retro, discuss how that went and how it affected performance (good and/or bad). Then keep, revise, or rescind that change, and decide on the next one. Though this section of my site uses some language specific to my approach to agility, the principles are based on psychology research and thus should apply to any other approach: Customize FuSca.

Answer 6

You can't, because your company is in a death spiral.

It has a fundamentally broken development process and a legacy codebase that needs to be thrown out and rewritten from scratch. This will require significant time, time that won't be generating revenue - and in a company as small as yours, spending that long without revenue will cause the company to fold. No matter what management may say to keep you happy, there is zero possibility they will embark on a course of action that will outright kill the company.

Ergo, the needed time will never be spent and the situation will only continue to deteriorate, until it reaches a point where all of the senior developers who understand the platform have left out of frustration, and the only ones remaining are juniors who don't have the experience to understand the mess they're in. And juniors aren't likely to create good code, especially without seniors to guide them, so the problem will only grow.

Sorry, but this simply isn't fixable no matter how many tests you add. Take a cue from the developers who have already figured this out and left - cut your losses and find somewhere saner to work. This isn't a challenge that you can overcome.