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.

Acceptance test can be made executable by an automation framework.  But you should not choose one at the beginning of your adoption of ATDD.  Here's why.

Many tech leaders and project managers are mandating a minimum level of code coverage by developers.  They believer this ensures a level of quality and reliability in the product but this is a fallacy.  Hear why.