To get a sense for how much room for improvement you have in your current process to ship faster by investing in people, take a look at how your team is currently doing in the following categories. These are just a few of the improvement opportunities we'll look for during a consultation.
Long Release Cycle.
If you have a fixed release schedule or a very long testing process, features and fixes may have to wait a while before getting into users’ hands. There are often good business reasons for doing this, but there are also good reasons to change to a more modern approach. Users increasingly expect to have bug fixes (especially security fixes) available right away. Developers feel more trusted and empowered, and ultimately happier, when they’re able to get work they’re proud of into production without delay. And delivering earlier lets your business react faster to real-world feedback and get more value from your investment in software.
If you have lots of tasks in progress at once, you’re putting up with more distractions and more task switching to get the same output. You’re probably also spending more time merging and reconciling work done in parallel as it gets completed. This frustrates developers, and it makes it less clear what they should focus on by reducing the apparent urgency of any one priority. Thinning the pipeline by removing some lower-priority items can produce a virtuous cycle: less simultaneous tasks means things get delivered faster, the business is able to react to feedback and adjust its plans, and some of those items you removed won’t even be needed in their original form.
In a healthy technical culture, anyone asking for changes to the software should feel challenged to break up their request into the smallest possible steps that still create real business value. Smaller deliverables ship sooner, which enables smarter decisions about what comes next without keeping too many resources tied up. They’re much more accurate to estimate, and they have a much better chance of getting finished before business realities change and leave them behind. And when features are divided up in ways that make sense to the product owner, developers gain domain knowledge faster, and can make decisions that better reflect how the software will be used.
Does your team review requirements before starting the implementation? Getting a second opinion about each task before writing the code may be even more valuable than reviewing it afterward, because this can catch problems at an earlier stage when they’re much cheaper to fix. And a review of the business requirements helps to make sure they’re represented in a way that’s clear and logical to developers. This is key to helping developers build domain knowledge quickly and understand the purpose behind the features they’re building.
Does your team review code before releasing it? This is well-known as a great way to catch problems before they end up in the hands of users and become much more expensive to fix. But it’s also a chance to insist on clarity of the code that’s being written: that it clearly communicates its intended behavior, along with the business concepts that behavior represents, to all the developers who will come along to work on it afterward. This kind of clarity is crucial to having a team that feels confident to tackle every new challenge by moving forward, without needing to second-guess and reengineer existing code that’s too hard to work with.
There’s a lot of variation in the kinds of testing software teams do, and in how thorough and disciplined they are about it. But unless you have some kind of safety net in place to ensure that major pieces of already-delivered functionality won’t break without someone being alerted, you’re likely to spend a lot of time scrambling to make emergency fixes. The confidence to experiment and make improvements without fear of causing expensive damage is key to a good developer experience.
It’s helpful to have a trustworthy source of information that developers can consult to find out exactly how the business requires the software to behave. Otherwise, as features and fixes accumulate over time, the business and the software grow to depend on each other in ways that aren’t explicitly recorded anywhere. As a result, developers spend a lot of time figuring out the behavior of the software (and guessing at the business reasons behind it) for each part of the code they visit. This makes domain expertise accumulate slowly, and makes developers less confident that they understand the goals they’re working toward. The ideal would be to record every requirement in the form of an executable test, but at the very least, find some way to keep a record of the most important business requirements of the software, and keep it up-to-date.
Effective code mirrors the business problems it solves. It uses the same terminology, and it’s organized in the same way that a domain expert thinks about the problem. This is a part of tech culture that starts at the top, when project owners set the example of using consistent terminology and breaking down requirements and business problems into separate areas of concern that make logical sense to translate into software. These habits result in code which reflects the way business experts think about the problem, and which quickly builds the domain expertise of all developers who encounter it in the future.
Do developers know where to look to find out exactly what they should be working on? Do they know where to go with questions about the business processes they’re contributing to? And do they know your organization’s priorities for how they should react, even (and especially) in high-pressure situations? All these things should be written down, to keep the team aligned on the same mission, and to make on-boarding fast and consistent for new team members.