mailSender(org.springframework.mail.javamail.JavaMailSenderImpl) {
host = ‘mail.authsmtp.com’
port = 2525
username = ‘user’
password = ‘pwd’
}

Hold on a second, if there was ever a time for you to recognize sarcasm it was here. Obviously agile teams don’t just sit around and sing with each other. Unless the song is about reverse boolean logic in C# then it would be a little useless, however there are circumstances where a little song and dance among team mates produces something even stronger then good code. It’s called a good team rapport, and I would argue that having a team which works well together (regardless of the activity), will always produce results which rival the best of code. Teams who play together will also work together towards the common goal, great software. It would be much easier working with a complicated and overly complex enhancement request if the product manager and the dev team got along. If they could even speak the same language (or sing the same song), wouldn’t that be the truly harmonious team? Isn’t that what all software development teams should strive for? Agile or not, a good, well working team will always produce amazing software. (Of course, that’s just in my experience in developing both in the Agile world and the Waterfall world).

Also, we’re talking about an AGILE team, it’s incredibly unlikely that a support technician is sitting at the table with the rest of the team. His work would prove to be a little distracting, but on the other hand, listening into his calls and understanding what common problems your users are running into will definitely help you build greater software. If anything, putting a support guy that close to you serves one great purpose, to make you see the problems your users are encountering and motivate you to fix them. (If not to make the software better, then to make the support guy less distracting by having less support calls to deal with).

@Ian

There is a line that needs to be drawn here, and a pinch of process to go with it. Ideas are either constructive to the creative process or a hindrance (depending, of course, on how you look at them, and of course, what the idea is). If I were to approach a project manager who manages building cogs with the idea for building a great pop can, that’s going to be nothing but a hindrance. Of course this is what the project manager is for, to steer the ship and help weed out the great ideas (like automation, Kaizen, new cog greasing apparatus) from the terrible ones. (Then again, if your programmer can’t tell that a pop can has nothing to do with a cog builder, then maybe you should rethink your hiring process….)

I love how you draw unnecessary attention to software development by calling it a “craft”. Sit down for a second and get off your pedestal, we’re not curing cancer here. Of course building software is different then other engineering tasks, there are some minor similarities (process, specifications, teamwork), but there are also major differences (try as I might, I can’t possibly become a structural engineer with my knowledge of JAVA). Explain to me in a simple straight-forward manner, how software development is NOT different from engineering work? I mean hey, every job requires a degree of focus and concentration, perhaps the heart surgeon would make a great programmer after all by your standards.

I’d be scared to have a developer on my team who didn’t ask questions or “call out for help”. Imagine how much disaster is going to befall the project when the “new kid” checks in code which he developed in solitude in his cubicle. It won’t integrate, it will be buggy, and we will spend a lot of time fixing the problems. All of which could have been avoided with proper, healthy interaction. (Again, healthy interaction, talking about the last Jays game at the water cooler isn’t really constructive now is it?)

“Real programmers” – such as you label them – are a dying breed of stone tablet chiselers who believe that the only way to develop software is their way, and resist change and collaboration with every fiber of their being. The “Real programmers” of today are taking a much more active stance when it comes to active collaboration. I’ve worked (literally, at the same desk), side by side with project managers, quality assurance testers, UI experts, database developers and more, and each time I do this I learn something incredibly important about their roles and how it relates to my “craft”. Even more importantly, I learn a lot about my role and how it influences them. The code I develop today is 100, even 1,000 times better then the code I developed 2, 3, 10 years ago. Why? Because once we learned to work together as a team and respect each other, we recognized the impact it had on the software and kept on collaborating with each other. We have teams which rival the top development teams at industry leading corporations.

@Simon

I don’t 100% agree with your answer to number 10. TDD is not a replacement for a fully functional QA, nor is it meant to be. TDD replaces the dreaded manual unit testing, BVT & Smoke test which does nothing but suck up time in a schedule, but it is no replacement for exploratory testing. There’s a saying at my company ” A developer makes a lousy QA “, and I’m sure it’s common in other places as well, but it’s 100% accurate in every scenario I’ve seen. Developers just don’t have the ability to see the forest through the trees and will only focus on the scenarios they know of. Exploratory QA is meant to test everything that developers aren’t thinking of, if anything, turning a QA into a developer is almost a guarantee that your automated testing will truly become an acceptable replacement for functional and regression testing. This leads me to the “Quality Engineers” section, are they developers? Are they QA? Are they both? In my experience, a QA Engineer is someone who learned how to write automated scripts, but if all they script is the functionality placed in front of them, are they truly able to see beyond the screen and think of the scenarios that they aren’t seeing? Or are they too locked into only testing what they can see because they don’t have the time/patience/skills to be able to move outside their box? I think QA engineers are important to achieving the 100% coverage goal (more like a dream, really), but so are regular “testers”. Something to ponder over.

As much as you love the Joel test (I did too the first time I read it), I believe you shouldn’t use it as the basis for judging an Agile team. There’s far too many “Depends” answers here which really take away from the focus of the test. Why not come up with something on your own which actually applies to Agile?

I’m not touching the “hug” question, there are far to many shades of “gray” in this area. My current table mate sings and hums to himself and I’m at peace with it. Throw on your headphones, crank the tunes and watch your fingers dance across your keyboard as you build something wonderful. Beats having to listen to him and also fixes the question about the “hug”.

“Seriously?” Yes. And no.

“…a pile of people running round in circles coming over with ideas and disputing them all day?” No. And sometimes yes. I see a bit of that, but I see much more focused team based work following agile principles, in our case XP. Take a read of James Shore’s Art of Agile book, as I think this quite closely resembles our environment, attitudes and working practices; you are clearly not familiar with it. And I have seen running round in circles in the environment you describe too.

“Do you think that the actual craft of writing software is any different by all other engineering work that requires focus and concentration?”(sic). A question to the very heart of the matter, and yes, I do. In fact I think the term “Engineering” is entirely inappropriately applied to software development. It’s not predictable and mechanistic in my experience, it is much more like building dry stone walls, it’s a cross between puzzle solving, research, heavy lifting and creativity. It certainly requires concentration a lot of the time, but sometimes that’s the opposite of what you need to get really great work done. Decompression and latitude work just as well and much better in certain circumstances. And thank you for your good luck, although I don’t think I need it. I have a strong pipeline of new recruits from a variety of backgrounds including researchers, new developers and seasoned pros, and they are forming the most capable dev teams I have worked with. No script kiddies in my world – although I would never turn them away.

I’m afraid I don’t recognise the “real programmers” that you refer to, although I confess I have done my best to avoid environments that don’t value the human interactions, and in which an ask for help would be considered either a distraction, or a sign of weakness. In fact I find it curious, and slightly offensive, that you would judge me and my developers and working environment as somehow inferior to what you believe to be right, and presume we are not capable, high capacity, high integrity, intelligent individuals doing great work, just because you don’t recognise or value the practices. I do recognise the respect and pride that you mention, but don’t see that in any way at odds with a bit of fun and a conversational and personal atmosphere.

And what’s wrong with giving the guy a hug? What experiences in your life lead you to believe that hugging and quality code are somehow mutually exclusive? (rhetorical questions, this isn’t Oprah).

Do you think that the actual craft of writing software is any different by all other engineering work that requires focus and concentration? Good luck hiring the new kids on the block and getting script out of them.

Real programmers work on a 2-3 teams of highly focused and respected individuals who take pride in what they build. Not “call across to other people to help” and break the focus of the whole group.

“give the guy a hug” hahahaha. Give him a hug and go be buddies. Who needs quality code writing anymore. Group hugging, yeah!