I am a pragmatic developer, I try to to use the paradigm to fit the situation. Agile is quite fashionable, but more to the point, it is very relevant to the industry I'm working in. This resource shouldn't be news to anyone.
The more I work in IT, the more I think this profession should be analogous to the law rather than mechanics or art. That is people pay for professional attention to detail, and perspective.
Despite a lot of words about it, testing isn't a big part of my personality; I test for confidence of “no stupid errors”. This article is currently quite chatty, not like lecture or meeting notes.

What is Agile?

  1. Communication. Agile is a “more female” structure, and is “better at relationships” ** with clients than other processes. This means clients needs are more likely to be met.
  2. TDD.
  3. Teamwork.
  4. Short dev cycle/ small releases regularly. Whilst these maintain the platform, they are purely to meet the stated requirements.
  5. Refactoring. This must not change the features, but is to reduce purely effects of short term planning of the previous point. These are not client facing. Having the refactoring separate to adding features means there is less pressure to release stuff. A fast solution is being responsive, a refactoring is being scalable, and cost efficient.

What is NOT Agile?

  1. Long drawn out dev cycles over months.
  2. Presence of “stuff” currently not needed. I personally find this hard. I define work good enough to be paid for, as having more technology than “absolute minimal”. If nothing else, the system I build should be manageable by a less technical person, as I may not be around.
  3. Absence of tools for software development. The simplest solution is always to use something that someone else wrote and tested earlier.

What would I like?

  1. Clarity by all parties that functional testing is part of agile. There is little point in showing clients work that doesn't function. Acceptance testing is something completely different, and should be validated by the client.
  2. Clarity that testing applications is detailed work, and having testcases makes it easier to manage the quality of testing.
  3. Clarity that my attention to TDD is a reduction in costs, as it makes people focus on goals, rather than being cleaver. Again, I find this hard.

** As far as engineering paradigms have a gender. I believe my description to be accurate rather than flattering of humanity.


I am touting a party line, but its a professional one. These are a few other peoples opinions.

  1. http://agilemanifesto.org/principles.html
  2. http://en.wikipedia.org/wiki/Agile_software_development
  3. http://www.agilealliance.org/the-alliance/the-agile-manifesto/
  4. http://www.agilemodeling.com/essays/agileCriteria.htm
  5. http://www.forbes.com/sites/stevedenning/2011/08/12/agility-is-not-enough-beyond-the-manifesto/
  6. http://en.wikipedia.org/wiki/Test-driven_development
  7. http://www.agiledata.org/essays/tdd.html
  8. http://butunclebob.com/ArticleS.UncleBob.TheThreeRulesOfTdd
  9. http://www.slideshare.net/RobMyers64/successful-teams-are-tdd-teams
  10. http://odetocode.com/Blogs/scott/archive/2005/07/27/the-problem-with-test-driven-development.aspx
  11. http://jonkruger.com/blog/2010/08/01/a-tdd-success-story/
  12. http://programmers.stackexchange.com/questions/41409/why-does-tdd-work
  13. http://www.methodsandtools.com/archive/archive.php?id=17
  14. http://lithespeed.com/how-not-to-do-resource-management/
  15. http://theagileadvisors.com/the-agile-team/there-is-no-i-in-agile/