I’ve come across dozens of entrepreneurs and decision makers approaching our company because they want to increase development output.
First and foremost, trying to increase the output is a huge mistake. Sometimes it can be useful for middle managers looking to be promoted, but it isn’t focusing on value. Outputs are meaningless if they are not aligned with business objectives. Instead, we try to encourage our clients to think in terms of outcome.
Second, and this is very hard to explain, sometimes in order to run faster, we have to slow down first. If you have the wrong architecture, lack of automated testing, quality problems or there’s a learning curve, you have to slow down. If you postpone technical debt, it will come back to bite you.
Outcome delivery speed depends on the following things:
- Code Structure and Architecture
- Automation (testing, environments, etc.)
Each one of these can be approached in different ways, but if we have all four things aligned, we can produce exponential results. I’ll go over my vision for each one of them, and how they affect the results of a project.
I won’t dive into the details of how a team should be composed, but there’s no doubt that a good team is by far the most important aspect. You can’t have exponential results with junior developers. You can’t have high productivity if your team doesn’t communicate properly.
You need a team that’s the right size, with the right experience, and in a collaborative environment. More team members don’t necessarily mean more speed. Nine women can’t make a baby in one month.
The clients and stakeholders are also part of the team, and they play a key role when it comes to team productivity. Clarity, transparency, clear goals and good communication are essential.
For most projects, most clients, most environments, Agile is a no-brainer. It can produce way more value than any other development process. However, Agile is not a solution for everything, and even under its umbrella, there are multiple flavors.
I won’t go over the nuts and bolts of an Agile process, but I have some general advice:
- Focus on outcomes, not outputs.
- Create a collaborative environment inside your delivery team and also within your relationship with the client.
- Run structured retrospectives at least every 2 weeks.
- Keep your team informed about business goals, brainstorm technical strategies to achieve them and push back when necessary.
- Don’t create an order taker culture. Empower your team to find solutions with the clients.
- Keep 100% transparency.
- The process is a tool to generate something. Keep polishing this tool and adapting it to your project. Don’t create too much bureaucracy but don’t let anarchy take over.
Code structure and Architecture
Architecture is a very open concept, and everyone has their own definition of architecture. For the sake of simplicity, I am focusing on a few key points:
- Code structure and components: a clean, semantic, well-designed code structure will make your development process run faster. You’ll generate fewer bugs and generate less technical debt. I’ve seen that for most projects, an API-based architecture will evolve better to a maintainable code. One of the main reasons is that it will help your team members to specialize in one specific component (frontend, backend, etc.).
- Code quality and standardization can be driven by the process too. You can have static code analysis tools, continuous integration processes and code reviews with specific guidelines. This will help a lot.
- Know where you stand in terms of scalability. Sometimes you have to slow down the delivery of features to focus on bigger changes (like integrating a different kind of database or cache servers). Preparing to scale from the very beginning is the key to running efficiently. Even if you don’t have everything built from the beginning to avoid overengineering, you need a plan to execute once the platform starts scaling. This can be reviewed and changed, but doing the exercise of thinking it through is very valuable.
- You need metrics everywhere. You have to know how the users are using your app, the health of your web servers, database servers, alarms, etc.
This is a catalyst for everything else. Automation is what glues everything together and speeds up all those things that don’t need human interaction. We have to continuously think about what else we can automate. This will save a lot of our time, letting us invest it in more valuable work. It requires worth, but it has a huge ROI.
With automation, you can:
- Communicate better by triggering delivery of important information. For example, the new code merged into the development branch or new version deployed.
- Test your application without the need of humans. You can run automated tests every time you write some code and make sure that you don’t have any regressions. Writing test code can also help you think through edge cases and make your platform more robust.
- Easily create environments for developers, QAs, stakeholders, etc.
- Manage servers, deployments and even scale automatically.
- Analyze your code and make sure that it meets the standards you want to achieve.
- Run performance tests, making sure that the code doesn’t have clear performance problems.
To pave the road for faster development, we need to have a good team, a great (and self-improving) process, the experience to create the right code structure and architecture and rely heavily on automation.
Any other variables, like pushing the team harder or working overtime as a habit, will only hurt the quality of the outcome, confidence of the team and the long-term viability of the platform. The client is as important as the delivery team and facilitating their journey to become a better product owner is part of our work.