Success recipe for new IT projects-Agile way. Fail Fast, Fail Early
- 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.
- 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