You’ve probably heard many times that Agile doesn’t work for embedded software development. Embedded software is unique and Agile techniques just don’t work for software that has to touch the hardware. You might not realize that Agile isn’t about all the techniques and methodologies you often hear about. Agile, as described in the Agile Manifesto, is about improving collaboration within a team and with the customer, delivering working software, and responding to change.
According to a recent survey by Zippia, 71% of U.S. companies are now using Agile. Agile projects also have a 64% success rate versus waterfall, which has a 49% success rate. What you might find interesting is that companies that adopted Agile, on average, saw a 60% growth in revenue and profit! Honestly, I’m not surprised. When looking outside the methodologies, the mindset change to closer collaboration makes it far more likely a team will succeed.
You might want to say again that you and your team develop embedded software, so it doesn’t apply to you. If you think this, you need a mindset change. There are five tips you can follow as an embedded software team to start following Agile methodologies and improve your team’s software.
Tip #1 – Get your head out of the details
The number one problem I often see with embedded software teams trying to adopt Agile is that they get their head stuck in the low-level details. They usually lock up if you ask an embedded software developer to write a user story. They’ll tell you that they can’t do it because that simple story has thirty-odd things that need to be done at the hardware level to implement it. A story might read:
“As a user, I want to set the temperature so that I can keep the spacecraft warm.”
An embedded software developer says there isn’t enough detail because they need to know if the heater is on a GPIO line, a PWM, etc.
The devil is in the details, but the key to adopting Agile techniques, or creating a modern software architecture, is to push the low-level details to later. Start thinking at a higher level away from the hardware. The details will come when needed, but that isn’t during day one or the first sprint.
When adopting #Agile, #embedded developers need to get their head out of the details in order to be successful. Click To TweetTip #2 – Ignore Agile purists
In just about every area of life, you’ll often find purists. These people follow a belief, methodology, or technique to the letter without deviation. Anything that doesn’t perfectly follow the purists’ view is not considered acceptable. For example, I recently ran an Agile SCRUM workshop with a customer who had modified some Agile methods to suit their needs better. A colleague told them that they weren’t “doing Agile”. What exactly does that mean, though?
Folks that claim you aren't doing #Agile usually don't understand what Agile is! Agile is a set of values and principles that a team adopts. Agile methodologies are just there to help the team shift their thinking. Click To TweetAgile has over 40 different methodologies that adopt Agile philosophies and values. You don’t have to adopt any of these to follow Agile. A team needs only to embrace the values and philosophies and implement processes that help them to achieve them. Every team is different and requires a different set of methods to help them be successful. An Agile purist will often tell you there is a right and wrong way to do Agile. I would tell you that IT DEPENDS on what works for you and your team. What works for you will change and evolve. It’s not static; it’s dynamic.
Tip #3 – Start with SCRUM
It’s not uncommon for teams interested in Agile to adopt SCRUM. SCRUM is used by more than 60% of teams. I think it’s essential that you separate the idea that SCRUM is Agile. SCRUM is a methodology that helps teams change their mindsets to adopt Agile values and principles. SCRUM helps teams get a clearer picture of where they are and allows them to interact and collaborate daily.
Daily collaboration is vital if teams are going to respond to change effectively. Traditionally, requirements are tossed over the fence, and developers start to bang out code as fast as possible. They disappear into a black hole and only escape months later, only to discover that everything about the product has changed! (Yes, this is an escape-by-wormhole analogy). SCRUM helps developers interact and collaborate better, which allows them to move into an Agile mindset.
Tip #4 – Recognize you need more than Agile to be successful
Agile can help a team adopt the right mindset to be successful. In addition, agile can provide methodologies to improve collaboration and establish effective communication. However, agile alone will not guarantee that you and your team will be successful. Success requires more than just your mindset and processes.
Agile is not a silver bullet. Just because you adopt an Agile methodologies doesn't mean your team will succeed. Successful #embedded product design requires more than just Agile methodologies. Click To TweetIn 3 Elements to Successful Embedded Software Development, and my book Embedded Software Design, I discuss that three elements must be balanced to launch an embedded product successfully:
All of these elements are required, not just one or two. If you just focus on Agile, you’ll have the right processes in place, but you may not develop a scalable architecture or have the right tools and development skills to follow through.
You need to broaden your view beyond just Agile to succeed. Again, this is a deviation from many Agile purists who claim that if you just follow the process, you’ll have a perfect emergent software architecture and the right skillsets. To be blunt, these things don’t happen by accident. If you want to adopt Agile, consider the broader picture, and don’t let your coach, trainer, or the literature fool you.
Tip #5 – Use Epics to define high-level user stories
An essential concept for embedded engineers to understand when they adopt a methodology like SCRUM is that the user stories they initially write are Epics. An epic is a series of user stories that share a broader strategic objective. Most embedded developers, as discussed earlier, focus on the low-level details first. The story we looked at earlier,
“As a user, I want to set the temperature so that I can keep the spacecraft warm.”
It is an epic. Warming the spacecraft will be broken up into smaller user stories that include items like:
- Low-level drivers
- State machine development
- Message processing
- Etc
Even these stories might be broken up into another dozen or so stories.
Modern software development, especially for embedded systems, starts from the top down, not the traditional bottom up.
Conclusions
Agile is all about improving collaboration, responding to change, and delivering working software. No one should convince you that an embedded software team can’t adopt Agile. Every team I’ve ever met that has been successful is following Agile values and principles, even if they don’t realize it! Agile methodologies and techniques can help a team change its mindset. Some techniques like DevOps and TDD can even impact how you develop software. They might be more challenging to accomplish in an embedded environment, but our tools are always evolving, and what is hard today will be easy tomorrow.
Agile adoption within an embedded software team can lead to greater success. Just remember, Agile is not a silver bullet. Agile by itself will not make you and your team successful. You still need to balance the Embedded Software Triad, which includes software architecture and design, development, tools, and coding skills. However, I’ve used Agile for nearly a decade in my development efforts and with my customers. The values and principles work. The methodologies and techniques evolve and adapt to the team to best fit their needs. If you or your team are struggling to adopt Agile within your embedded software teams, feel free to reach out to Jacob to see how we can help.
