In this competitive era of software development, everyone is keeping a sharp eye on their bottom line. Usually, this involves evaluating agile metrics like user stories. It might even mean cutting employee benefits or perks. There are several ways a business might mitigate the risk of running over budget on a software project, but the only real way to stop it is to consider the source.
How often do you suspect your actual development team of being a major source of budget leak? It may sound silly, but it happens all the time. We want to trust our tech teams, but it’s important to be aware of the dozens of little ways in which software developers can accidentally add a bit of time here and there during the development lifecycle – ultimately adding up to more money spent. In fact, developers are often the largest source of scope creep. Here are some of most common developer budget busters, and what you can do to avoid these sinkholes on your projects.
(1) Bugs
Of course, we start with the most common complaint levied against software developers: “You’re making too many bugs! Why can’t you just write perfect code the first time?!”. While that would be great, it’s just never going to happen. And simply berating your developers sure won’t get your bug count any lower. But it’s true that bugs happen and can often account for an annoying chunk of your budget, so what else can you do?
Consider the need to invest more in code reviews within the software development process. Ensure that team members are regularly reviewing code for one another, no matter their level of expertise. It might initially look like wasted time, but this short-term expense will save larger costs in the long-term. Reviewing code first can eliminate potential problems before your team has wasted any time coding against best practices and needs to go back and fix it later.
Most agile teams will allow for BAs to hand-off business requirements to their developers before they begin programming. This gives them a chance to ask questions, discuss the bigger picture, and point out anything amiss. Maybe you also ought to start having Developer-QA hand-offs before considering the tasks to be complete. As QA is now responsible for that feature at this point, it’s useful to have QA agree that the task is done and ready to be tested before they get started.
In order for any of it to work, all of your team members need to be on the same page about what ‘done’ is. This type of shared language is crucial in the seamless functioning of any team and should be determined together and documented accordingly. Is a feature done when it’s coded? Or is it not done until it’s tested? But what about those inevitable bug fixes? Distinguishing between ‘Done’, ‘Done-Done’, and so on, can be very helpful. For instance, that developer task might be ‘Done’, but it’s not ‘Done-Done’ until the receiving quality analyst has reviewed it against those requirements documents and declared it ready for testing.
(2) Unclear Requirements
Whether the requirements are incomplete, or the developers don’t understand them, a set of unclear requirements is trouble. You leave the possibility for a developer to misinterpret the requirements and/or make decisions on their own. Typically, the developers don’t have as much face time with business stakeholders as the BAs or tech leads do, which increases the odds that their decisions are not aligned with the business’ vision. When this happens, it usually leads to changes that require additional work to undo or redo.
For example, if not specified in the requirements, a developer might believe that when a user clicks the ‘save’ button, they return to the home page. However, it might make more sense for that user to continue to a forms page, as that would be their expected next step. This results in wasted development time to create the wrong functionality and reverse it later.
In order to avoid that and similar scenarios, you need to make sure your process both for creating and handing over requirements has appropriate fail-safes. Your developers should have a full understanding of the requirements before they tackle programming them. Encourage questions as needed after the fact, too. It’s far better for a developer to go back and ask a question about something no one thought of before than it is to make up an answer and hope for the best. Once the team has checked with the business for feedback, it is an appropriate time for suggestions from developers based on their expertise.
(3) Bored Developers
Your developers need to have enough complete (and understood!) requirements to stay busy throughout the development cycle. Just like when they are confused about requirements, a developer left with no requirements will often complete work that will need to be redone or undone. It may sound counter intuitive, but you should consider halting developers entirely when they don’t have approved tasks to work on.
You never want to let a developer get bored because they will usually start making work for themselves. While this is occasionally beneficial, more often this work can end up being useless, or worst case will require additional work to undo. For instance, if your developer has an extra hour to kill and no approved work to start on in the backlog, they might start to invent – without your business stakeholders. Now you have something like a color changing icon that surprises your business owner when you show them. Even if they look cool, surprises in software development are never good! Though this added feature might have only taken an hour, turned out fully functional, and looks great, it’s not what was asked for. That extra hour multiplies very quickly when you account for things like the conversations about the feature, the time to remove it, and the time to fix that extra bug created upon removal. If your developers feel like they have great ideas to improve the end product, encourage them to share their ideas with the business, and let them follow the appropriate approval flow.
The business owner or technical lead can manage the potential for bored developers. Consider forcing developers to sit idle when the work-funnel runs dry. It might be excruciating for your team, but it’s going to save your budget in the long run. In addition, it should hammer home the significance of getting requirements complete and approved by stakeholders. While you manage your team’s scope creep, you’re also driving decision-making on the business side. This is another great example of a short-term cost leading to long-term benefits through behavior modification and culture change.
(4) Agreeable Developers
You’ve probably heard that nice guys finish last – this is so often true in when it comes to software developers! Sometimes with the best of intentions a developer will agree to do “just one more thing” or “a quick, little change” asked by a business or quality analyst. This is often simply done, and an important part of working in an agile or agile-adjacent environment. That being said, it is vital that developers push back on “small changes” if they feel like it’s too big of a task and deserving of an actual change request. That doesn’t mean you need a jerk on your team though – just a critical team player and the right environment for them to speak their mind.
It’s crucial to establish a culture that encourages developers to speak out about what is and is not realistic when it comes to small adjustments during the development stage of the product lifecycle. You’ll also want to check in during your iteration/sprint retrospectives when evaluating your estimates versus actuals (or whatever metric your team uses). In fact, checking regularly throughout the duration of the project is important to catch any extra time your team is spending writing code that you didn’t account for.
You may find that every estimate going over by an hour because of last-minute changes is killing your bottom line. These add up fast! Use this information to identify whether you need to update your requirements process. For example, it might be worthwhile to track in terms of one-hour tasks throughout your project. This allows you to know sooner when you’ll be behind and estimate just how much more time you’ll need to catch up.
Communication is truly key when it comes to keeping your scope and budget under control. Take the following steps to ensure that your own team isn’t inadvertently setting your project back:
- Refine your hand-off processes so that nothing moves to the next step unless it’s really ready;
- Develop a shared language with your team so you can all know when that is;
- Cultivate an environment that allows for developers to ask questions, clarify their understanding, and raise flags when something seems like it won’t fit in the current scope or budget;
- Plan appropriately from the start so that your developers are never sitting idle.
When you have the appropriate resources to complete your project, you have the luxury of fine-tuning these resources to make sure all the gears in your beautiful machine are spinning along harmoniously. Of course, all of these moving pieces mean that this can also be a challenge. Just be sure you don’t avoid paying attention to your developers only to find out that they are inadvertently working against you.