1. SUCCESS FOR IT
PROJECTS
-AGILE WAY
FAIL FAST, FAIL EARLY
JOSEPH V CSM CSP
JOEVGH@GMAIL.COM
678-333-6534

2. THEME OF DISCUSSION
Our Agile theme of discussion
• Fail early and fail fast
• Fail with cheapest cost possible**
IT projects : Issues
• Schedule and Cost Overrun
• One reason is the early failures in project
• Project successfully completed almost always had budget
and/or schedule overrun.

3. AGILE FACTOR
Agile addresses few long standing issues
• Requirement Clarity
• Most business owners don’t have clear requirement as IT
wanted
• But Agile provides solutions of iterative deliveries, which
provides a requirement clarity on the go.
• Customer Satisfaction
• Early agile demos give an opportunity for the customer to give
feedback

4. FAIL FAST AND FAIL EARLY

5. VISION TO DELIVERY
Vision
Product Roadmap
Minimum Marketable Product (MMP)
High level Feature set creation**
Release Planning
Creation of Feature -> Epic -> Stories
Iteration Zero
Story Pruning
Sprint Process - Fully Automated Testing
Iteration Hardening
Certification and User Acceptance
Rollout planning
Governance and Metrics

6. PRODUCT VISION
Why: Need or Opportunity
Identify: Product Category
Customer: Who will buy it
Differentiator: Key benefit for customer
Sales: Compelling reason to buy this product
Marketing: Competitive advantage, Primary attraction. Wow
Factor**

7. PRODUCT ROADMAP
High level feature set
Planned Releases
List of significant features in every release
Approximate Target Release Time
Significant milestones based on MMP

8. DERIVE “MMP”
Minimum Marketable Product
• Minimum features ready to use for target customer group
Primary Factors
• Software Development and Hardening (Testing & Certification)
• Software readiness evaluation
• Software Implementation
• User training
• Software Support
• Software Upgrade
Identify product owners early in the cycle
Derive minimum functionality required for group target customers
Major area of failure
• Minimum Functionality for target group is unknown most of the time
• Many product owners couldn’t quantify “done definition” on time

9. HIGH LEVEL FEATURE
SET
Estimate high level feature set
Use relative estimation
Break it into smaller size perhaps to 2-4 man months
• Create Epics
Make use of historical information if any for estimation
Create a mapping from feature to epics
Avoid
• Absolute Estimation

10. CREATING A PRODUCT
BACKLOG
High level feature to epics
Create epics in a traceable system
Provide relative estimates
Refine estimate using affinity estimation on Epic

11. RELEASE PLANNING
List Total Capacity
List External Delivery Commitments (Contracts)
List major defect fixes required
List features to be released
List the Priority
Create a Release Plan
•
•
•
•
Iterative Internal Releases
Major External Releases
Minor External Releases
Patch External Releases

12. RELEASE BACKLOG**
Output from release planning
What is required for planned releases
Automated Burn down chat

13. NEED OF AN AGILE PMO
Scrum doesn’t track the below items
• Cost
• Schedule
• Risk
Need the Agile PMO for the same
Keep the budget away from Sprint teams and allow them to
focus on quality
Control the product backlog for Cost and Schedule

14. RELEASE BACKLOG PRIORITY
Priority will be as follows
•
•
•
•
High Risk High Value
Low Risk High Value
Low Risk Low Value
High Risk Low Value

15. ITERATION ZERO
Evaluating Readiness for Sprints
Infrastructure(Dev/Test Environments)
Create Product Backlog(Epics and Stories)
Story Pruning Process
Globally Distributed Team(communication and Governance)
Training (New Teams)
Establishing Agile PMO
Core architecture discussion
Team readiness(Hiring, Roles etc..)
Consider Spikes for “High Risk High Value”

16. STORY PRUNING
Very important for global teams
Establishing Clear Requirements in Stories
Evaluating affinity estimation
• Avoide technical debt
• Close to 100% Automated testing
Splitting and merging of stories as required
Reestablish release baseline**

17. SPRINT BACKLOG CREATION
Factors to consider
• Consider Global Teams
• Consider Base velocity for each team
• Consider velocity progression
• Evaluate Readiness to Sprint Teams
Create Sprint backlog for Team.
• It could be single or multiple
• Recommended to add different sprint backlog.

18. AVOID “IVORY TOWER
ARCHITECTURE”
Avoid separate software architecture teams
• Sprint team acceptance is low for external design
Embed initial product designers/architects in sprint team.
Keep them as ambassadors of original design
Initial product designers will safeguard their vision to the
release
Compare and contract the ideas from sprint team against
original though process.

19. SPRINT- FEW POINTS
Remove impediments on time especially for global teams
Implement TDD
Implement Continuous Integration
Implement Continuous Delivery (Optional)
Sprint Demo and Retrospectives

20. ITERATION HARDENING
Tight hardening is required for Critical applications
Financial applications and Online retailers etc…
Length of hardening will be higher as technical debt is
higher
Near to 100% automation reduce to length of hardening
Amount of Manual Testing extends the duration
Sprint delivery quality extends duration
No of integration to external systems can increase duration
Exploratory testing is key for higher quality

21. CONTINUOUS DELIVERY
ROI still not clear.
Initial setup is hard
Maintenance is also difficult
More tools are available in market
As tools get cheaper and setup is easy, CD will be viable
choice for all teams

22. METRICS
Measure and Improve requires metrics
Metrics
• Productivity
• Quality
• Effectiveness of process
• Earned Value
• Predictability of the process
Adapt your metrics based on your organization's need

23. PERFORMANCE IMPROVEMENT
Metrics drives the process improvement
Present metrics to scrum masters and development
managers.
Make that as subject for discussion in retrospective.
• Let team come up with suggestions

24. VELOCITY PROGRESSION
Ideal Hours vs. Story Points
Establish Story points early in the cycle
• T-Shirt Sizes: S,M,L,XL, XXL
• Even though ideal hours are used scheduling
Story Point shows velocity progression sprint team
Ideal hours get reduced for a T-Shirt Size as teams gains
more knowledge

25. DOCUMENTATION
Very little documentation by its nature
Creates walking knowledge centers
Creates Job Security for many development resources
Need to avoid this SPOF
Creates documentation as Sprint progress
Involve a BA for core set of functionalities and
implementations
All functionalities have to be documented somewhere
outside code
Encourage Development department to create intranet pages
for complex functionalities.

26. FAIL COST EFFECTIVELY

27. COST CONTROL
Highest Cost Overrun
• Initial phases
• Till requirements are clear and design is stable
Major Mistake
• Staff the project even before design is stable
Governance
• Tight Budget control during initial phases
• Tight timelines on initial delivery
• Try different ideas in parallel
• Balance the budget control with schedule overrun
Use Global Teams
• Establish your failures early at cheaper cost.
• Can shutdown quickly if design not ready

28. COST CONTROL - AFTER
DESIGN IS STABLE
Engage Global teams – Easy Wins
• Exploratory Testing
• Sprint+1 creating automated testing script
• Sprint+1 Regression Testing
• Sprint+1 Defect fixing
• Increasing Coverage on TDD
Creating Product for international market
• Internationalization(currency and language)
• Global implementations(business rules for different nations)

29. COST CONTROL –
SUPPORT
Engage Global Teams
•
•
•
•
•
•
•
•
•
Call center
Data Migration
Rollout
Creating Run books
BPO
KPO
Infrastructure Support
Database support
Application Support

30. STRESS ON 100%
AUTOMATED TESTS
Leave least “technical debt” during development
Total cost ownership will be low
Can get to production as low as couple of days to couple of
weeks.

31. BY
JOSEPH V
JOEVGH@GMAIL.COM
678-333-6534
AVAILABLE FOR EMPLOYEMENT OR SHORT TERM
CONTRACTS IN ATLANTA GA