After taking a great webinar from www.threebeacons.com and a good talk from Nathan Eror www.neror.com; I have a better understanding of Agile and how QA works in that team.  Using this information and the process of actually scoping an Agile project with my team-  I believe we have a general concept of how Agile works.

The first things we needed to understand were the words-  the jargon….  I have also learned that there are like 8,000 different ways to do Agile and every team takes what works from the best versions…
Release-  the actual final piece of software.

Iteration-  Time frame used to break up each development cycle within the entire release cycle.  Usually 1 to 2 weeks in length.  You want at least 4 iterations per release in order to take advantage of Agile methodology.

Epic-  It’s like a phase-  more like a block of functional pieces that are logically grouped together. Ex:  Login Page for Online Application

Story-  mini, functional pieces of the release within each epic.  Ex:  I am a Acme customer and I need to login to the Acme site with my email address.  Stories should be phrased as a functional need-  not CODE or DEV work.  Clients do not care about Tables and embedded graphics.  They want to see what works.

Unit Testing-  The heart of Agile.  Test everything as you build it.  Automate the testing if possible.

I will go into a whole different blog about testing-  I am sure I am about to learn a lot as I am being helped by a developer on setting up our testing, repository and bug tracking systems next week.

Basically what we learned is that Agile works if you sell it to the client as collaborative.  Your team MUST buy off on how iterations work and that everything- including testing and build deployment go into each iteration so that at the end of the iteration, you have a functional product for testing and sign off.   The product does not have to have all functionality, just what the client needs to provide a more defined scope as each iteration is completed.

We had to define optimal programmer hours available for each iteration.  We determined for our first project that we would sell 50 “points” for each iteration.  Those points were  based on programming hours and difficulty of each story.

That brings me to my next revelation-  you have to basically scope the project down to the story level before you can quote it-  so planning and pre-project fact finding is critical.  The idea is to pre-qualify the lead and plan the hell out of the project before you walk in with a presentation.  Then the client can shoot it apart through the Agile process by redefining needs.

I will post more as I get deeper.  What we have found makes Agile great for us-  although  a bit cumbersome for smaller projects.  We are finding our middle ground.

It should not matter if your company has five people or fifty people, you should always be looking to train your successor.  With a limited number of people replacing baby boomers in the workforce over the next 10 years, it is critical to grow up your internal talent.  I would like to discuss a few key points:

• Keeping your best people challenged- There are many reasons to challenge your team, but not all of them are obvious.  I believe that in order to keep a person on their toes, they should always be training their replacement.  I believe this lines up with a philosophy of not focusing on the immediate needs, but on a long term goal for your company or division.  Michael Gerber focuses on this core philosophy in his E-Myth series.  “Work on your business, not in your business.”  Without taking this high level approach, there is no upward push from behind and there is no desire for a manager to push themselves past the status quo.
• The talent pool is thin- between the retirement of baby boomers and the recession forcing companies to keep their very best talent, there is a smaller pool of available and qualified talent.  It is critical that companies look into their own ranks for upward promotion.
• Create an actual program- It may be a very loose structure, but there needs to be a defined line of succession.  Some companies may simply call their replacement an assistant.  Assistant manager, vice president, etc…  If a company or division has the resources a group could be assembled for mentorship and acceleration of talent.

As long as a the company leadership is developing its internal talent, the firm will always be pushing the bounds of their peoples’ ability.  Both managers and mentors will feel a sense of possibility in training their replacement; key positions will be deeper and junior employees will find upward learning and opportunity without looking for outside positions.  Keep in mind replacement costs and training without any plan for those key positions.