This week I will relate the notion of "changing change" to the test-driven development process, in two different senses.

Part three of this series on changing our relationship to change deals with the concept of encapsulating variation in business automation.  This is expressed in non-technical language and should be useful to those that lead product develop...

This episode will explore another aspect of the agile design process, from a non-technical point of view.

If we are to be successfully agile, we must embrace unpredictable change.  But to do that, we have to fundamentally alter our relationship to change itself.  This is part one of a series about how I recommend teams accomplish this.

The fourth point of the Agile Manifesto, that we value responding to change over following a plan, has massive implications for the way agile teams are managed.  This podcast will introduce the issues that result, and will lead to the next...

This week I will answer the questions raised over the last four Agile Tips, each a different aspect of the Agile Manifesto.  I'll also set the stage for what to expect next from this series.

This week I will tackle the four point of the Agile Manifesto, with an eye toward my conclusion podcast next week.

This week I will cover part three of four in the Agile Manifesto, as preparation for my final entry in this series that will suggest how to address these implications in your organization.

This week I will investigate part 2 of the Agile Manifesto, as part of my series of four podcasts on the subject.

This week I'll examine the first point in the Agile Manifesto, as part of a series of four podcasts.

In this episode we will examine the roots of the Agile Movement, and delineate the Agile Manifesto that came from those roots.  This will begin a series of five podcasts that point out the implications of each item in this manifesto.

No matter what kinds of products and services an organization offers, there are terms that are specific to them.  These terms must be carefully defined and consistently updated as things change.  This podcast is all about creating suc...

This episode will introduce a useful framework for organizing requirements as the are identified.  Such organization can be very helpful in collaboration and validation throughout an agile process.

Various technologies provide us with the concept of "inheritance".  What should this used for, ideally, in an agile development environment?  This episode addresses this question in a way that should be interesting to non-technical pe...

The way we create business automation in the modern environment has been influenced by the strength of various innovations that have preceded us.  This week I'll introduce this idea, and then over the next few episodes will examine some of...

Last week I pointed out that Test-Driven Development, even though it is named as it is, is not a testing activity but rather the creation of an executable specification.  So how does this change how they are written?  That's the subje...

This week I wrap up my answer to the question of three weeks ago and is so going point out, perhaps, the most important aspect of TDD, and how to make sure it delivers all the value it is capable of.

Part two of my answer to the question posted two weeks ago.  There is one more to come, next week.  It may be the most crucial of these answers.

This is my first answer to the question posed last week.  There will be two more in future weeks.

Teaching Test-Driven Development, either in the unit testing form for developers or the acceptance testing that anyone can learn and do, this questions almost always arises at some point.  It's actually an excellent question and can yield ...

How does this principle apply to the notion of an agile process?  I think it fundamentally changes the way we create automation, and the value that automation ultimately provides.  This week I explain why.

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 thi...

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 ...

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 u...