Comment by Nimi | Hacker News Reader

Comment by Nimi | Hacker News Reader

Parent Full thread

I find the described interaction problematic from an agile standpoint: "People and interactions over processes and tools" - and then, they agree to give a lecture on TDD? You're describing literally shoving a process down the throats of unwilling programmers.

I'm not an agile expert, but it seems to me they should have refused such an arrangement, and plainly say: "Right now, you don't use an agile methodology. Us giving a lecture to your guys won't change that, it will simply be a waste of your money. You can rent from us an agile coach for minimum 6 months, and she will try to transition you to an agile methodology. This isn't a single decision you make and then 'bam, you're agile' - this affects hiring, you might even have to let go of programmers who won't play along. Don't pay us for a lecture that will simply anger your employees and achieve nothing."

Regardless of the usual agile vs. waterfall debates, what they did sounds to me very far from the principles of being agile.

Nimi, the agile manifesto does not say "People and Interactions _instead_ of processes and tools". Indeed, the preamble to the manifesto is quite specific that we think processes and tools are good things. It's just that people and interactions should take precedence.

In light of that, your contention that teaching TDD is "very far from the principles of being agile" is somewhat misguided. Quite to the contrary, to disregard processes and tools is what would be far from agile.

Thanks for replying.

Could you elaborate on your stance? Obviously, being agile doesn't do away with processes and tools. But giving a lecture on TDD to unwilling programmers seems to guarantee the "people and interactions" part of the equation will be unsatisfactory. There's also the question (at least in my mind) of how this should be viewed in terms of customer collaboration - without attending that lecture, it seems to me that there's no collaboration here, robin2's employer pre-ordered something useless, and that's what they got. Where am I wrong?

Obviously, teaching TDD in a collaborative and positive environment, and making sure the students are capable and willing to practice TDD would be very much "agile".

Just in case that's not clear: I'm sincerely asking that with humility, there's not a doubt in my mind you have a much better grasp of what agile means - you defined it...

Nimi, to be clear, I did not define agile; I simply collaborated in the effort that defined it.

In one post Robin2 described the course as OO, in another he described it as "C++". Those are two different courses so I'm not sure which it really was. However, back in those days we always did a brief lecture on TDD, as well as several other disciplines such as pairing, refactoring, etc. I was not at the class in question so I cannot comment on precisely what happened; but in general we tried to cover the bases of the various agile disciplines as part of any class we taught. Our customers knew this, and understood the implications. Object Mentor was, after all, the first and foremost of the Agile Transition companies. So all our courses had that flavor.

I see, thanks for clarifying. Actually sounds similar to a course I'm teaching at my university - supposed to be an "advanced C course for EE" (whatever that means), I threw in a bit of "intro to agile", what little I can try to teach from my limited experience (obviously Object Mentor is/was much better equipped for doing that type of thing). In a few weeks the reflection documents will be due and I'll know if it worked... :-)

In this case, I don't think the company can be blamed. As I recall, it hadn't asked for TDD training, it had asked for C++ training. So if anyone should be blamed it would be ObjectMentor for (a) hearing this as "introduction to object orientation", and (b) sending someone with rusty C++ skills.

That's what I meant - even if your employer asked for TDD training, ObjectMentor should have objected on the grounds that it will achieve nothing.

Well, ObjectMentor got paid, someone at the company got to tick a box to say that developers had been given appropriate training, and we got a break from real work.

Corporate training is an odd business, it has to be said.

At the time of that course, Micah was supporting a very large C++ application, and had been for some years. Were his skills rusty? I rather doubt it.

In any case, --- what does this have to do with the article in the title line? It seems odd to be talking about something my son did nearly a decade ago in response to an article I wrote today?

Reply on news.ycombinator.com