Ruthlessly Helpful

Stephen Ritchie's offerings of ruthlessly helpful software engineering practices.

Category Archives: Agile

Thank You AgileDC 2025

Leave a comment Posted by on October 28, 2025

A very big thank you to AgileDC 2025 for hosting our presentation yesterday. Fadi Stephan and I gave a talk titled, “Back to the Future – A look back at Agile Engineering Practices and their Future with AI” offered our experience and perspective on a few important questions:

  • As a developer, if AI is writing the code, what’s my role?
  • As a coach, are the technical practices I’ve been evangelizing for years still relevant?
  • Do we still care about quality engineering?
  • Do we still need to follow design best practices?
  • What about techniques like Test-Driven Development (TDD) and pairing?

Agile Engineering with AI

I want to thank Fadi for co-presenting and for the hard work he put in to our discussing, debating, and deliberating on the topic of Agile Engineering with AI. Our work together continues to shape my thinking on software development. I will have a follow-on blog post that covers our presentation in depth.

If you are interested in learning about AI TDD, or building quality products with AI, or other advanced topics, then I recommend you check out the Kaizenko offerings:

  1. Build
  2. Innovate
  3. Lead
  4. Transform

I highly recommend Fadi’s coaching and training. It’s top shelf. It’s practical, hands-on, and it’s the best place to start to elevate your know-how and get to the next level.

Check out all that Fadi does here: https://www.kaizenko.com/

Coding with AI

These days I’m doing a lot of Coding with AI, which you can see on my YouTube channel, @stephenritchie4462. You’ll find various playlists of interest. For the Coding with AI playlist, I basically record myself performing an AI-assisted development task. I try ideas out in a variety ways, as a way to explore. If you are an AI skeptic, I recommend experimenting just to see how being an AI Explorer feels. I was surprised by how interesting and useful and fun coding with AI can be.

Sessions I Attended

First, I attended the keynote speech by Zuzana “Zuzi” Šochová on “Organizational Guide to Business Agility”. I enjoyed many of the ideas that Zuzi brought out:

  • Start with a clear strategic purpose: Agility is how you achieve it, not why your org exists.
  • Leadership is a mindset, not a title; anyone can step up, take responsibility, and model new behaviors.
  • Combine adaptive governance with cultural shifts because being too rigid kills growth, and being too loose breeds chaos.
  • Transformation isn’t a big bang; it’s iterative. Take tiny steps, inspect and adapt, retain a system-level awareness.
  • Enable radical transparency, shared decision-making, and leader–leader dynamics to scale trust and autonomy.

Note that AgileDC is on her Top 10 Agile conferences to attend in 2025.

Then I attended the Sponsor Panel discussion on The State of Agile in the DC Region. A lot of thought provoking discussion with both a somber yet hopeful tone. The DC region is certainly undergoing changes and managing the transition will be hard.

For Session 1, I attended Industrial Driven Development (IDD) by Jim Damato and Pete Oliver-Krueger. For me industrialization is a fascinating topic. It’s about building the machine that builds the machine. In other words, manufacturing a part or product in the physical world requires engineers to build a system of machines that build the part or product. I am amazed at what their consulting work has accomplished with regard to shortening lead times.

Next, I attended Delivering value with Impact by Andrew Long. This was the most thought provoking session of the day. I particularly liked the useful metaphors on connecting Action to Customer to Behavior to Impact. There were several key insight related to using customer behavior change as a leverage point to increase the business impact your receive from your team’s actions.

After a hardy lunch and catching up with Sean George, I attended the Middle guard in Midgard… session by David Fogel. The topic is related to how the Old Guard (fixed mindset) and the New Guard (growth mindset) represent two different camps found in the Agile transformation. Midguard is the present reality. So, as an Agile Coach you’re in the present reality of working with the Middle Guard, who are a mix of both fixed mindset reservations and growth mindset desires. After the topic was introduced, it was facilitated using “Pass the cards” per Jean Tabaka (or the 35 Shuffle technique), which was a masterclass in how to use dot voting efficiently in a workshop. A lot of good knowledge sharing.

Next, I attended AI Pair Programming: Human-Centered Development in the Age of Vibe Coding by George Lively. From my software engineering perspective, what I learned here will provide the most grist for my follow-on learning and experimentation. What George showed us was his excellent experiment and the demonstration of how AI-assisted software development can both accelerate delivery and be well managed. He applied static code analysis, test code coverage, quality metrics, and DORA metrics in a way that shows how AI Pair Programming can work well.

Next was Fadi and I at the 3:15pm session. As I mentioned above, I will blog separately on our session topic.

Finally, I sat in on Richard Cheng‘s From Painful to Powerful: Sprint Planning & Sprint Review That Actually Work session. Richard has an excellent way of explaining the practical application of the Scrum Framework. He takes the concepts and framework and gives clear advice on how to improve the events, such as Sprint Planning and Sprint Review. In this session, he reminded me of some of the pitfalls that trip me up to this day; I need to stop forgetting how to avoid them. The session showcased why Richard is an excellent Certified Scrum Trainer (CST), and his training never disappoints. Check out his offerings: https://www.agilityprimesolutions.com/training

As many of you might know, Richard and I used to co-train (though I was never on an equal footing) when we both worked together at the training org that is now Sprightbulb Learning.

Stay in Touch

In addition to attending sessions and learning a lot, it was great to catch up with friends and former colleagues who attended the conference. Some I hadn’t seen in years. A big highlight of AgileDC are the connections and reconnections in the DC area’s Agile community.

You’ll find Fadi on LinkedIn here: https://www.linkedin.com/in/fadistephan/

You’ll find my LinkedIn here: https://www.linkedin.com/in/sritchie/

Take care, please stay in touch, and I hope to see you next time!

Agile, Presentations , , , , ,

First, the mental creation

Leave a comment Posted by on April 24, 2020

With physical things, like buildings and devices, etc. people seem to be generally okay with generating strong specifications, such as blueprints, CAD drawings, etc. These specifications are often about trying to perfect the mental creation before the physical creation gets started. In these cases, the physical thing you’re making is not at all abstract, and it could be very expensive to make. It’s hard to iterate when you’re building a bridge that’s going to be part of an interstate roadway.

missed-it-by-that-much

What I’ve seen in the world of software, the physical creation seems abstract, and engineers writing software appears inexpensive when compared to things like steel and concrete. Many people seem to want to skip the mental creation step, and they ask that the engineers jump right into coding the thing up.

If the increment of the thing that your team is to write software for is ready to be worked on, and you have a roadmap, then an iterative and incremental approach will probably work. In fact, the idea that complex problems require iterative solutions underpins the values and principles described in the Manifesto for Agile Software Development. The Scrum process framework describes this as product increments and iterations.

However, all too often it’s a random walk guided by ambiguous language (either written or spoken) that leads to software that lacks clarity, consistency, and correctness.

Sadly and all too often, the quality assurance folks are given little time to discover and describe the issues, let alone the time to verify that the issues are resolved. During these review sessions, engineers pull out their evidence that the software is working as intended. They have a photo of a whiteboard showing some hand-wavy financial formulas. They demonstrate that they’re getting the right answer with the math-could-not-be-easier example: a loan that has a principal of $12,000.00, a term of 360 payments, an annual interest rate of 12%, and, of course, don’t forget that there are 12 months in a year. And through anomalous coincident, the software works correctly using that example. Hilarity ensues!

banks-care-about-rounding

Unfortunately, QA is often squeezed. They are over-challenged and under-supported. They are given an absurd goal, and they persevere despite grave doubts about whether a quality release is achievable. Their hopelessness comes from knowing that the team is about to inflict this software on real people, good people, and the QA team doesn’t have the time or the power to stop the release.

the-dirty-remains

What are the key things to take away:

  • When the physical creation of software seems to be cheap, comparable to the mental creation of writing down and agreeing to light-weight requirements, then the temptation exists to hire nothing but software engineers and to maximize the number of people who “just write code”. In the long run, however, the rework costs are often extremely expensive.
  • In the end, the end-users are going to find any defects.
  • Better to have QA independently verify and validate that the software works as intended, of course, what is intended needs to be written down:  clearly, consistently and correctly.
  • QA ought to find issues that can to be resolved before the users get the software — issue reports that show clear gaps in required behavior.
  • QA conversations with engineers ought never degenerate into a difference of opinion, which happens when there are no facts about the required behavior. Very often these discussions (rhymes with concussion) escalate into a difference of values — “you don’t understand modern software development”.

Interestingly, the software’s users are going to find the most important defects. The users are the ultimate independent validators and verifiers. End-users, their bosses, and the buyer can be ruthless reporters of defects. In fact, they might very well reject the product.

Agile, Best Practices, Communication, Development, General, Opinion, Scrum