In order to embrace change, as agile says we must, we must make sure that changes to the system going forward do not create excessive waste and/or delays. Part of how we can do this is to follow good principles, such as the Open-Closed Principle. This episode will explain this principle, and what it means.…

Last week I discussed the notion of refactoring, and why business people often fail to see the value in it. This week I explore what that value is, and how best to express it honestly.Av Scott L. Bain

Should a Project Manager allow a development team to spend time and resources on Refactoring? What is refactoring, and why do they want to do it? It seems to have no business value whatsoever. This episode, and the next, will explore this question and offer a way to resolve it.Av Scott L. Bain

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.Av Scott L. Bain

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.Av Scott L. Bain

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.Av Scott L. Bain

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.Av Scott L. Bain

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.Av Scott L. Bain

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.Av Scott L. Bain

Part 3 of my analogy on product quality.Av Scott L. Bain

Part 2 of my analogy on product quality.Av Scott L. Bain

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 ana…

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.Av Scott L. Bain

This episode relates a story that an ex-student and current colleague of mine related to me over lunch. I felt it was an extremely revealing and useful example of how requirements are misunderstood, the disasters than can result, and what to do about this.Av Scott L. Bain

Scenarios, like requirements, can often be too large to work with effectively. In this episode we'll examine why this is a problem, and some example of how we can deal with it.Av Scott L. Bain

The world has changed, and so has the technology we use to automate it. But a lot of the traditions that guide our efforts to control automation projects are based on the realities that existed in the past. Agile is a response to this, and this episode is all about why, and how this is so.Av Scott L. Bain

When collaborating with others, sometimes you will encounter reticence to ask or answer important questions. There are a number of reasons for this, but in this episode I will outline an approach I take to counter this, one which has served me well in multiple occasions.Av Scott L. Bain

When creating something new of value, one must always consider the context within which it will operate. Part of this is determining what, if anything, in the existing business processes will be effected by the new work. Failing to take this into account can have serious consequences, as this episode will demonstrate.…

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 ana…

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.Av Scott L. Bain

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.Av Scott L. Bain

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.Av Scott L. Bain

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.Av Scott L. Bain

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.Av Scott L. Bain

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 themAv Scott L. Bain

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.Av Scott L. Bain

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

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.Av Scott L. Bain

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.Av Scott L. Bain