Own Your Development Process.

I recently read an article titled "Agile development is fading in popularity at large enterprises - and developer burnout is a key factor". It discussed that developers at larger companies are struggling to establish an agile development philosophy, while those at smaller companies are seeing their agile development prosper. I think this sounds just about right.

Larger companies face issues with agile which small companies don't have to consider. When a company is large, there are countless areas of ownership. However, each team may only have touchpoints with a handful of those areas. This leads to employees being completely blind to most other parts of the business, siloed to only their area of ownership, plus their dependencies (and internal customers, if they have any).

Large companies also have established successful revenue streams and a clear identity. Naturally, these large companies tend to be less agile and more risk-averse. Planning and executing elegantly is more important than being able to quickly pivot.

The "Agilefall" Mutant

AKA "Fragile"

What the article described is something I've also encountered, which is that large companies tend to use a multi-modal approach rather than committing fully to agile. For projects I work on, I don't frequently work with stakeholders. Engineers don't self-organize. In reality, the business comes up with features, we break down the work and spend a few weeks planning it out, write some design docs, and then spend several months executing implementation. Once that's done, it goes through QA and gets released. We support the launch, hotfix any bugs, and start planning for the next proposed business feature.

That doesn't sound very agile, does it?

It's not, it's far more traditional. But we still exercise many behaviors of an agile team: we have daily standups, we do retros, we groom stories, and execute in sprints. We have the agility to see when a design is wrong and pivot to a better solution without having to uproot the entire project. Our plans are generally designed to promote parallel work with minimal dependencies between milestones. While our projects are long, our milestones are designed to be self-contained deliverables so they at least "feel" and "execute" in a more agile way.

The pain of Agilefall

This process has come with pain points along the way. The planning portion has been historically neglected and underestimated. We've not always been the best at planning milestones to be isolated and lack co-dependency. This usually resulted in numerous projects experiencing the pain of multiple delays due to encountering holes in designs, missed requirements, or generally underestimated tasks. These delays also meant developers had no time to take on important tasks to improve the quality of the codebase or the developer experience, slowing the development process even further. These pain points led to many conversations with other engineers, mostly complaining about these exact issues, and how everything just needs to change. Sure, it's easy to question the entire system in times of frustration. But if there's one thing that I've learned as an engineer, it's that scrapping an entire system and reworking it from scratch is never the right answer.

Break the Silos

We recently had an org-wide meeting, which provided us with insights into how we can better our engineering systems to help us estimate better and deliver high-quality, bug-free software to our customers more frequently. There was emphasis on treating the org not as a set of teams, but as a single unit where we all work together to keep moving forward. It helped me realize that engineers have complete control over our development system, and it's mostly up to us to improve it.

Breaking out of silos, learning what other engineers in adjacent teams are working on, learning from others, teaching others, interacting with the design and product team members to understand the problems we're solving for customers, having more open dialogue focused on improving the customer experience; These are important actions to take so that the organization can move as a cohesive unit. Communicating early, frequently, and with precision reduces frustration and enables us to quickly abandon things that fail and study things that succeed. When we understand one another, we achieve alignment on our goals and move faster.

Leave things better than how you find them

The reality is that we could spend an hour a day thinking and complaining about how slow the test suite for BigSoftwarePackage is, or how component.tsx has a bad design and is horrible to work with, but out of that comes nothing but five wasted hours a week. None of the problems were solved, they were merely discussed. When your first instinct is to act instead of speak, a lot more will get done.

The developer needs to take ownership of tooling and code quality. If there's a code smell in the part of the codebase you're touching, can you quickly refactor it as part of your story? If there's a tedious set of commands you have to run frequently, how about writing a shell script to make it a single command? Have you considered test optimization to reduce the run time of the test suite? There are countless ways to continuously improve upon the developer experience, and these efforts can be baked into your schedule. Spending an hour per sprint on these efforts probably won't harm your velocity, and it will make you a little less frustrated with your workflow. In the long run, it should help increase velocity by removing (or reducing) blockers in the development flow (i.e., code smells, slow unit tests, slow/manual processes that can be automated, etc.).

At the end of the day, you're the engineer. It's up to you to ensure your machine is well-oiled and running smoothly.