Home > Tracks > Embedded Systems Programming

How Agile is Changing the Face of Embedded Software Development

Niall Cooling - Watch Now - Currently watching: 0

This presentation is ideal for anyone who is either new to Agile, considering using Agile or even has experience in working with Agile methodologies and practices with embedded software or firmware developments.

It will clarify the Agile landscape, covering both process based aspects, such as Scrum and various techniques, including Test Driven Development (TDD) and some of the underlying foundation principles, such as Continuous Integration (CI).

As part of the discussion, we shall look at some of the modern-day tools that help apply Agile techniques(e.g. Docker) and finally look ahead to the current gaps and where embedded systems offer particular challenges to the use of Agile techniques.

M↓ MARKDOWN HELP
italicssurround text with
*asterisks*
boldsurround text with
**two asterisks**
hyperlink
[hyperlink](https://example.com)
or just a bare URL
code
surround text with
`backticks`
strikethroughsurround text with
~~two tilde characters~~
quote
prefix with
>

jwgrenning
Score: 0 | 1 day ago | 1 reply

Hi Niall, Good talk on Agile. On TDD... it starts as flossing, i.e. something you should do. I've flossed most my adult life. It's a habit. I rarely don't. TDD is not like that. With TDD skill develops and soon TDD becomes FUN.

NiallSpeaker
Score: 0 | 19 hours ago | no reply yet

Hi James, I can only talk about my experiences when consulting with companies who have/are trying TDD. Hopefully, you saw I pointed people at your presentation on TDD and put the rest of us to shame about presentation style ;-) I'll up my game for the next one!

moredatalesscenter
Score: 0 | 2 days ago | 1 reply

Hi Niall, I really enjoyed your presentation. I appreciated the recognition of working in multi-disciplinary teams (SW, HW, Mech) when it comes to embedded systems development. So many books focus on just agile software development. Also good coverage of Docker, as I’d always assumed this is a Web/Linux thing that wouldn’t apply to the embedded world.

NiallSpeaker
Score: 0 | 19 hours ago | no reply yet

Thanks. Docker is now central to so much of what we do internally. It's shown its real benefit as we've moved from gcc-5.4 all the way to gcc-10 (mainly supporting C++11/14/17/20). It's allowed us to test our codebases in a painless way without impacting the existing setups. Hopefully, the blog postings about Docker will give help cement its applicability.

Raghu
Score: 0 | 4 days ago | 1 reply

Very good presentation Niall. Thank you

NiallSpeaker
Score: 0 | 4 days ago | no reply yet

Thanks for taking the time to watch

ACT
Score: 1 | 4 days ago | 1 reply

How do you work around some of the challenges you described, e.g. having to deal with hardware/software integration when hardware is part of a different team that does not participate in the software team's sprints? How do you align with hard dates on the hardware integration schedule?

NiallSpeaker
Score: 0 | 4 days ago | no reply yet

And there in lies the biggest challenge. There are no easy solutions out there. A couple of companies have reorganised the whole team structure along project lines, so all members (h/w, s/w, mech, etc) are all part fo the same team rather than having a separate hardware department and team. But that is only feasible will smaller companies and dynamic management. Other (larger) companies are using the SAFe framework to try and address this issue. This is where better simulation/emulation technology is needed to mitigate schedule risks.

enrico.perera
Score: 0 | 5 days ago | 1 reply

What are some examples of integration tests that the CI would be performing ? Is the CI doing these within a software only domain (host server) or is this being run on the target (via jlink/debug interface and additional hardware to monitor pins/voltage levels/signals etc.. ) ?

NiallSpeaker
Score: 0 | 5 days ago | 1 reply

The majority are S/W only (as that's the easy bit). More complex/complete CI setups are doing full h/w-in-the-loop testing; but that typically requires building custom rigs (the best I saw used Lego!). I've seen Raspberry Pi's used as well to interact with voltage signals, etc. It's something we're working on at the moment to try and simplify.

enrico.perera
Score: 0 | 5 days ago | 1 reply

When you talk about integration tests that happen in the S/W domain - what type of tests are being conducted ? Can you provide a hypothetical example ? Is it just as simple as the interaction between between modules instead of the just limiting to just a module (unit testing) ?

NiallSpeaker
Score: 0 | 5 days ago | no reply yet

To the greater extent yes. Integration testing should be focussing on the Module/Component/Subsystem API protocol. What's typically missed is that almost all interfaces have some sort of protocol (based captured as a state machine). Good integration testing is about state-space investigation of this protocol. Fundamentally Mocks are there to prepare a unit for integration testing (as opposed to stubs for unit testing).

KVas
Score: 1 | 5 days ago | 1 reply

Hello... Thanks for the session.. covers a lot of stuff... had two questions related to scrum team... what if the scrum team is unbalanced in terms of competencies and experience... secondly how to best estimate exploratory or R&D type of stories, like working with some new hardware etc

NiallSpeaker
Score: 0 | 5 days ago | no reply yet

Two good questions. On the first one, an unbalanced team, I have seen (in real life, on a real commercial project) pair programming help address this. Done well/correctly, pair-programming has so many benefits. Unfortunately, it's really difficult to get management buy-in. The second one is far more difficult; especially where there is more R than D. This is why I prefer lean over scrum, as it's a pull model rather than a push model (I see scrum as a push model). It is all related to risk management and trying to decompose the core requirements. Check out https://www.youtube.com/watch?v=pz8CpSUiULo for some ideas

Pete
Score: 2 | 5 days ago | no reply yet

Good stuff. It was handy to see you break down working across HW, SW and Mech boundaries with a CI model. Don't see that topic come up very often. Thanks for the overview of a CI build-test-deploy strategy and some tools that could be used to make it happen.

IoTsri
Score: 0 | 5 days ago | 1 reply

Thanks for the talk. I'm going to discuss this talk at my client's company.

NiallSpeaker
Score: 0 | 5 days ago | no reply yet

Thanks. We do have a full day covering all things agile in more detail which I'm happy to discuss offline. Glad you found it useful.

Jeremy
Score: 0 | 5 days ago | 1 reply

will the slides be uploaded?

NiallSpeaker
Score: 0 | 5 days ago | 1 reply

Yes, they should have been. I'll check with Jacob why they're not there. But feel free to ping me directly (maybe on LinkedIn) and I'll send you the PDFs if they're not up by the end of the day

Jeremy
Score: 0 | 5 days ago | no reply yet

Got 'em. Thanks Niall for the wonderful talk! Lots of good nuggets in there. The title tricked me a bit, but you are right, I once said to a team at my company "if you're not doing CI (and we're not yet in many cases), you're just moving stickers". I've been on teams before that have done CI and really saw the benefits in the "agile mindset". I along with a few colleagues of mine are pushing for more to go down the CI path, and I liked all the slides you had on the topic. I'll be referring back frequently.

olivierdugas
Score: 0 | 5 days ago | 1 reply

Very nice presentation. Thank you

NiallSpeaker
Score: 0 | 5 days ago | no reply yet

Thanks for the feedback

MarkusADH
Score: 1 | 5 days ago | 1 reply

Thanks for the talk! I am going to try to bring continuous integration and TDD into my student team, and this was very helpful

NiallSpeaker
Score: 0 | 5 days ago | no reply yet

Thanks Markus. I've posted some work on CI, Docker and embedded on our blog at https://blog.feabhas.com/2017/09/introduction-docker-embedded-developers-part-1-getting-started/ might be worth a read.

Alan
Score: 0 | 5 days ago | 1 reply

Great presentation Niall. You mentioned near the start that you're not a great fan of stories. I'm wondering what method you prefer to capture the business and technical aspects? Are you referring to traditional requirement statements such as "the light SHALL turn on after 200ms", etc.

NiallSpeaker
Score: 0 | 5 days ago | 1 reply

Hi Alan,
Thanks for the feedback. I think it very much depends on your application, but anything that had any degree of integrity must have some sort of traceability back to the "SHALL" (dull I know but necessary). Check out a webinar I did last year which goes into a lot more details and cover user stories, use cases and other techniques: https://www.youtube.com/watch?v=pz8CpSUiULo

Alan
Score: 0 | 5 days ago | no reply yet

Thank you for the feedback and link, Niall. I always had a niggle about agile in this respect.

OUR SPONSORS