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 developers 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.
Much of the advice above can be summarized as follows: invest early in processes, developer 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?
Whenever you’re managing a team of developers, productivity problems may occur.
Productivity may be an overused word these days. But in the end, aren’t we all looking for results?
Hours of development work don’t come cheap these days—and yet when you ask the team about progress during a Sprint, it’s almost always a disappointment.
And you have no idea why. You’re sure more could be done. You miss your deadlines and have to explain that either to your clients, your superior, or both.
It’s a common situation—but it doesn’t have to be your reality. It is possible for you to call your developers and hear that everything is done according to the schedule. They might ask you eagerly for more work or they could get done more than you expected.
How can you reach this productive team nirvana? Here are 5 practices that will help you manage your developers better.
Clear, concrete and transparent goals are the most important factor of every successful project. And yet, only 1 in 10 teams successfully executes their goals. Usually teams spend much more time on HOW to do things instead of WHY they want to do it.
This usually results in implementing unnecessary functionalities or causing huge refactor efforts in a freshly delivered release. It also undermines the team’s motivation and engagement.
Productive teams are focused on the “why.” They ensure that their goals are well-defined, known and understood by everyone. Productive teams work with their Product Owners/Stakeholders to understand the value of the envisioned features.
In the world of rapidly changing technologies where specialists are worth their weight in gold, a team built on solid cross-functional foundations is fundamental for every successful project.
It’s a rare situation where Sprint tasks can be ideally mapped to the core skills of your team members. There are always too many or too few tasks for either backend or frontend developers, or the amount of work on test automation or manual tests sometimes exceeds the amount of available testers.
Competences bottlenecks tend to happen from Sprint to Sprint and cause Sprint leftovers.
The key to solving this is to build teams with T-shaped skills. The T-shape is an abstract to describe someone with deep vertical understanding in one area (such as backend development or test automation, etc.) but also with broad, but usually not deep, knowledge in other areas.
Imagine a Python developer who is great at using the Django framework but can also do a little bit of frontend and create basic E2E automated tests—that’s a T-shaped team member.
T-shaped people have a positive impact on the scalability of the team, but more importantly they can eliminate skill bottlenecks.
The most common symptom which may indicate low effectiveness of the team is a high amount of work in progress.
High WIP causes Sprint leftovers. Usually about 60% of Sprint tasks are 70% done and 40% are 100% finished, which may break one of the fundamental Scrum principles of providing a potentially shippable product every iteration (as described in the Scrum Guide). Working on more than one task at a time also requires costly context switching.
Productive teams are aware of the true cost of multitasking and avoid it at any cost. They seek to limit WIP no matter what type of development method they are using. Keeping WIP under control is built into the Kanban and Lean approaches but it can be successfully used in different methods such as Scrum.
Micromanagement is a great way to create a bunch of people blindly following the manager’s orders—but it won’t help you build a team. Total control destroys creativity and takes responsibility away from the team. It also makes the project a “one-man show” without nearly no support from the team.
Good managers use trust as a basic tool for project development.
They value leadership more than direct management. Trust is their secret recipe which combined with transparent vision, a cross-functional team and reliable processes makes them the Team Six Navy Seals of modern development.
Good managers use a no-blame environment to create a spirit of trust. If mistakes happen, they use them as an opportunity to work collectively on the best process solutions for future use.
A development team needs forward momentum. Otherwise, it might fall prey to an old truth, in words you may have heard before:
Fortunately, modern development frameworks have improvement processes in place, such as the retrospective.
Productive teams use retrospectives for continuous improvement. They do not limit the “retro” only to the development process; they also focus on products, the process and improving the attitude of the people involved. The best teams understand the power of small changes.
Keep in mind that the above is just our subjective list of topics. However, we’re sure that if you use it wisely, it will improve the productivity of your teams. We also encourage you to test different approaches and tools on your own.
The development process is much more about people than technologies. If there’s one rule of thumb to follow, it’s this: everything that improves people's interactions will improve their productivity.
Of course, there’s more to learn to get even closer to software management nirvana. Here’s a couple of our articles that will help: