This is kind of a fun one.  I start by pointing out that, regardless of appearances, computers are not really doing any of the things we think they are doing.  Examining this fact, and it is a fact, leads to some interesting and I think useful insights.  Next week, I'll drive this idea into practicality.

Products that are difficult to use or illogical in their design can seriously impede their value.  This episode will examine an example of such a problem, from the author's own personal experience with a new car.

Last week I teased the notion that it's possible to bring your legacy code under better control by using a magic button.  While such buttons obviously do not exist, this week I'll outline how to get the value of such a resource anyway, at a manageable cost.

What is the best way to deal with the fact that most organizations have a high degree of vulnerability to the quality (or lack thereof) of the legacy systems they depend upon?  This week I'll discuss a thought experiment that helps us to understand this conundrum, and next week I'll show you what to do about it.

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.

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.

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.