5 Tips for Becoming More Agile

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 100’s 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.

Related:5 Tips for Choosing an Embedded Programming Language

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 of the disciplines focus on testing. For example, if you look at Ron Jeffries's 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 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 all the scope creep that went with it, I swore I’ll never start a project again with an automated test harness. At the beginning, it may seem overkill, but the time and pain it can save in the long run are well worth it!

Related:5 Embedded Technologies to Master in 2022

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 into 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 from 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 down 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 to 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.

Jacob Beningo is an embedded software consultant who works with clients in more than a dozen countries. He has published many blogs to count embedded software architecture, processes, and development techniques. He holds three degrees, including a Master of Engineering from the University of Michigan. Feel free to contact him at [email protected], at his website www.beningo.com, and sign-up for his monthly Embedded Bytes Newsletter.