Developing a software product or solution is an ongoing challenge. Some of the issues slowing down your software team are complex and require solutions you won’t read in a blog post. However, there are three easy fix issues that are slowing down your software team, that you can start implementing solutions for today!
- Developers have to make best guesses and assumptions as to what the code should do
- Developers often complete large chunks of work, only to find out it’s ‘not what we wanted’
- Skilled resources are overloaded
- “Developers have to make best guesses and assumptions as to what the code should do” We wait until work is complete to test whether it meets the intended requirements
When developers wait until work is complete to test whether it meets the requirements, we often find that:
- Developers have to make best guesses and assumptions throughout the development process, as to what the code should do
- When it comes time for review, the product or solution ‘misses the mark’ and requires rework
- Over time, the time lost to rework and additional reviews accumulates
A simple solution to this issue is to implement an approach where a ‘test’ of fit for purpose is created before the developer begins working on the code. We call this documented test a ‘test-first document’. This approach provides the developer with a ‘marking sheet’ or series of tests to apply to their work in progress to review whether it is aligned with the intended purpose or not.
When developers use a test first document to test whether their code meets the intended requirements during the development phase, we usually find that:
- Developers have guidance throughout the development process as to what the code should do
- When it comes time for review, the product or solution more frequently ‘hits the mark’
- Less and less time is lost due to rework or additional reviews
“Developers often complete large chunks of work, only to find out it’s ‘not what we wanted’"
When developers are given a project or assignment, they frequently accept the handover, go back to their desk, get in ‘the zone’, and then ‘disappear’ to complete the work. When this happens, we often find that:
- Developers make an error in key choices in the approach they are taking early on in the development process which are not sense-checked until the review stage.
- The product manager often complains, ‘That’s not what we wanted!”.
- Significant amounts of rework are often required (or complete rebuild from scratch).
An easy way to address this issue is to assign smaller chunks of work to developers so that they are delivering smaller pieces of work at a time. Reducing the size of the deliverable reduces the risk of the developer straying too far off track and allows for course corrective actions and realignment before too much time and cost has been lost.
When developers are assigned small chunks of work, we usually find that:
- If developers make errors in key choices in the approach they are taking, these are caught and corrected before they are an issue.
- Product managers more frequently exclaim, ‘Yes! That’s what we wanted.”
- Developers do not have to complete significant amounts of rework, and rarely need to rebuild from scratch.
“Our skilled resources are overloaded”
When a software team has a mixed level of capabilities, and there are one or more skilled resources, we often find that:
- Skilled resources sometimes become possessive or reluctant to delegate specific jobs to other (less skilled) team members. At the same time, other team members often pass jobs on to the skilled resource because they do not enjoy them, or they feel they are not the best person to do the job.
- The skilled resources work queue stacks up and they become overloaded, while other team members have fewer opportunities to practice and develop the capability needed for the job.
- The team becomes stuck in a vicious cycle where the skilled resource becomes the constraint and other team members are underutilized.
This issue can be addressed by putting a bit of time into distinguishing what work can and cannot be shared across the team. Work should be assigned to resources based on who can complete that work with the lowest opportunity cost, not based on who does it best overall i.e. a senior developer may hand over work to a junior developer even though the junior developer will not do as good a job. It seems counter intuitive, but when work is more evenly spread across resources the team’s rate of output will increase.
There may be required qualifications or significant training gaps that will prevent some tasks from being shared around, but you only need to offload enough tasks to stop the skilled resources from becoming the constraint of the team, or overloaded.
As work is shared, less-skilled developers will have the opportunity to work on their skills, and the less loaded senior resources will have time to guide and mentor them. This results in a more versatile team.
Solving these three easy fix issues that are slowing down your software team may seem too easy to be true, but the productivity gains will quickly stack in your favor. When developers have less rework, and work is resourced across the entire team, you’ll be shocked at the increase in output you can achieve.
WHAT YOU CAN DO TODAY TO INCREASE THE PRODUCTIVITY OF YOUR SOFTWARE TEAM?
Every day, you strive to maximise productivity. You have more developers but project completions are even more behind.
You do your best to control costs by balancing dev capacity and skill but you have to fight fires to get jobs out on time—and firefighting costs money.
You create project plans to ensure projects run effectively—then customers request off the plan features or demand urgent patches.
The fact is, the market is chaotic. But your business should not be!
Your FREE copy of Pace Invaders: will show you how to quiet the noise.