How to be Agile in Embedded?
22 November 2023
Agile has been a software development trend for nearly two decades. Nevertheless, embedded software engineers are often reluctant to implement Agile in embedded projects. What is the reason behind this uncertainty, and is embedded development truly not a good match for Agile? Let’s find out.
How Agile won over software development
The thought behind the Waterfall methodology is as old as human civilization. We see a need, design a solution, document it, and finally implement it. It works with building a house as well as with designing a new medicine. It does not, however, include the possibility to adjust and change the solution. Once designed, the house will be built exactly as the architect planned it out.
Waterfall in software development dates back to the 70ties and was based on an even older manufacturing framework used by Ford in the early 20th century. The assumption that what worked well for designing cars would also work for software development was reasonable in the floppy disk era. Since any new program had to be distributed as physical media, providing users with patches would mean huge costs. Not to mention difficulties with putting additional data into circulation.
However, modern, Internet-centric software development is a process that not only allows change but thrives on it. Ever since we moved from analogue to digital age adjustment has become a critical part of any software’s lifecycle. With the ever-changing digital landscape, new opportunities, and new threats becoming reality every other day, it is not possible to design a solution that will be ever-viable. Evolution has become an integral part of the software lifecycle.
Going Agile
In 2001 a group of individuals consisting of developers, consultants, and project managers published a document that brought a breeze of fresh air into the world of software development. The Agile Manifesto emphasized four key values that would drive how agile teams think about and approach their projects.
The idea behind Agile was to prevent a disconnect between delivered products and stakeholder expectations. With waterfall development taking months or even years to complete, final products were often outdated the moment they hit the market. The user needs that the product aimed to address could change or even entirely disappear before the software could be completed. As a result, the Agile Manifesto emphasizes collaboration in the team and with customers, embracing change and swift delivery of working software.
The concept gained traction in the early 2000s, but the popularity of Agile skyrocketed around 2010-2015 when industry leaders like Adobe, Intel, Cisco, and Lufthansa, among many others, began adopting Agile methodologies. Over time, Agile grew and diversified, with new variations designed to meet the expectations of specific types of projects and organizations emerging.
The core principles however did not change: iterative approach, frequent customer feedback, and openness to change. Suddenly being Agile was no longer trendy, it came as a necessity. Customers simply were no longer open to waiting months for the first sneak-peak of what was being built. According to The 15th State of Agile Report by Digital.ai in 2021 94% of companies practiced Agile in one form or another.
Embedded strong in Waterfall
While software development, in general, moved in the direction of Agile, embedded software development largely continued to adhere to the Waterfall methodology. The common understanding being that Agile is not a good fit for the low-level, hardware-based programming with high complexity that is at the center of every embedded project.
Arguments would be made that only after the software is completed, fully integrated, and uploaded on the hardware, any reliable testing can be performed. Only then will any hardware issues like memory, bandwidth, or timing inconsistencies come to light. Embedded engineers would consider user stories too high level to benefit from, and 2-4 week sprints simply not long enough for tangible progress to be made. Additionally, with low-level features like drivers or kernel components being developed, teams struggled to receive meaningful feedback from the stakeholders.
Most of these assumptions, however, were formulated with specific Agile practices in mind. Many of these methodologies, to define their own identity, would argue that achieving expected outcomes is only possible through strict adherence to them with a religious-like meticulousness. This however is not always the case, adjusting methodology to the type of projects and needs of the team might be very beneficial. Especially with so-called hybrid methodologies, combining features of Waterfall and Agile, on the rise.
How to be Agile in embedded?
Embedded programming can significantly benefit from the agile approach, despite not always being able to adhere fully to popular methodologies.
“Even though embedded does have its unique and special challenges, we can and should benefit from Agile development approaches. Yes, you are special, but there is nothing special about some of the problems we share with non-embedded development. We can learn, benefit and apply agile to embedded.”
Agile embedded software development, 2011, James Grenning
Below you will find a list of areas in the embedded solutions development process that can greatly benefit from Agile.
Stay in sync with your stakeholders
One of the concepts introduced by Agile is the creation of cross-functional teams that are able to perform and complete all necessary tasks. The approach involves assembling a group of various specialists with diverse skill sets collaborating closely, enabling them to solve problems more efficiently and with greater confidence. This is particularly crucial if software and hardware development occur simultaneously through concurrent engineering. With such co-dependent development, both software and hardware teams must remain perfectly synchronized and communicate as frequently as possible.
Close collaboration is a concept that extends beyond development teams.
“In the initial stages, during the development of the project skeleton, many embedded projects follow a process resembling the Waterfall approach. However, as the project progresses, the level of customer involvement usually increases, leading the project to transition towards the Agile. ”
Artur Gdański, Embedded Solutions Manager at Tronel
In the waterfall methodology, the customer would be present in the initial phases of the project to convey requirements, but later on, their involvement would be minimal. On the other hand, the agile approach enables teams to stay in sync with the customer and their expectations. It opens the development process to change, but as a result, the delivered solution closely aligns with what the customer requires.
We shared top tips about successful cooperation on embedded projects in one of our previous posts.
Divide your workload
Epics and user stories are often considered to be too high-level and too simplistic for embedded software development. It is crucial to remember, however, that the function of these artifacts is mainly to support organizing and planning the work. It is not required to include all the details at the initial stages. They will emerge as progress is made.
Utilizing user story-based tasks in Kanban boards or project backlogs simplifies processes of dividing the workload and delivery schedule planning. Optionally, feature-based development or test-driven development (TDD) may offer slightly more tangible and structured solutions for workload division.
In general, people are noticeably more skilled at planning work within shorter time horizons. The key lies not in the technicalities of dividing the work, but in having a clear understanding of what needs to be accomplished within the next 2-4 weeks. Planning will be adjusted after each sprint is completed to accommodate any changes in schedule or scope.
Test on the go
One of the major challenges encountered by embedded development teams is the potential incompatibility between software and hardware. Even if the team has access to the hardware prototype from the early stages of the development process or can simulate its behavior, testing in the project’s final stages may uncover some unexpected issues.
As a countermeasure, integrating agile testing, test automation, and continuous integration (CI) tools enables developers to monitor code performance during development cycles and avoid any last-minute surprises. Dividing the code into smaller, testable functionalities allows the embedded team to maintain and ensure the high quality of the code, regardless of the project’s stage.
Learn from every sprint
Sprints, and working in iterations in general, are the main concepts of the agile approach. In theory, each sprint should result in a releasable version of the software. However, this is often not feasible in embedded development, where complex low-level features may require many weeks to deliver. Instead, the team may concentrate on making tangible progress that can be shared with stakeholders at the end of each sprint.
Even in high-complexity projects, where problem-solving or feature implementation may take weeks or months, working in strict time iterations allows the team to better organize and plan. Moreover, sprints enable teams to take advantage of the retrospective meeting, a SCRUM event that is too often undervalued. The retrospective meeting aims to promote continuous improvement by facilitating a discussion at the end of each iteration. The team aims to identify wins as well as areas for improvement. Retrospectives are essential for the project team to grow, mature, and thrive.
Find your Agile mindset
Utilizing Agile in embedded development is not a fruitless pursuit, it is a very realistic approach to delivering embedded solutions projects. It is crucial, however, to ensure, that strict rules of the methodologies will not discourage you from taking the first step. Instead of overly concentrating on the practice itself, try discussing with your team what might be the best approach to incorporate Agile into your embedded projects. Start small, work in sprints, divide your workload, communicate, and test early in the process. Before you know it your team will be working Agile – it’s all in the mindset.
If you’re looking for a partner to work with on an Agile embedded project, search no more! Speak to an expert and tell us what you want to achieve.