As a software leader, we know you’re focused on three main things: time to market, quality, and productivity. And, after being in business for over two decades, we thought it was time to share some of the secret sauce that leads software teams to be successful in these areas.
Enter, Lighthouse’s 5 Core Software Principles:
Before we dive into each principle, we want to be clear: building enterprise software is hard. There’s pressure from leadership to get it done quickly and with quality, and input often comes from many different stakeholders, resulting in a system that can quickly get complex. It’s no wonder it’s so easy for projects to get off track! So, as you review the principles below, consider the accompanying thought starters. And, if you need to bounce ideas off of someone, give us a call!
1. High Quality software results in lower cost and shorter schedule
Finding defects in early work products significantly reduces future rework in later work products, which lowers cost and schedule. It all boils down to getting it right the first time instead of getting it done fast while allowing countless bugs to leak through (learn more on this here).
We’ve delivered numerous webinars, QA conference presentations, white papers, etc. on this principle of Defects + Delays = Dollars. If you want to know more about this critical principle, check out our white paper.
Thought starter: Is there a recent project – or maybe one you’re currently delivering – that’s over both budgeted time and dollars?
2. People first, then process, and finally tools
We find that many organizations start by purchasing a tool and hope it’s a silver bullet, but, in reality, your staff has the biggest impact on productivity and quality. By far! In our research, we’ve learned that 65% of a team’s productivity is a result of the right people with the right aptitude and attitude, 20-25% are from consistent processes and training applied across the organization, and only 10-15% from tools and technology. You can’t build enough processes to protect you from poorly performing people! And, frankly, who would want to?
Once you have a competent, motivated, well-trained team in place, they will clamor for some consistent processes. Focus on thin processes and then train them so your staff can easily move between teams. You can get some great productivity with simple tools like Excel and Jira. And, be sure that your team can do the job manually before you start to implement tools. Going to tools too fast can result in large amount of churn and re-work (think garbage in, garbage out).
Thought starter: Where might you readjust your time and money in order to invest in your people?
3. Smaller systems have higher quality
A smaller system means your team has less to focus on in order to deliver it with quality. Agile helps tremendously here because it forces teams to select a small amount of functionality to get completed in a couple of weeks. Our industry data shows that Agile teams produce more code, and higher quality code than non-Agile teams (or Wagile teams). As it turns out, smaller is not just better – it’s actually exponentially better! If you are having difficulty getting your leadership bought into Agile (or small iterations), reach out and we’ll gladly share the industry data showing the exponential benefit of small systems.
With small, quickly-delivered functionality, the team learns quickly and can apply those learnings on the next Sprint.
Thought starters: Are you fully Agile, still waterfall, or some mix of Wagile? And, do you do retrospectives after each Sprint such that your team is learning and improving as they move forward?
4. Small teams of highly competent, motivated, and empowered people flourish
Let’s dissect this one. First, skill matters. However, it can only take a team so far if the culture is holding them back. Skilled teams thrive the most in a culture where they feel empowered and trusted to do their jobs.
Finally, a smaller team means less lines of communication, therefore decreasing the risk of miscommunication. To visualize this, let’s look at the formula: x(x-1)/2, where x is the number of team members.
When there’s 2 on a team, there’s only 1 line of communication.
But let’s say there’s 5 on a team; now there’s 10 lines of communication!
Or even 10 people on a team could seem like a small team, until we map it out and now there’s 45 lines of communication!!
Even if your team is fully competent and highly-motivated, you can still have miscommunication because of the complexity in larger teams.
Thought starter: How might you adjust your teams to streamline communication?
5. Simpler systems have higher quality
There’s a design decision to be made when it comes to complexity. If there is less complexity to the system, there will be less confusion on what the system needs to accomplish. Therefore, when designing, we recommend measuring and limiting the McCabe cyclomatic complexity (the number of branches in the code). Tools exist that measure this, so if you’re curious about where your system is in comparison to success benchmarks, let’s chat!
Our experience shows that approx. 80% of the system bugs exist in the most complex modules. Kind of makes sense, doesn’t it? If a developer goes in to fix a bug in a complex module, they are much more likely to break something else.
Thought starter: Are you measuring your complexity as part of your CI environment? Are you requiring code to get refactored once it exceeds a high-risk threshold?
When you adhere to these principles, quality increases, cost reduces, and schedule reduces. Remember: Defects + Delays = Dollars.
At Lighthouse, we exist to help you deliver smaller, simpler systems with smaller teams and higher quality. Which of the above core principles could you and your team improve? If you’re not sure, or maybe you know where you want to improve but you’re not sure how, shoot us a note! We’re always here to help.
