Keeping the methods segregated wasn’t my goal. I was simply playing along with the idea that you only unit test public methods, because that’s what all the TDD gurus say. I like to use unit tests to pinpoint defects, so I kind of want to test private methods, which is where all the gutsy stuff happens.

So I really like your idea of adding test methods to the class being tested, but I also want to hear from the gurus: why exactly is it not a good thing to unit test your privates? And if you do put NUnit test methods into a production class, do you go ahead and decorate the production class as a TestFixture? (I guess you’d have to.)

I haven’t thought this through, but I know it’s kind of important.

Yeah, I liked pairing with you on that project too. Events like CodeRetreat attract the people who really want to learn.

I’m not sure how else one would go about it, but I’m sure my mind isn’t yet experienced enough to be able to say whether there aren’t any other approaches that would be equally or more viable.

It was fun partnering with you, and a really enjoyable day overall. I love events like that.

But they generally do single-track development so everything is on the main version control branch. Sadly, you can’t really test one new feature at a time.

pulls current source out of TFS and builds it on the testing system

…”

Is there a testing system? Or is this test minus one?

Do you already know there are well-defined boundaries to allow the test version to be built one feature at time? Or is this test zero?

If you don’t really love collaboration, and if you feel possessive about your code, and if you are super hung up on getting personal credit for things… then pair programming is kind of a band-aid.

If you don’t truly value openness, then a KanBan system may somewhat work for you… but it will be hugely compromised by vagueness and hedging.

That having been said, I really like the idea of actions creating thoughts and feelings. It seems backwards, but it’s a real phenomenon. If you’re not really into changing requirements, but you’re at least a little open to the idea, then working with changing requirements in an Agile-ish space is likely to update your thinking.

That’s why I totally endorse doing some Agile practices without management’s open support, if that works for you. It gives you (the dev team and partners) some benefits of Agile, helps you catch onto Agile principles, and lets management see and experience Agile benefits rather than talking them to death.

We are in the process of evolving into an Agile-based environment. I suppose some might say that we’re not agile, since we don’t meet some set of criteria, but really, who cares? Like Lou says, sometimes baby steps are the way to go.

The point is, it is starting to work for us. And when I look back at where we were before we started this journey, and compare it to where we are today in terms of productivity and developer satisfaction, I am quite pleased. There is much to do, but as an old-school waterfall-type project manager, I’m sold on the benefits of Agile at this firm in particular.

My approach is to apply constant but gentle pressure on everyone (opponents and supporters) to continue adoption of activities and thought processes that will help us to evolve to a more competent Agile environment. Will we ever get far enough along the scale to meet some set of criteria so that we can claim to be truly Agile? I’m not sure I care about that. All I care about is whether we are getting the job done in a competent and sustainable way. The rest will sort itself out.