Analysis is a fundamental part of system's development.  It is also one of the most difficult things to do right, and since everything that follows is based on it we need multiple skills to do it correctly.  Commonality-Variability Analysis, as suggested in the work of James O. Coplien, is a remarkably powerful approach to conducting requirements analysis.

Test-Driven Development (TDD) is not really a testing activity per-se, but an analysis process that drives product design.  That said, although it does not eliminate the need for after-development testing (QA/QC), it does contribute to that process.  This episode will show why this is.

One of the benefits of Test-Driven Development is the way is enhances our ability to collaborate effectively.   This is especially true if you include Acceptance Testing as part of the way of working.  This episode is all about this.

TDD is a process that produces multiple values for the organization.  One of them is a fundamental improvement in the quality of the products they produce.  This is not just because of the testing per se, but also because of the effect of writing them up front.  This episode explains why.

How can we keep track of the behavior of systems as they change over time?  We must do this, or critical enterprise knowledge can be lost, at potentially great cost going forward.  This episode is about how TDD solves this problem.

This tip is one of four that elucidate the benefits of TDD, so that those whose approval is needed for adopting this way of working will understand why it should be done.  This week, the issue is increasing team velocity.

Adopting TDD initially can involved overcoming the objections of others in your organization.  In this episode, and the next few that follow, we will examine these concerns and how to address them

Good design and process seeks to reduce or eliminate risks, but we all know that it is impossible to act completely risk-free.  Because of this, we need a way to assess those risks we cannot prevent, in order to determine what, if anything, to do about them.  This podcast will offer an effective way to do that, collaboratively

Somethings are known before we begin a project, but many things are not.  We need to balance our process between decisions that cannot or should not be deferred, and those that it is better to wait on.  This episode all about that balance.

Most of us do not ask "why" enough.  Let's look at the effects of this problem, and what to do about it.