Pragmatic Agile Development - The PAD Roadmap
 
  May 2007 - Pragmatic Software Newsletters 
 
 

Newsletter Sponsors

Software Planner is an award winning  web-based solution for managing the software life cycle.  Tracks customer requirements, defects, test cases and allows document sharing.  Provides project management, with importing/exporting from Microsoft Project®, customizable dashboards and Microsoft Outlook® Synchronization. 
Software Planner Awards:
::
Best ALM/QA Tool
::
Best Project Management Solution
::
Best Bug and Defect Tracking Tool
Software Planner Upcoming Events:
:: May 17/18 - 2007 Star East, Orlando, FL

Pragmatic Agile Development - The PAD Roadmap

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.

This month, we discuss the PAD Roadmap, the bible for PAD.  Below are the prior newsletters published on this topic: 

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

The PAD Roadmap
The PAD Road Map is the bible for your release.  It is the central communication tool as you progress through the release.  Below are the sections defined in the PAD Road Map:

  • Schedule - Since PAD uses a locked duration for each phase of the release, a documented schedule is imperative.  This section of the PAD Road Map has a visual calendar that shows when each phase of PAD begins and ends.  It also identifies employee vacations and holidays so that everyone is aware of when people will have time off.
  • Requirements - This section of the PAD Road Map identifies all the requirements you wish to deliver in the release.  Each requirement is listed in priority order.  Each week, your team will work on only the high priority items and will meet to discuss if any new requirements need to enter into the release.  During the weekly requirements review, requirements that have been fully coded will be staged for quality assurance and other non-high priority requirements will be reprioritized to enter the queue for work (work is done only on high priority requirements, this allows your team to stay focused and allows new requirements to enter the release at anytime during the coding phase).
  • Customer Facing Defects - This section of the PAD Road Map identifies any customer facing defects that are being fixed in this release.  If you are developing a new product (no prior releases), this section is skipped.  Having all customer facing defects exposed in the PAD Road Map draws attention to them by the development team and ensures that once the new release is in production your support team has all the details of each customer allowing them to easily contact the customer to communicate the resolution of each fix.
  • Features - This section of the PAD Road Map identifies the marketable features that will be introduced with the release (you could have several requirements that make up one feature).  Having this in the PAD Road Map ensures that all marketing materials explain the features with the same nomenclature.  These descriptions are used for help guides, documentation, and marketing materials.
  • Milestones - This section of the PAD Road Map identifies all of the critical activities and measurements that are collected during the PAD process.  It identifies meetings that need to occur, statistics that show if the release is tracking towards plan, and deliverables for each milestone.
  • Percentage Complete Definitions - This section of the PAD Road Map identifies what constitutes a specific percentage complete.  Many people will mark percentage complete as 50% when they begin work, 80% as they progress, and 99% until finally complete.  This is very subjective and not very meaningful.  An alternative way to determining percentage complete is to objectively define what each level of percentage complete means.  For example, here is an example for the coding phase:
    »  0% - Not started
    »  15% - Requirement(s) reviewed and understood
    »  25% - Data objects completed
    »  50% - Business objects completed
    »  75% - User Interface and other objects completed
    »  80% - Code complete/unit testing completed
    »  95% - Code complete/code cleanup/refactoring
    »  100% - Code complete/ready for QA
  • Server Configurations - This section of the PAD Road Map identifies the QA, User Acceptance and Production server configurations.
  • Success Criteria and Reward - This section of the PAD Road Map identifies measurable success criteria and the reward for a successful PAD Release.  It is important for everyone on the team to know what constitutes a successful release.  It could be a certain amount of billable work, a release to production with no severity 1 or 2 defects, a project that is delivered on time and on budget, etc.  Likewise, it is important to reward those who contributed to the success of the project.  By identifying the reward up front, it encourages team cohesiveness, as everyone invests in delivering a success project.

Want to review a template PAD Road Map?   Click here: PAD Road Map Template

Learning More About PAD
Our upcoming newsletters will drill into the details of utilizing PAD to consistently manage your software lifecycle.  Next month, we will discuss PAD Best Practices.

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

Helpful Templates

Below are some helpful templates to aid you in developing software solutions on-time and on-budget:

About the Author
Steve Miller is the President of Pragmatic Software (
http://www.PragmaticSW.com).  With over 21 years of experience, Steve has extensive knowledge in project management, software architecture and test design. Steve publishes a monthly newsletter for companies that design and develop software.  You can read other newsletters at http://www.PragmaticSW.com/Newsletters.asp.  Steve's email is steve.miller@PragmaticSW.com.


 

Pragmatic Software Co., Inc.
383 Inverness Parkway
Suite 280
Englewood, CO 80112

 

Phone: 303.768.7480
Fax: 303.768.7481
Web site:
http://www.PragmaticSW.com
E-mail:
info@PragmaticSW.com