Pragmatic Agilist

As you begin your large-scale agile transformation, you may find yourself printing out posters of The Big Picture , jack-hammering cube walls into pulp, and negotiating an awesome corporate site license for an Application Lifecycle Management (ALM) tool.  Plus you are likely putting rigorous product management, architecture and continuous integration practices into place, along with test driven development, and automated functional testing, without the last of which you will be completely helpless under your regression load. This is all heady and exciting stuff, and just keep doing it, but I would recommend that as you do, you put staffing at the top of your list of concerns, and put a fair amount of energy into the effort.  The Agile Founding Fathers weren't messing around when they put the words "Individuals and Interactions" at the very top of the manifesto.  Make no mistake--agile lives or dies by the quality, motivation, and communication of the people practicing ...

Are you new to the testing concept, or the "quality" concept, as I've learned to describe it?  I'm still learning, myself.  You may have seen some previous attempts, but I'm happier now.  Here's the framework I've devised most recently to help express how I think you need to design and implement agile quality tactics.  Your mileage will of course vary.  Experienced quality people please jump in and help me, where I've gone completely off the mark! Step 1:  Know what to test.   This can be a metaphysical question, but our friends at ISO have come up with a good practical starting point, code named SQuaRE:  Systems and Software Quality Requirements and Evaluation, aka ISO 25010.  It has 31 separate quality dimensions which roll up into seven "non-functional" categories, and one "functional" category. From http://a2build.com/architectedagile/Architected%20Agile.html?ISO25010.html There are many quibbles out there about whether...