The first piece of advice I give people when they ask for the keys to our success: don’t hire too many testers.

I am currently reading the excellent "Debug It!" book written by Paul Butcher and I wanted to share with you some of the little gems that I have found in it.

Testers cling to the concept of an independent QA team for many reasons, but the main reason is fear, specifically:

* Fear that they will lose their QA identity

* Fear that if they report to a development manager, they will loose support and programmers will get priority

* Fear that they lack the skills to work in an agile team and will lose their jobs

* Fear that when they’re dispersed into development teams they won’t get the support they need

* Fear that they, and their managers, will get lost in the new organizations

We often hear of QA managers asking questions such as “My company is implementing agile development. How does my role fit in?”. This is directly related to the “loss of identity” fears.

Source: “Agile Testing”, Lisa Crispin and Janet Gregory, Addison-Wesley, 2009

As you move ahead, keep in mind the following:
* Never confuse the map with the journey - The project plan is only an outline (and a guess at that), so you should believe the team’s results and not the plans. Remember, it is the achievement of the objectives that is important, not the production of artifacts or the completion of activities. Be careful not to confuse the ends (objectives) with the means (artifacts and activities).
* Adopt the attitude that continuous planning is a good thing - In every iteration, expect your plans to change (albeit in small ways if your planning is effective). Don’t fall into the trap of thinking that the plan is infallible.
* Mature your process alongside your team - Tune the working practices alongside the plans, adapt your team’s skills as necessary to improve over time.
* Be prepared to cut your losses - Canceling bad projects early is success because you save time, money and resources that can be applied to better opportunities.
* Be honest - Without objectivity and honesty, the project team is set up for failure, even if developing iteratively.

Source: “Managing Iterative Software Development Projects”, Kurt Bittner, Ian Spence, Addisson Wesley.

Transitioning from a traditional approach to iterative software development is more a change of mind than a schedule adjustment. So try to be honest… or at least as honest as you can be ;o)

Over the years I have come to describe Test Driven Development in terms of three simple rules.

Is agile a remedy for failing software projects? I think a lot of software projects should fail, and the problem is you just don't know which ones until you're pretty well into it. So is agile a remedy for it? No. I think software projects are still going to fail because there still [will be] the promising ideas that don't work out in practice. One thing that agile development can give you is to make sure those projects fail faster, sooner, cheaper, so you can get on with the next thing.

Source: Kent Beck, "Extreme Programming inventor talks about agile development"

http://www.computerworld.com/action/article.do?command=viewArticleBasic&articleId=9046399 

If you want more effective programmers, you will discover that they should not waste their time debugging - they should not introduce the bugs to start with.

E. Dijkstra, The Humble Programmer, 1972.

What I see when I travel and talk to customers, participate in conferences and have discussions with experts around the world is that software development is very much still an immature discipline. We still rely on too much old work. Personally I am convinced we will change that dramatically, but it is a very slow process.

I have been working on process improvement and new technologies for many years now, starting with component based development and then adding to that object orientation and now aspect orientation. I've been involved with new technology since the sixties, and I've been more optimistic than most -- it's my nature, but we are still struggling with basic stuff for many reasons. We will continue to struggle for a couple of decades more, I think.

Ivar Jacobson

Source: http://www.builderau.com.au/strategy/designprinciples/soa/80-of-software-is-no-brain-work-Ivar-Jacobson/0,339028846,339281019,00.htm

As a rule, software systems do not work well until they have been used, and have failed repeatedly, in real applications.

Dave Parnas, Communications of the ACM (33, 6 June 1990 p.636)

Program testing can be used to show the presence of bugs, but never to show their absence!

Edsger W. Dijkstra 

Source: Notes On Structured Programming, 1970, at the end of section 3, On The Reliability of Mechanisms.