We had all of the best intentions as we went about our business, calling ourselves Agile, but we unfortunately did so rather haphazardly. We suffered from Product Managers who couldn’t do the job – understaffed, untrained and, in the final analysis, unavailable – as well as executives who seemingly could do nothing about that dire predicament. We also went almost two years with little or no professional Agile coaching (which was more my fault, as Agile Manager, than anyone else’s) and therefore continued to flounder, all the while blaming the development teams who in most cases were actually doing quite well, under the circumstances. We allowed schedule pressures to compromise principle after principle, and then wrung our hands in frustration at the inferior results that those poor decisions produced.

I also observed first-hand another oft-cited phenomenon of Agile: that it will reveal all of your weaknesses. That it did; we just didn’t do anything with that information, no matter how many times Agile flung it up in our faces.

Attempting to “go Agile” was an interesting enough journey, in fact, that I got material for two books out of it (“The Real-Life Adventures of AgileMan” and its sequel, “More Real-Life Adventures of AgileMan”). And I don’t think that would have been true of any other two years in my 22-year career! So that’s something, I guess…

Likewise, it is to my great personal chagrin that people are using context-driven methods as an /excuse/. Waa-waa-waa my HR people won’t let me do this my facilities people won’t let me do that.

Context-driven says adapt your process to the /essence/ of the business – which turns out to be a non-trivial task. All that stuff above is adapting the process to the /accident/.

There is a big difference.

The context of my question is that on more than one occasion I have worked with organizations that due to a circumstance beyond their control, Geography, they will never be able to hire the appropriate collocated team. So, what these teams do is continue to swim upstream with the best possible hires they can find that as you say in this post write “crappy code on a regular basis.” They continue to hope against all logic that eventually the “crappy coders” will become competent by the good example set by the minority.

It seems that companies in this circumstance would be better served to widen their pool and allow for a distributed team or a partialy distributed team. Yes, you’re sacrificing the one principle of a colocated team but isn’t that better than sticking to this principal at the expense of all the other practices (TDD, Refactoring, Iterative Design, No Crappy Code)?

P.S. You can coin a new XP buzzword, NCC

I have a question regarding “Was your Whole Team together in one place?” I understand that this is optimal but what team do you think would perform better ? A team of 8 distributed developers all of whom had a high level of competence and agile aptitude (who proactivly communicate in spite of being distributed) or a collocated team of 8 with the typical mixture? (In my experience this looks like two strong performers with agile aptitude, 3 average programmers, two terrible programmers and one saboteur).

I’d be interested in your thoughts on this, I’ll follow up with the reason for the question.

– Jonathon