Pragmatic Approach to Agile Practices

To ascertain delivery assurance in software projects, it may be useful to ask the following questions:

  • Are we working on the right thing?
  • Are we doing it right?

A team and/or an organization that answers these questions convincingly shall feel confident in their progress.

  • “Are we working on the right thing?” might include:
    • Problem Definition
    • Adaptive Planning
    • Scope Management
    • Change Management
    • RAID (Risk, Assumption, Issue, Dependency)
    • NFR (Non-Functional Requirement)
  • “Are we doing it right?” includes:
    • Practices (Safety nets)
    • Quality Assurance
    • Review and Feedback
    • Governance
    • Metrics Reporting
    • Communication Plan

On many occasions, even though we all agree that we want to follow all the practices and processes, we might have to be pragmatic in customizing the practices/processes without compromising the delivery assurance.

To achieve that, one of the approaches that had helped me in my experience was to categorize the projects using certain complexity factors. They are:

Project complexity factors

Based on the values we choose for our complexity factors, we may arrive at different sets. 

For simplicity, let us consider a small company/business unit. A sample categorization might look like:

<sample data>BudgetTimeClient (Potential)Team SizeTechnical Complexity
Small<100K2-3 weeksNo visibility on Future work<5 peopleNot much
MediumBetween 100K & 500K4 to 12 weeksSlight chance of work5-15 peopleSome customization
Large>500K> 3 monthsClear Visibility2 or more teams of >10 people eachResearch/study to do

Then, using this above sample categorization, if we arrive at a guideline for the delivery practices/processes, it may look like:

 LargeMediumSmall
Sprints / IterationsYesYesNo
Sprint Length2 weeks1 weekNo
MilestonesMandatoryPreferableNo
Communication PlanYesYesNo
Metrics   
Release Burn-upYesYesYes
Sprint Burn-downYesMaybeNo
SPCR YesMaybeNo
Cycle TimeYesNoNo
Velocity ChartYesMaybeNo
Defect Turn Around TimeYesNoNo
Spill Over DefectsYesNoNo
Business MetricsYesYesYes
Engineering Practices   
Unit Test CoverageYesPreferableNo
Functional AutomationYesOptionalNo
Usability TestingYesIf the project is UI intensiveNo
UX ReviewYesIf the project is UI intensiveNo
Code ReviewYesYesNo
Performance TestYesPreferableNo
NFR ReviewYesYesYes
Continuous IntegrationYesPreferableNo
Continuous DeploymentYesOptionalNo
Staging / Performance Test EnvironmentYesPreferableNo
Project Management ToolYesSimple SpreadsheetSimple Spreadsheet
Metrics Tracking ToolYesSimple SpreadsheetSimple Spreadsheet

As usual, there are different opinions in the Agile World, in dealing with practices/processes. Here I’d just shared an approach that worked for me. 

Best Regards

SK

What do you think?

Leave a Reply

What to read next