Talks

Below, you’ll find a list of unique and enlightening talks on subjects that will help audiences grow their consulting and development skills. If you’d like to have me present it at your company or user group, please fill out this form and I’ll get back to you. Remote presentations are somewhat easy to make happen, as well as in-person in the Houston area.

Trusting the Scrum Team: Bridging the gap between Vision and Execution

Have you all ever wished for improved collaboration between technical and non-technical people who trust each other?

As a developer:

  • Have you ever had to justify the time spent writing tests?
  • Do you ever think “how can I make them understand this intricate code I had to write?”

As a non-technical person:

  • Have you ever wondered why developers say a user story will take so long to implement?
  • Do you ever think “maybe if I learn a programming language…”?

Attend this presentation and learn how to bridge that large gap by building a common ground where everyone can better contribute to the success of projects.

You’ll learn how to improve communication and collaboration to make sure developers are delivering what’s needed by the business while doing the right things right (be that writing tests, refactoring code, etc).

Effective User Stories

User Stories have become a common artifact used by most software development teams. Their effective use can improve the quality of deliverables to the business while lowering development costs. Everyone involved in the project can and should contribute to both writing and using user stories more effectively.

In this talk, we’ll have a look at techniques to try right away: product owners, business analysts, QA, developers, UX designers, everyone is likely to get a thing or two out of it!

Finding the bug in “UX == ‘the art of making things look pretty’”

Writing code is a lot of fun. So is technology. What about all those shiny Javascript libraries? It’s very easy for software developers to get lost in technical concerns and completely overlook the purpose of developing software to begin with.

By acquiring good skills in UX design, developers can make the product of their code really shine, while improving their collaboration with UX designers and stakeholders.

We test, therefore we smile!

Unit, integration, end-to-end tests. Which ones to write? For the back end or the front end? Or both? How much of each?

In this talk, I’ll answer those questions with a description of why, how, and what, the benefits, the value, the fun.

Testing in Agile: from Afterthought to an Integral Part

Testing cannot be an afterthought; it has to be an integral part of software development. Is it something that QA teams do? Or is it part of a developer’s duties? Do business analysts and product owners play any role in it? What is test automation? Unit test, Integration test, Test-Driven Development, Behavior-Driven Development… what do those mean?!

This session addresses those questions, as we talk through the importance of tests, the collaboration among team members, the techniques, and practices around different kinds of automated testing.

Refactoring Test Code

Most developers hear about “Red->Green->Refactor” as part of the TDD process. Some never get to the “refactor” part. Some only refactor the “production” code, but not the test code, after all, that’s “just test code”. Tests become cluttered, hard to maintain, and are abandoned.

In this talk, let’s have a look at some ways to refactor “test” code (C#, JavaScript/TypeScript, unit/integration/end-to-end…), so that they become easier to read and even create opportunities for better collaboration with non-technical people.

Improving Development with Context-Based Testing

It’s very common for developers to follow a “one test fixture per class/component” approach; that is, one file containing all of the tests that verify a given class or component. Then a new bug report comes in, the fix is a simple one-liner, but it requires 50 new lines of test code. There’s also a new feature that’s supposed to be easy to implement, but tests for it are hard to write, because the test files are too messy. In both cases, the tendency is to simply ignore the tests, write the code, and call it done.

In this talk, we’ll take a look at context-based testing as an approach to organizing tests, making them easier to read, write, and maintain. It works for many types of tests, such as unit, integration, and end-to-end. And it keeps both developers and the business happy!

“I Cannot Write Tests for That!”: UI Edition

I often hear something along the lines of “I cannot write tests for that UI code!” as the reason for the lack of unit tests. The fact is, more often than not, we can write tests for what seems to be “UI code”.

In this talk, we’ll explore an approach to either write or refactor UI code so it can be tested more easily. We will NOT cover how to write automated UI tests, though.

Code Review: I mean no harm!

As part of the work I’ve been doing for many years, I get to do a lot of code review. I usually document things that come up doing code review so I can share it with other developers in the teams.

In this session, I share some of the code I’ve looked at, the reasons why the code raised yellow or red flags in my mind, and possible solutions I’ve proposed.

Want to build software? Get your act together first!

Software developers are supposed to create applications that make people’s life easier, automating tedious tasks, encouraging users to get their work done, organizing complex workflows into digestible information and actions, helping them separate the most important information from the least important. But still, most developers forget to automate their own boring tasks. We forget to organize our information. We sometimes use tools that do not help us get our work done.

So how can we build software that fits our client needs, if we don’t understand those needs ourselves?

This session is not only about software development; this session is about things we can do and tools we can use to organize ourselves, so we can free up our minds to more important things.

Tools covered in this session include (but not limited to) Evernote, application launchers, screen capture tools, tablets, smartphones, etc.

Beyond the Daily Stand-up: An Intro to Scrum

Countless companies believe they’re doing Scrum because they have 30-minute daily stand-ups (with people sitting and staring at their laptops) every morning. But Scrum is really a lot more than that.

In this session, we see all of the main parts of Scrum (roles, artifacts, and events), and we also talk about some real world collaborations in teams that adopted Scrum.

Preparing and Giving Sprint Reviews (and Demos)

The Sprint Review is the time when a Scrum Team demonstrates the value brought into the business over the last iteration. It’s the culmination of all the hard work done, and giving a great review presentation (which may or may not include a demo) is essential to calling a Sprint a success!

In this session, we’ll go over some techniques, tips, and tricks to put together and deliver a great Sprint Review.

The Software Does Not Work? Rewrite it!

Outdated technology? Unmaintainable codebase? Politics? Those are just some of the reasons that cause software rewrites. Whether a rewrite is really needed or not, chances are we all work on such projects.

Do we rewrite the entire software? Can we rewrite just parts of it? Where do we start? Can we automate the process?

Since the early 2000s, I’ve worked in a variety of such projects. I’d like to share the most important lessons I’ve learned in these projects.

In this talk, I’ll share some of the different types of rewrites and techniques, what I learned from it, and how it changed my way of approaching both software rewrites as well as greenfield projects.

Mixing Italian Sauce and Productivity: Mamma Mia!

You’ve heard it before: set a timer for 25 minutes, do some work, take a 5-minute break, rinse, and repeat. What else is there to it?

  • How to plan for it
  • What to do during the breaks
  • How to manage interruptions

BDD, but not the way you heard it before

Is Behavior-Driven Development a QA Process? Or is it a coding practice? It’s often talked about in the context of describing system behavior. Can we add it to our CI/CD pipeline? What tool should we use? In this talk, I’ll put a different spin on it and offer you an unusual perspective.

We will explore BDD, keeping an emphasis on collaboration and communication among developers, testers, and business stakeholders, but rather than focusing solely on technical aspects, this presentation will delve into the human element of the methodology, highlighting the importance of empathy, mindfulness, and inclusivity in creating effective BDD processes.

We may Start With Why Atomic Habits can be Badass, Making Users Awesome at the Speed of Trust when we look at the Design of Every Things, if we Dare to Lead. You see what I did there, yes?

Automated Tests: A Case Study

Some questions I hear very frequently: “If we have automated end-to-end tests, do we still need tests on the back end? What about on the front end? Integration tests? What’s the ideal code coverage? BDD or TDD?”

In this session I’ll share data gathered over 30 sprints, showing test counts in the different areas, ratio of frontend/backend/e2e tests, code coverage, process, experiences, and opinions. 

  1. Leave a comment

Leave a comment