It’s no surprise—Agile is often misunderstood as little more than two-week sprints, burn-down charts, and daily stand-up meetings. In reality, Agile isn’t a micro-management framework; it’s a mindset rooted in continuous improvement and technical excellence.

When Extreme Programming (XP) emerged in 1999 with its provocative name, it challenged the status quo with sound engineering practices designed to support tight iterative cycles. Yet today, many Agile teams struggle to integrate these practices, leading to poor product quality, hard-to-change code, endless debugging, long stabilization phases, and the growing burden of manual testing.

In this keynote, we’ll cut through the noise to uncover why Technical Excellence is the cornerstone of successful Agile teams. You’ll discover how XP practices like test-driven development, refactoring, and automation can address the hidden challenges of Agile and set your team on the path to true agility.

13:34:27 From garyb to Everyone:
	Ah, the early days of uC development.
	
13:35:54 From James Grenning to Everyone:
	8085/8086
	
13:37:40 From Stephane to Everyone:
	I love the dynamic editing!
	
13:37:42 From Daniel Mendez-Lozada to Everyone:
	superb video editing!
	
13:38:10 From garyb to Everyone:
	Intel 8048/8049, HC6805...
	
13:49:20 From Otzen to Everyone:
	There was a german youtuber that coined the problem, Scrum is alot about reducing processes, but often Scrum becomes the new process, and turns into "Böse Scrum" (evil Scrum)
	
13:53:34 From James Grenning to Everyone:
	come on admit it
	
13:53:42 From Jacob Beningo to Everyone:
	If I didn’t write bugs, I’d have to skip the debug part of my job!
	
13:53:46 From Jacob Beningo to Everyone:
	:-)
	
13:53:55 From Patrick Wright to Everyone:
	I am a programmer and I write elegantly complex bugs!
	
13:53:58 From Jacob Beningo to Everyone:
	(I write some really good ones too)
	
13:54:02 From garyb to Everyone:
	Yup, especially when developing for a metal mask order... ouch.
	
13:54:19 From Tom to Everyone:
	I have trouble finding the focus I need for actual (incremental) development work when many requirements conversations are happening all around me. Do other organizations typically have dedicated people working on requirements and other people doing development?
	
13:54:52 From Jacob Q to Everyone:
	I love this other quote from Edsger Dijkstra: "If debugging is the process of removing software bugs, then programming must be the process of putting them in."
	
13:55:35 From Jacob Q to Everyone:
	Replying to "I have trouble finding the focus I need for actual...":
	Sadly, no, and I think that is often dreamland. Just like TDD, it is something that we have to build into the process ourselves for everyone's benefit.
	
13:55:36 From Suzi O'Rourke to Everyone:
	I am a programmer and I write bugs. I'm hoping to reduce those, but I expect I'll write better bugs as I go along!
	
13:57:43 From garyb to Everyone:
	Replying to "I have trouble finding the focus I need for actual...":
	Larger organizations, yes there are some dedicated resources. Where there are no dedicated spec or test resources - I've found that I'm not a good at developing, spec reviewing, and debugging all at the same time - and under time pressure.
	
13:58:13 From Otzen to Everyone:
	At a conference many years ago I talked to a gentleman who worked with reviwing SW for Nuclear plants. He told me that over 50% of the bugs they found was in the spesification.. 😲
	
14:00:05 From dteubl to Everyone:
	Replying to "At a conference many years ago I talked to a gentl...":
	And it is still cheap to remove those bugs at that time requirements and early development. When they reach  production, it is pretty costly.
	
14:02:13 From ts to Everyone:
	Replying to "I am a programmer and I write bugs. I'm hoping to ...":
	better bugs in the sense of more complex and harder to find bugs. 😂
	
14:05:00 From Daniel Mendez-Lozada to Everyone:
	Replying to "I love this other quote from Edsger Dijkstra: "If ...":
	I also like this other quote from Dijkstra:
	"Those who want really reliable software will discover that they must find means of avoiding the majority of bugs to start with, and as a result the programming process will become cheaper. If you want more effective programmers, you will discover that they should not waste their time debugging, they should not introduce the bugs to start with."
	
14:06:06 From Daniel Mendez-Lozada to Everyone:
	Replying to "I am a programmer and I write bugs. I'm hoping to ...":
	I am a a programmer and I write bugs for a living 🙂
	
14:06:16 From Suzi O'Rourke to Everyone:
	Will the slides be available after the talk?
	
14:08:12 From garyb to Everyone:
	All too often we, as developers, are blind to our own assumptions when debugging - my code doesn't do that!
	
14:09:17 From Jacob Q to Everyone:
	Trying to automate firmware testing continues to be one of the biggest challenges my team is facing. :/ Lately we have been settling for "semi-automated" tests, e.g., debug commands to run tests on target hardware
	
14:09:24 From dteubl to Everyone:
	"It worked on my computer yesterday!..."
	
14:09:24 From James Grenning to Everyone:
	Replying to "All too often we, as developers, are blind to our ...":
	I have a shirt... My code works, Why? My code doesn't work, Why?
	
14:10:25 From James Grenning to Everyone:
	Replying to "Trying to automate firmware testing continues to b...":
	Semi automated HIL is practical.  Production might help pay for HIL unattended.
	
14:11:28 From Otzen to Everyone:
	Some time back, i was tasked with adding test's to a piece of old code. Newer before did I learn how a piece of really works so fast.
	
14:12:30 From James Grenning to Everyone:
	Replying to "Some time back, i was tasked with adding test's to...":
	Yes, adding tests to legacy code make you qualified to work on the code.
	
14:13:06 From James Grenning to Everyone:
	Replying to "Some time back, i was tasked with adding test's to...":
	See my github account for the legacy-build.sh script to help drag code into the test environmetn.
	
14:13:39 From James Grenning to Everyone:
	Replying to "Some time back, i was tasked with adding test's to...":
	https://github.com/jwgrenning/legacy-build
	
14:14:14 From ts to Everyone:
	@James Grenning  Do you think AI will be a great help for all those different aspects? In my experience as a solo developer, it would be very helpful.
	
14:15:30 From James Grenning to Everyone:
	I'm no AI expert, but it certainly is helpful for getting details needed to solve problems
	
14:18:00 From dteubl to Everyone:
	There is a great book for "harnessing messy legacy" code bases: https://ptgmedia.pearsoncmg.com/images/9780131177055/samplepages/0131177052.pdf
	
14:19:28 From Jacob Q to Everyone:
	👏👏👏👏👏👏
	
14:19:34 From dteubl to Everyone:
	Great Talk!
	
14:20:04 From garyb to Everyone:
	Oh, how I would have liked to have had this mind set sooo long ago.
	
14:24:23 From Jacob Q to Everyone:
	My question: Do you have any advice for someone trying to build an official Software Development Process document for a small (~10 electrical/software engineers) company? We have some existing standards (e.g., a style guide and release process) and lots of tribal knowledge (e.g., review code using GitHub Pull Requests) but one of my goals this year is to unify all this (to help with being able to write code for IEC 61508 projects). I like what you were saying about "problem solvers over dogma followers" and am afraid that if I do this wrong I will end up with "checklist followers"
	
14:24:45 From Tom to Everyone:
	Did I hear correctly that architecture shouldn't necessarily be complete or even first? I find it hard to keep the code manageable when there is no clearly defined set of architectural rules (e.g. a common language).
	
14:25:55 From Tom to Everyone:
	Replying to "I have trouble finding the focus I need for actual...":
	Most recently, I did find it very helpful to translate marketing requirements to use-cases and then focusing on one specific use-case.
	
14:25:59 From Nathan to Everyone:
	What would be the role of a test engineer in an interative approach using TDD ? (is there one?)
	
14:27:32 From Klaus Elk to Everyone:
	I remember the eXtreme Programming wave. A lot of good agile ideas. However, the pair-programming was extremely tiring. I prefer technical reviews and whiteboard talks before programming and e.g., pull-request reviewing after - but not programming with others.
	
14:27:37 From dteubl to Everyone:
	Q: You are quite long in the business now. Do you have any insight, why these thechniques are still not "common" in every team after more than 20 year so faar. And why do some orgs. aiming back to waterfall in some places. Embedded is special, safety/mission critical is even more special, but as you mentioned, that is not a case to not use working techniques.
	
14:27:50 From garyb to Everyone:
	Replying to "What would be the role of a test engineer in an in...":
	Test engineer's role is so important - their mindset is different than the developer's. Very effective part of design team and spec review asset.
	
14:28:01 From M. Schlax to Everyone:
	Do you have any advice for a team that has been piloting agile development, while still working in an environment that requires waterfall planning/reporting. We find it hard to not get bogged down in endless planning, especially early on in projects. It feels like we constantly bounce between iteration/PI planning and then overall project planning for waterfall, and are left with not enough time to actually deliver actual code.
	
14:29:28 From ts to Everyone:
	Replying to "I'm no AI expert, but it certainly is helpful for ...":
	Maybe with reasoning introduced into AI it will become much better over time.
	
14:30:44 From Otzen to Everyone:
	This talk is frustrating, all the time I am nodding and agreeing to it all.
	And at the same time thinkng
	How do I make my organization see this?
	
14:32:04 From Tom to Everyone:
	Replying to "Did I hear correctly that architecture shouldn't n...":
	I think this discussion on architectural vision answers my question.
	
14:32:23 From dteubl to Everyone:
	Replying to "This talk is frustrating, all the time I am noddin...":
	You are not alone with this. I hear the some from friend and former collegaues all the time.
	
14:32:47 From John.Singleton to Everyone:
	I think this talk could help someone looking to join a good software team. What are one or two questions we can ask during an interview to help judge whether it's a fairly functional team?
	
14:35:46 From Jacob Q to Everyone:
	Replying to "This talk is frustrating, all the time I am noddin...":
	What I have found is that when I can find some "low hanging fruit" that I can share (e.g., teaching new engineers to use something like "conventional commits" to focus their workflow), developers will start doing it because they benefit from it, whether or not it is formally part of the company's processes/procedures.
	
14:36:07 From Klaus Elk to Everyone:
	Replying to "Do you have any advice for a team that has been pi...":
	This is actually quite common! Especially in e.g. Medical or Automotive, where there are formal reqyurements.
	
14:36:44 From Jacob Q to Everyone:
	Sorry for the length :)
	
14:37:14 From Tom to Everyone:
	Replying to "I think this talk could help someone looking to jo...":
	I like to ask how they do things that I hope they are doing. "What test framework(s) do you use?" "How do you automate HIL tests?" "How do you collect user / stakeholder feedback?"
	
14:38:33 From Viktor to Everyone:
	Q: Is there a way to identify when we are in "Expert Beginner" stage? What is an escape plan?
	
14:38:45 From Jacob Beningo to Everyone:
	Replying to "Did I hear correctly that architecture shouldn't n...":
	Perfect! You can also reference my keynote yesterday in teh architecture section. 
	1) Software Characteristics
	2) Philosophies / Principles
	3) Architecture Decision Records
	4) Architecture Style / Structure
	
	The structure can be a little more emergent at the lowest levels
	
14:41:19 From Suzi O'Rourke to Everyone:
	Are the slides going to be made available?
	
14:41:24 From Otzen to Everyone:
	Replying to "Did I hear correctly that architecture shouldn't n...":
	Remember architecture is more abot abilities, not technical requirements
	Readability, maintainabnility, modifiability, testability ....
	
14:41:30 From dteubl to Everyone:
	Replying to "This talk is frustrating, all the time I am noddin...":
	Yup. Some claims - I am with this group - that starting change in small, convincing one collegauge at a time, learning a new practice at a time work better than starting at organizational level. If the changes at a small team are there and they are performing better the "managgers" will look into it that, what is actually happens there.
	
14:45:23 From garyb to Everyone:
	James, are there practical comparisons to develop in a visual programming environment - that isn't NI?
	
14:45:44 From Jacob Q to Everyone:
	Replying to "This talk is frustrating, all the time I am noddin...":
	A book I read quite a while ago that inspired me in this area was "Team Geek"
	https://www.oreilly.com/library/view/team-geek/9781449329839/ 
	One of the concepts they spend a lot of time talking about is establishing healthy culture among the developers (e.g., not making code personal) -- lots can be done "bottom up" like this
	
14:46:54 From Jacob Q to Everyone:
	Pretty much every "new idea" that I've been able to get my team to adopt has only come about after I invested the time to make a good demo/example to pave the way / lower the barriers to entry
	
14:47:15 From Otzen to Everyone:
	Replying to "This talk is frustrating, all the time I am noddin...":
	@dteubl Been there done that, we where a small department and truly adopting the agile manifesto.
	Some mangers saw this, and a few years later the organization changed to scrum/agile. But almost no one knows what that manifesto is about, so we sprint and refine and slowly die.
	
14:47:39 From dteubl to Everyone:
	@James Grenning : I'll look into those videos. I already giving your book to most of my colegaues/students ;)
	
14:48:09 From garyb to Everyone:
	Replying to "This talk is frustrating, all the time I am noddin...":
	A significant challenge is to learn from code reviews and not make developers the victim of the code review.
	
14:48:42 From dteubl to Everyone:
	Replying to "This talk is frustrating, all the time I am noddin...":
	@Otzen really sad to hear that.
	
14:50:14 From John.Singleton to Everyone:
	This is interesting, because I've been told that it's better to add unit tests to new code rather than legacy code.
	
14:50:27 From James Grenning to Everyone:
	https://wingman-sw.com/articles/tdd-legacy-c
	
14:52:32 From dteubl to Everyone:
	Replying to "Pretty much every "new idea" that I've been able t...":
	I would say, that at least you took your time to do that, and tried to make your team better. Keep Up with it!
	
14:54:38 From Otzen to Everyone:
	Replying to "This is interesting, because I've been told that i...":
	replace "better" with "cheaper" and it is correct ;-)
	
14:57:36 From Otzen to Everyone:
	Someome said in the chat yesterday "The goal is that the integration tests finds integration bugs" (free from memory)
	
14:59:15 From John.Singleton to Everyone:
	Replying to "This is interesting, because I've been told that i...":
	I think I'm going to reintroduce the idea for the legacy code that I think I'll reuse or continue to work with a lot...at least a module or two.
	
15:01:24 From davyb to Everyone:
	What do you see as the most disruptive thing in the last year or two ? (that isn't AI)
	
15:01:31 From Otzen to Everyone:
	Replying to "This is interesting, because I've been told that i...":
	To start testing legacy code, take a look at "the golden master" testing.
	
15:03:21 From RF to Everyone:
	If not Sprint, 7-up or lemonade? Perhaps not!
	
15:04:12 From John.Singleton to Everyone:
	Good answer. I will not blindly get excited by a Scrum team. Thank you!
	
15:07:25 From Otzen to Everyone:
	Replying to "Trying to automate firmware testing continues to b...":
	Are you trying to run unit test on the target HW?
	
15:10:06 From garyb to Everyone:
	Graphical design happens to be a Parker Industrial Product development environment.
	
15:10:50 From Jacob Q to Everyone:
	Replying to "Trying to automate firmware testing continues to b...":
	I would prefer to run unit tests on development workstations (and in CI), and we can do some of this. For example, pure functions, math, certain algorithms, etc. However, the code is too tightly coupled to hardware (e.g., "main.h" included everywhere and brings in CMSIS stuff for the MCU that won't compile on x86), so it takes a bit of work to separate each module. Alternatively, I can make the target hardware the "test runner", not because I want something as cool as HIL, but rather because it is easier/faster to get going with (no need to do big refactors to detangle)
	
15:11:26 From garyb to Everyone:
	Thanks James, very worthwhile!
	
15:11:30 From dteubl to Everyone:
	Replying to "Trying to automate firmware testing continues to b...":
	I managed to hook a HIL to the end of my CI pipline and let it execute predefined tests.  With high level test on the whole system is was working quite well.
	
15:11:34 From René Andrés Ayoroa to Everyone:
	Great talk, James! Thank you.
	
15:11:50 From davyb to Everyone:
	Awesome thoughts
	
15:12:15 From Greg Burk to Everyone:
	Great talk James, insightful as always!
	
15:12:21 From Viktor to Everyone:
	Thanks James!
	
15:12:33 From Patrick Wright to Everyone:
	Thank you!
	
15:12:40 From RF to Everyone:
	Wisdom combined with humour ... that makes a keynote worth watching AND listening.
	
15:12:41 From Eric Habets to Everyone:
	Thank you James!
	
15:13:03 From Jacob Q to Everyone:
	🐛