In March, our newsletter explored the differences between Agile and the Waterfall methodology for software development.  In April, our newsletter introduced a blended approach to Agile development called Pragmatic Agile Development (PAD), and explained that PAD is designed to encompass all of the measurement and oversight of the Waterfall methodology (similar to approaches used by PMI / CMMI) with the nimbleness of Agile development, providing a methodology that yields the best of both worlds.  In May, we discussed the PAD Roadmap, the bible for PAD. 

This month, we discuss PAD Best Practices.  Below are the prior newsletters published on this topic: 

March newsletter: Exploring Agile Development
April newsletter: Pragmatic Agile Development - The Lifecycle Phases
May newsletter: Pragmatic Agile Development - The PAD Roadmap

PAD Best Practices
By following PAD best practices, your software development efforts will become productive, reliable and repeatable.  Best practices span several areas:

• Workflow - To ensure that everyone understands how items move from one status to another and to ensure that critical information is collected as statuses change, it is imperative to define your workflow and state transitions.  This should be done for each area of your software lifecycle:
  » Requirements Mgt - http://www.pragmaticsw.com/Newsletters/newsletter_2006_06_SP.htm
  » Project Mgt - http://www.pragmaticsw.com/Newsletters/newsletter_2006_09_SP.htm
  » Defect Mgt - http://www.pragmaticsw.com/Newsletters/newsletter_2006_08_SP.htm
  » Test Case Mgt - http://www.pragmaticsw.com/Newsletters/newsletter_2006_07_SP.htm 
   
• Requirements - When defining requirements, consider these best practices:
  » Use A Requirements Template - http://www.PragmaticSW.com/Pragmatic/Templates/FunctionalSpec.rtf
  » Scrub Your Requirements - http://www.pragmaticsw.com/Newsletters/newsletter_2004_03_SP.htm
  » Create Prototypes - http://www.pragmaticsw.com/Newsletters/newsletter_2004_02_SP.htm 
  » Provide Solid Naming Conventions - Prior to defining requirements, it is important to define your naming conventions.  For example, you may define your requirements with a client identifier (e.g. IBM-0001 may be the first requirement for IBM). 
   
• Project Management - When managing project tasks, consider these best practices:
  » Setup Holidays / Vacations - By establishing holidays and vacations up front, team members are agreeing in advance to their time off.  This can greatly reduce unexpected task slippage.
  » Review Resource Utilization - Review tasks assigned to each person to ensure that they are not over allocated. Remember that some team members work on multiple projects simultaneously, so you must coordinate tasks across projects.
  » Require Consistent Time Entry - Require that team members enter their time daily (or weekly).  Each team member should attach time to actual work done so that you can later evaluate estimate vs. actual time variances.  This process can greatly improve your estimating ability.
  » Record Objective Percentage Completes - As team members are recording percentage complete on tasks, force them to be objective (e.g. 0% means nothing has be done, 10% means that the person has reviewed the specification, 20% means that the person fully understands the specification, etc.).  By taking the subjective nature out of percentage complete, you will get a more accurate picture of how close a person is to being done with their tasks.  Another approach is to have them estimate remaining effort.  This is take from Agile's Scrum methodology and provides another way to more objectively ascertain percentage complete.
  » Review PAD Road Map Daily - The PAD Road Map specifies milestones, deliverables and measurements.  Review the PAD Road Map daily to ensure all items are being properly tracked.
  » Provide Customer Status Reports - http://www.PragmaticSW.com/Pragmatic/Templates/WeeklyStatusRpt.rtf  
   
• Test Cases - When defining test cases, create a traceability matrix where you can ensure that you have proper test coverage for each requirement.  Failed test cases should be matrixed back to the defect that was generated so that you can understand which test cases generated the most defects.  When defining test cases, remember to create positive tests (tests that exercise documented features), negative tests (tests that exercise actions that are illogical or designed to break the software: e.g. entering an invalid date, entering data outside specified ranges, etc), and regression tests (tests that ensure existing features are not broken with the new release).
   
• Defects - When entering defects, enter solid steps to reproduce the error, provide screen shots of errors, and have objective severities.  For example, a severity 1 may mean that it crashes the software, severity 2 may mean that it is a defect without a workaround, severity 3 may mean it is a defect that does have a workaround, severity 4 may mean it is a trivial defect (like colors, grammar issues, etc).  By defining objective severities, it is easy to agree on how severe a defect really is.
   
• Post Mortems - It is important to learn from prior releases.  By holding post mortems, you identify the things you did right and the things you need to work on in the next release.  Here is a sample post mortem report:
  http://www.PragmaticSW.com/Pragmatic/Templates/PostMortem.rtf  
   
• Support / Customer Management - Implement an easy to use support ticket system so that your clients can send support issues to your team and check the status of those tickets online.  Consider building a knowledge base so that your team can quickly identify frequently asked questions and solutions, make this knowledge base accessible by your internal team and external customers.  Implement surveys that provide feedback on how well your support and customer service are being implemented. 

Learning More About PAD
If you wish to learn more about PAD, here are some helpful links:

• PAD Overview Presentation
• PAD Best Practices Excerpt
• Additional PAD Information