Is Agile methodology applicable to Embedded Systems Development?
In the IT industry, Agile methodologies are often used for software development management. Over 70% of IT companies use Agile for their development flow control. Scrum has emerged as one of the most popular. It is mainly used in the creation of various types of applications, be it for companies in the banking, insurance or medical sectors.
In Embevity we develop embedded systems for clients who are delivering product for various market sectors. We mainly deal with the development of software for embedded systems, which means that the delivered code interacts with hardware. Still, part of our work requires design and development of electronic hardware.
Although the production of electronic hardware is a linear process and it would seem that there is no place for agility, in our embedded systems development projects we use Agile methodology.
What are the benefits of using Agile? What are the limitations, inconveniences or challenges? Is it worth experimenting? Do you need to use pure Agile or is there room for flexibility?
Please continue reading to find out how we manage embedded development project using Agile.
First things first: do our clients need Agile?
No they do not. That is not what our clients need from us. Clients are looking for a partner who will deliver a product or part of the product that they can sell and make money off. They want their business to be successful. Which means that during their “partner assessment” stage they need us to define: price, scope and timeline for the project. From that they will draw conclusions if our development services are the right solution to their problem.
A typical Waterfall approach would define price, scope and timeline and risks. Sounds great from the client perspective. It would not leave room for elasticity with its strict schedule-based perspective. But we never found the Waterfall project management tools to be flexible enough to comfortably manage progress and introduce change requests.
There are several indirect factors that the client and the development team need, to feel comfortable and confident during product delivery:
- Progress, hours and budget burn rate monitoring
- Client and subcontractor interaction
- Convenient tools
- High success probability
We see that Agile improves the above points. So contradictory to the beginning of this paragraph we believe that using Agile leads to a better project outcome. And that is what clients need. But while diving into the Agile methodology we have to keep in mind that price, scope and timeline are vital for our clients. It certainly builds trust and long term relations, when you care for these three factors. That is why we manage the projects in the hybrid Waterfall-Agile methodology. That also means we do not use pure Agile, which we believe is unnecessary. You can take from Agile what you find beneficial and leave the rest for the purists.
How do we use Agile/Scrum in Embevity?
For each project, we create a team that consists of a project leader, developers and a PM. Typically, our client representative serves as the Product Owner. PM and the technical leader form a couple that takes the role of a business analyst. Together they contact the client and talk about his needs. PM together with the Technical Leader analyze the requirements given by the client, present the project implementation plan and the risks associated with it. PM and leader are members of the project team and cooperate in a partnership relation.
The above roles, their responsibilities and communication channels are defined at the beginning of the development process and constitute a communication plan which is also documented. The software development process starts and enters a typical Agile cycle:
What is the biggest challenge? Delivery of the increment at the end of the two-week sprint. In the production of embedded systems, it takes a long time to develop hardware, e.g. schematics and PCB designs. With very complex projects, it is virtually impossible to prepare a project within a two-week sprint. Added to this are the high costs of producing prototypes.
Our solution to this is to allow hardware run its own cycle in parallel with embedded software development. Before the prototypes are ready we use development platforms for software development. Once the prototypes are manufactured we can introduce them into the deployment and testing cycle together with software.
The whole development process can be depicted by the following graphic:
What works well and gives benefits, and what problems do we encounter?
Benefits of working in Scrum:
- We are transparent in communication with the client
- We talk with the client about the scope of tasks
- We work in regular cycles
- We review, improve and prioritize the backlog
- Errors that appear in our clients’ installations have priority in finding solutions
- We plan the scope of tests in each iteration
- We perform frequent regressions
- We help each other and remove bottlenecks quickly
What limits us:
- It is difficult to deliver the increment of the designed device in each iteration
- The cost of the project increases with the increased frequency of prototype production (e.g. every sprint)
- It is difficult to keep firmware and hardware specialists involved in scrum meetings
We are constantly looking for new and better solutions. Thanks to the knowledge gained during the “real scrum cases” training, new opportunities opened up. If Scrum has ready-made elements that limit us, we will try to apply Kanban. It will still make us Agile. We do not limit ourselves to Scrum, we are looking for other possibilities, and Kanban is one of them.
Why Kanban? Because it is more flexible and gives more freedom, which makes it more universal. The first steps in the application of Kanban will be to isolate processes, establish rules, measure and visualize processes. On this basis, we will plan releases and implementation dates, and we will track progress of work on an ongoing basis.
Is it worth being an agile organization? Yes! Only agile organizations will survive in a VUCA world. In order to keep up with technological advancements, we must constantly learn and adapt to unexpected events. And that’s how we want to work, as an organization that learns, experiments, implements new ideas, focuses on people and constantly improves.