This is not about agility, this is about acting responsibly.  Developers - stop making excuses not to test.  Managers / Product Owners - stop accepting myths about why testing isn't happening.  With that in mind, I present you the top developer testing myths (some of which I have even said).

Top Developer Testing Myths

1. I don't have time to test
2. The code is simple / its a small change / I'm too smart to need to test
3. There is all this legacy code, its too hard to test now
4. That's certain person's code, I don't want to touch it

I don't have time to test

When I left my previous employer, one of my goals with my next gig was to have it expose me to other domains and environments.  I wanted to get different perspectives, see Agile at different scales, and help spread successes as well as see the challenges and assist where I could.

I've been doing this now for a bit and I can tell you a few things for certain -

• The answers are far easier than the implementations
• You are not alone in your struggles
• People are succeeding even though they might not be considered 'Agile enough'

The answers are far easier than the implementations

'We have a large amount of dependencies in our projects.'
'Reorganize your work so you don't have dependencies anymore.'

'Our testing and regression takes too long.'
'Test sooner and automate as you go.'

'We have a large amount of dependencies across teams.'
'Create cross-functional teams that are customer focused to remove dependencies.'

'We have an international, cross-time zone, development team so stand-up times are impossible.'
'Restructure your teams so everyone is together.  Oh, and get rid of all the walls between members, make sure everyone is pairing, and for bonus points make sure everyone is using a PowerBook and they sit on beanbags.'

My team and I are frequently asked for advice or pointers with some very common Agile or organizational problems.  While I personally like the discussion, the reality is I hate the answers.  I hate the answers because its the easy out.  Looking at problems and providing a solution is easy. Even helping create a plan to address the problem is easy.  Implementing the solution or the plan is hard, ripe with unforeseen problems, potentially painful, and most definitely will take a long time.  Providing an answer or a plan takes a few minutes to an hour.  To implement these solutions and actually have them stick will take a large amount of time and commitment.  Do you want to address quality issues?  You can't just have train people in TDD and test automation and expect everything to fall in place.  Chances are you will have to look deeper - look at your hiring practices for example.  Are your interviews focused on obscure API calls or are they focused on quality?  How do you create an organization that actually cares about quality, and by doing so not create one that is scared of ramifications of creating an unforeseen bug?

If you work in a traditional matrixed organization, trying to create cross-functional teams isn't as simple as creating a team and telling them go.  There will be headcount issues, territorial issues, domain knowledge and specialization concerns that have to be addressed.  You might actually be worse off for 6 months or a year - can you commit to that and see the light at the end of the tunnel?