Let’s get the obvious out of the way first. Here’s what the software development process used to look like:
Under the traditional Waterfall approach, the above process could take a year or more for complex projects. The plan looks good on paper, true, but in practice there’s a secret, final step:
You hope that the software you had in mind at the beginning of the process is still useful and relevant at its end.
The risk of releasing irrelevant software after months of work is one reason why you’re much better off opting for Agile, iterative development methods.
We’re not telling you to immediately switch to a framework like Scrum and employ all of its rituals and ceremonies, though we’ve seen success implementing such practices ourselves. If you’re interested, check out our Scrum introduction. (And if you’re sceptical, here’s our response to common Scrum criticism.)
So Scrum may or may not work for you. But at the very least you should consider minimizing the risk of developing unnecessary features and creating a product that completely misses market expectations.
Tackling development in sprints of 1–2 weeks lets you avoid that risk. It also helps direct work to prioritize features that are most essential. When you analyze and provide feedback on new features regularly, you can make sure development stays on course and fits your expectations.
Moreover, it helps you tackle changes in the market and the environment head-on, as they happen. This way, you can accommodate both changes in the scope of your project and changes in external conditions.
Let’s move on to other features of a successful software development process.
You can start by asking yourself: how do you manage the quality of your code?
It seems like an expensive proposition to allocate a significant part of your budget towards quality assurance. Employing manual testers generates additional costs, and automated testers can be even more costly than that. You may even be thinking that cutting back on testing time gives you more resources to develop more code.
But the costs of sending out bug-ridden software are higher. Losing customer trust carries a much heftier price.
This is why it’s worth it to make room for testing from the very beginning. This is especially true for automated tests, which can help you monitor small fragments of your software and make sure they stay functional as you scale. (For a detailed write-up on the advantages of automatic testing, click here.)
We like to follow the “four eyes principle,” meaning that each piece of code should be examined by at least two people. Helping ensure the quality of the code is just one benefit of this approach. Another advantage is that you make sure that you won’t lose knowledge about how and why the code works if the developer leaves your company (and developer turnover can be pretty high).
To take your QA to the very highest level, you should also consider adding a position akin to a Service Delivery Manager, who oversees the entire process of development, making sure the testers and developers work in harmony.
The world of software development is innovating at a rapid pace. With every new tech conference and event, new technologies and frameworks are released or rising to prominence.
This makes it all the more crucial to keep the skills of your developers up-to-date. Invest in training and consistently push your developers out of their comfort zone to make sure they can tackle the challenges of tomorrow.
Pay special attention to developers who are in “maintenance mode,” hunting for bugs in old code or providing DevOps support for legacy solutions. It may turn out that their skillset is stagnating.
If there’s one area in which this advice applies to the greatest extent, it’s cybersecurity. Perhaps you can get your tasks done using outdated web frameworks—but outdated security measures may compromise both your company’s data and the personal data of your clients.
Investing in the skills of your developers may increase your operational costs to some extent, but the effects of falling behind could be even more damaging. Keep this in mind when making your next budget decisions.
Your developers’ time is precious, and your role as their manager is to protect that time and make sure it’s utilized in the best way possible.
One way to ensure this is by taking steps to facilitate communication. There’s nothing worse than having poorly developed (or overdeveloped) features in your software that could have been avoided if there had been more understanding between the devs and the rest of the company.
You can start by introducing quick daily meetings (20 minutes tops) during which the developers can synchronize their efforts and report any potential blockers. Coupled with communication via Hangout, Skype and/or Slack, there’s a much smaller chance for misunderstandings to occur.
One tactic that we’ve found effective is having a single point of contact between the development team and stakeholders in the project. This practice helps especially in the cooperation between a software house and their client, but it can also be useful to avoid frustrations with internal developer teams.
With a single point of contact, you always know who to ask for the newest info in case you need a progress update.
Or better yet, hold weekly demonstrations of the new functionalities in the software (see point #1) that you can attend to admire the progress yourself. Make the demo a permanent part of your sprint process and see your communication improve. Demos will help you detect issues in time to correct them well before the software reaches the end users.
I hope the knowledge that Rafał shared with me will help you on your way to become a better manager for your software engineers.
Much of the advice can be summarized as follows: invest early in processes, dev skills, communication, and software quality. You will soon see how much money you will save in the future by avoiding common pitfalls and issues.
There are some issues that are difficult to solve even for the most successful managers. For example, if you’ve gone through the effort of recruiting software developers (perhaps using our guide), you want to put them to productive work.
Let’s say they help you develop and release a great app—what do you do after? Let some of them go, put the rest in maintenance mode? It may turn out that a few months down the line when you’re looking to start a new project, you find yourself lacking resources again, and need to invest once again in recruitment.
Scaling development resources up and down in a flexible way, in a manner that fits your needs, is the number one challenge you must tackle in managing software development. If you could add and remove developers from your team as you please, without the need to go through recruitment, wouldn’t your budget be much more predictable?
Meanwhile, stay tuned for other posts tackling the issues facing software development managers. Got any problems we could help solve, questions we could help answer? Don’t hesitate to let us know in the comments below.