One of the most interesting types of projects we handle at Haught Codeworks is the project rescue. Rescues come in all shapes and sizes, from freelancer engagements gone wrong to products laden with poor technical decisions. The common trait among all of them is the stakeholders are concerned about the direction of the project. Often times these issues are exposed once demand increases for the product and the team is asked to ship software faster. This is the worst time to realize that your project needs saving.
All rescues are different and there is no silver bullet to solve them. This makes these sorts of projects complex and challenging. It’s not simply overcoming some tough technical hurdles or cleaning up legacy code. It involves looking closely at communication, process and team dynamics. There is no ‘one size fits all’ when it comes to these aspects of how software projects run.
Technology is Rarely to Blame
The first observation we’ve made is technology is rarely the issue. This seems counter-intuitive since you often see increasing error counts, performance issues, or system outages that clearly are technology-related. Instead, we see technical problems as the canary in the coal mine that indicate your project isn’t healthy.
When we see lots of technical issues we look further for the potential root causes. The usual suspects are based on poor communication, ineffective process, and improper team composition.
Patterns in Rescues
We notice that there are some patterns we see repeated in these projects that are worth exploring. Before we dig in, it’s important to note that we’ll be scratching the surface on why projects get off track. In the interest of keeping this a blog post length, we’re just looking at several common patterns.
This is the first of the communication patterns that we see and it’s surprisingly common. In this scenario, the product owner doesn’t have regular check-ins with the development team. When this happens the development team continues on with the last instructions provided. The bigger the gaps between the check-ins, the greater the risk. Distrust grows between the product owner and the development team as they’re no longer regularly communicating.
If a product owner doesn’t understand what the team is working on or what sort of progress they are making, that’s a problem. A rescue situation is likely an outcome of lack of regular, honest communication between the development team and the product team.
This pattern appears when a product owner has disengaged and abdicated their responsibility for the product to a project manager. Though this approach can work it is necessary for the product owner and project manager to be on the same page or the project is in jeopardy of needing a rescue. Anytime I see a project manager acting as a proxy for a stakeholder, I get nervous. What’s being lost in translation?
Product Owner Hydra
A hydra, if you’re not familiar, is a serpentine-like creature from Greek mythology with many heads. In this situation, we have separate stakeholders, all with their own objectives and priorities. The result is that the project doesn’t have a unified voice that can guide product development to the same destination. Without this focused roadmap, the project drifts aimlessly between competing objectives making it inevitable that eventually, it’ll run aground.
This is a similar pattern to the product owner hydra. The way we see this manifest is when the product owner continually changes what the goal of a major feature or even the entire product after progress has been made. Sometimes people call this a pivot. Every time this happens, the engineers have to change the software to match, creating technical cruft in both the design and implementation of the system. Do this too often and it’s a recipe for a technical mess. Having a clear focus on what a product is and how it’s going to solve the user’s problem is vital to keeping projects on track.
Lack of Feedback
Feedback is vital in software, at all levels. At the lowest level, we need to know if our code works as expected. When a developer feels a feature has been completed, the feature should go through a review that provides valuable feedback. Did it get reviewed for completeness or does it meet the acceptance criteria the product owner specified? Is it technically sound, following good conventions for how software is developed? Typically, projects in a rescue lack consistent feedback at these levels.
This is a common one for those building an initial product. The product team is non-technical in most cases and doesn’t know if the freelancer they hired is capable of building the complete product. If the freelancer isn’t highly experienced then they themselves won’t realize that they’re in over their heads. It plays out when they build the easy part of the product as expected but the last part gets harder and harder until their inexperience and lack of bandwidth become an issue. One symptom to look for in these cases is the repeated slipping of deadlines even as the freelancer continues to say that things are fine.
One surefire sign of a rescue-in-waiting is when team members start leaving for other projects. This has a snowball effect. Whatever was causing stress or a drop in morale is only going to increase as the developers start to flee. Once enough team members have fled, the business is forced to figure out what’s wrong and call in a rescue.
Growing pains is a common scenario I’ve seen where a product sees demand spike and the business expands to match the growth. Before this, the team was executing well but as they got larger, things start to go awry. What may have worked for a team of 8 doesn’t work for a team of 16. Their original process and communication patterns no longer fit their new size. Some try to force the old ways to work, while others, unfamiliar with this size of an organization, start experimenting with mixed results.
Hitting the Technical Wall
We’ve seen this play out when a development team lacks architect-level experience around systems design and the product hits technical issues that the team did not foresee. A clear path forward is not obvious to the team and they don’t know how to adapt their design. To complicate matters, the potential solutions are unfamiliar to the team and not trivial to pursue. Since the team is not confident about which path to take, it presents great risk to the project. We typically see the team attempting small adjustments that don’t significantly make progress and the velocity of the team drops off. Once the team is provided with more experienced technical leadership, the best solution becomes clear.
Rewrite Gone Wrong
Rewriting an application can be a normal and healthy part of the evolution of your software product. It’s also one of the harder efforts to undertake. It should come as no surprise that when it goes wrong, it’s going to be a rescue. What we typically see is that these teams lack experience rewriting applications and underestimate the scope and difficulty of the project. We also see that they attempt to change too much in the process.
What all these patterns have in common is that the project is on a downward trend. Without some change, things will not improve and eventually, the project will reach a breaking point.
Luckily, these patterns have a source for the issue and they’re all correctable. Once you recognize the patterns playing out, you can get to the root cause and address it. The solutions may not be easy nor are they fixable overnight, but they do exist.