Nearly every embedded software team I encounter is interested in becoming more agile. Adopting Agile practices can dramatically improve how agile a team is. Businesses and developers all want to be able to deliver faster. We don’t want the headache of late and buggy code, yet we often just accept that is what life is in the software world; However, it doesn’t have to be that way. In this post, we will explore five tips for becoming more Agile.
Tip #1 – Ditch Code Review, Adopt Pair Programming
There is a big push within the software industry to do more code reviews. Studies have shown that code reviews are the most effective way to identify and remove bugs. However, there are a lot of problems that are encountered with code reviews! First, developers don’t want to do them! They are viewed as time-consuming, boring, and generally get in the way of getting real work done. I’ve encountered teams where they know they should do more code reviews, but the idea of reviewing 400 lines of code per hour (the industry recommended pace), is a snail’s pace when there are 10’s or 100s of thousands of lines of code that need to be reviewed.
A simple tip to make software development more agile is to ditch most code reviews and adopt pair programming instead. When two developers are working together to write the code, they will be performing a code review while the code is being written. The result is that mistakes and issues are often caught immediately, removing the need for boring team code reviews. Larger code reviews can be saved for mission-critical code, saving the software teams many headaches, and helping to make them more productive.
Note: This is a controversial idea. Studies show that you should be performing code reviews to minimize bugs, in fact, they are the most effective way. However, I come across a lot of teams that do too little to be effective, and if you’re going to do little to nothing, then you’ll benefit from pair programming.
Tip #2 – Automate Testing
If you took a moment to examine the many different Agile practices that have been defined over the years, you’ll notice that a critical one is testing. Software developers are notoriously bad at testing, and therefore many disciplines focus on testing. For example, if you look at Ron Jeffries Circle of Life diagram, shown below, you’ll find that testing is found in every layer (TDD, CI, Customer Tests). To become more Agile, developers need to adopt better testing practices and make sure that they are automated.
Image Source: https://ronjeffries.com/xprog/what-is-extreme-programming/circles.jpg
Several years ago, I had a simple project that a customer needed to be done. From their description, we decided that having an automated test harness would be overkill. A few simple manual test cases were all that was really needed. A year later, and with all the scope creep that went with it, I swore I’ll never start a project again with an automated test harness. In the beginning, it may seem overkill, but the time and pain it can save in the long run are well worth it!
Tip #3 – Shorten your cycles
One key to becoming a more agile software developer is to shorten your cycles. The idea is probably most obviously seen in the push for Continuous Integration and Continuous Deployment. Developers can break their development into smaller and smaller pieces so that they are able to commit small incremental improvements and features to the software codebase.
I often see embedded developers who will take long periods of time to complete their cycle. They’ll work on several different things at once and commit code that is broken and doesn’t work. In many cases, features can be broken up into smaller, functional features. Those smaller features can then be tested and integrated with an ever-smaller timeframe.
Tip #4 – Don’t become Tool heavy
When teams agree that they will start to use Agile techniques, they often get excited and jump into finding a tool to help them manage their “Agileness”. Unfortunately, when this happens, there is a temptation to dive into a tool and try to maximize its use. Instead of the team developing their processes, the tools they choose force them into a process. That process may fit the team’s needs, or it may not.
Many Agile tools available today can be used by small to large teams, but the tool producer may benefit more from larger teams over smaller teams (think licensing models). When you first start to become more agile, don’t give in to the temptation to become tied to a tool or get to a point where you spend more time in a tool trying to manage things. The tools you use should make you faster and more effective, not tie you done and make it more difficult to work.
Tip #5 – Divide and Conquer
Sometimes, when a team wants to adopt Agile practices and modernize their software development processes, they encounter some developer pushback. Some developers won’t see the benefit of adopting certain techniques or are at a point in their career where they don’t want to learn new tricks. When this situation arises, I’ve found that it can be more productive to divide the team. (It can be tempting to just fire non-compliant team members, but this is rarely effective)
The first part of the team becomes the maintenance heroes. These team members focus on using established processes and techniques to maintain and improve existing code and product lines. They stay behind to fight the battles of poorly architected software, spaghetti code, and so forth. The second part of the team becomes the future platforms team. This team is provided a blank slate to adopt and leverage more agile techniques and processes. The team members are often excited and interested in learning and using new techniques to become more effective software developers.
Conclusions
Many teams today do leverage Agile software practices; however, I’ve found that many embedded software teams struggle with it. In today’s post, we’ve explored a few low-hanging fruits that developers and teams can reach for to become more agile. Take a few moments to carefully consider these tips and how you can apply them to your own software practices.
