If you are familiar with the concept of a "Design Pattern" you may well feel that they reflect an older view of development.  Indeed, the patterns were first identified before the popularity of agile approaches.  That said, they are entirely agile, and this episode is about why that is.

Collaborating effectively includes, among many necessary skills, the ability to be persuasive.  This episode will outline an approach to persuasiveness that I have found to be highly effective in my experience as a consultant and mentor.

Over the last two weeks I discussed the power of list-making in an agile project.  This week, I dig into the details of one very important list, which is a list of the stakeholders to a given product, project, or feature.

Last week I introduced the notion of a team to-do list, and how important this artifact is during the development of a feature.  That list should be curated once the work is done.  How that curation is accomplished the the subject of this episode.

One of the most powerful tools available to the team when conducting Acceptance Test-Driven Development, or any kind of requirements analysis, is also one of the simplest ones.  This episode is all about that tool.

In agile processes, we need discrete definitions of every important aspect of our work, so that we can work efficiently and effectively together, and to know when organizational goals have been achieved.  Part of this is knowing when the work is "done", and that's what this episode is all about.

Part 3 of my analogy on product quality.

Part 2 of my analogy on product quality.

Part of the Agile approach, as well as the tenets of Lean, say to "build quality in."  This seems wise, but what specifically is meant by "quality"?  Also, how can we know if we have imbued our product with enough of the required qualities to make it releasable?  The next three episodes will examine the notion of quality using a hopefully familiar analogy.

TDD can help you to improve your product design for many reasons.  One of them is that it is difficult, if not impossible to write a good test for a bad design.  But what is a good test?  How would we know if it's good in the right sense?  That's what this episode will explain.