Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

An approach to scaling Agile in Mid size Enterprise Application Stack/ Products

630 views

Published on

Scaling Frame Works are great guideline for Scaling Agile but teams and companies who are working Scrum and/or Kanban for sometime now can scale Agile Implementation following certain disciplines and structural approached and . This talk is to discuss one such implementation.

Published in: Software
  • Be the first to comment

An approach to scaling Agile in Mid size Enterprise Application Stack/ Products

  1. 1. An approach to scaling Agile in Mid size Enterprise Application Stack/ Products Discuss Agile – Delhi June 2015 Scrum Bangalore 14th Meetup - September 5th 2015 Saikat Das CSM, CSP, SAFe Agilist, ICP Agile, DAD- Yellow Belt
  2. 2. • Case introduction | Profile of the Company • What is scaling Agile in brief and why difficult • Some Scaling Frame work • What is the motivation to look for Scaling Agile • Journey pre and post scale • The Model (Team and Cadence) • Outcomes • Factors enabling Better Success • Challenges during scaling Agenda
  3. 3. • This Scaled Agile Delivery model of non-food eCommerce platform of one of the onsite’s biggest retailer • around 6 lacs unique visitors per day; web demand of 1 million GBP; 1500 orders per hour, 18K orders per day • Application Stack: • Oracle ATG Commerce, Sterling commerce (OMS), Oracle PIM (product induction), Tibco IL (business logic), Liferay portal(market place) supported by in-house Customer profile management system, Integration with third parties for payments, recommenders, Customer Reviews etc. • The following slides shares details from the actual Scaling of Agile in the organization for few verticals. • some information are not shared to respect confidentiality of organization specific data Introduction
  4. 4. • Repeating agile successes embodied in large team across an organization (could be multi-location ) • Applying agile thinking to cross- product projects • Applying agile and lean thinking to development organizations • Transitioning from small-scale agile to large-scale one What is Scaling Agile
  5. 5. • Complex and takes time • Demands Discipline, Genuine Adaptation, Cultural Changes, Top Down Approach and Persistence • Requires Agile maturity for progress of Scaling and provide solid foundation. • There is no perfect scaling formula that guarantees success for every company. • Standardized Frameworks (Safe, Less, DAD etc.) definitely helps when you are blank slate but sometimes it needs certain organization specific tailoring. Why Scaling Agile is difficult
  6. 6. SOME OF THE SCALING APPROACHES
  7. 7. Scaling and Agile Onion Team Level Program Level Portfolio Level
  8. 8. Environment Teams Leadership Values & Principles Process Business/ Market Drivers … just to show major areas for consideration Number of Products developed using Agile Teams working on the same product Agile Maturity and Enterprise Discipline Organizational Distribution and complexity Amount of Business involvement Geographical Distribution Agile Transformations are Multidimensional
  9. 9. • What is your primary business goal for improvement? (decreased Time to market, increased customer Satisfaction……) • Do you need to scale all teams/ department etc. to reach that goal? • What kind of scaling is more important to reach that goal? (vertical or horizontal or both) • What scaling practices could help to reach that goal? • Are there any quick wins by using low effort, high impact practices? Questions on why scaling?
  10. 10. Types of Scaling Verticalscaling Horizontal scaling
  11. 11. What is generally Scaled • Number of Teams? (vertical) • Coverage of Value Stream ? (horizontal) • Business, Engineering, Support teams, Operations etc. • Number of Organization Levels? (both) • Classical Functional: Team, Department, Division, Enterprise • Team, Program, Portfolio, Business Unit, Enterprise • Large Scale Scrum (LESS): Feature Team, Requirement Area, Product • Levels of Inspect and Adapt Cycles? (both) • Iterations, Release, Road Map, Product Vision, Business Model
  12. 12. • To synchronize and align delivery of number of teams to realize Ideas/ Business Epics at portfolio level • Enable business leaders to prioritize aptly and control/cancel failing projects early, lowering risk and potential waste. • Reduce longer release cycle; respond fast to changing marketplace. • Deliver value early and often to see results (ROI) quickly • Improve collaboration between business leaders and development teams to build stronger relationships and overall team spirit. • Stop missing critical delivery dates with predictability & cadence • Have matrix at Sprint, Release and Program levels • Address quality issues due to late integration and high dependencies on other systems • Provide systems view where agile methods (Scrum, XP, Kanban) constraints view beyond the team Our motivation to look for Scaling Agile
  13. 13. Setting foundation (essential for scaling) • Pilot in few verticals, focusing on enabling Teams to deliver high value, high quality work product incrementally and iteratively • Incorporating feedback loop with actual customers • User Advisory Groups, Core Agile Group • Introducing Agile COP and Agile coaches building strong Scrum Masters • Inculcate culture • Of Quality • Of cross-team collaboration and transparency • Shifting roles of teams, management, executives • Resist temptation to solve enterprise problems just yet • Be wary / mindful of them • Have roadmap, but take incremental approach
  14. 14. High Capability, Low Willingness • Have high degree of awareness when coaching; • be ready to jump in and actively facilitate. • Provide “personal” coaching - 1:1. • If no change in a reasonable amount of time, then switch team/member High Capability, High Willingness • This is your “sweet spot” where you ideally would like to have everyone on your team operate. • This gives much greater chance for operating successfully under Agile. Low Capability, Low Willingness • Consider immediate switch-out. • Poor attitude combined in inability to deliver can be a toxic combination to the team. . Low Capability, High Willingness • This is your second choice of team members. • A good attitude with willingness to learn and embrace Agile values and principles greatly contributes to a high performing team. • Over time, technical skills can be learned. LowHigh Low High Willingness Capability  All 3 levels with high capability, high willingness (Appendix) Setting foundation - team consideration (essential for scaling )
  15. 15. Our Agile Journey pre-scaling • X Scrum teams in 2012 in India • Release Management Team to do Air traffic control and align Teams’ output as every Team had different sprint cycle • Had to wait 2 weeks for everyone to align and do release every 3-4 months • Pre Release planning for 2 weeks to get release plan ready • No Dev Scrum team in onsite all based out of Bangalore. • UX used to happen in onsite • UX and requirements was handed over to Bangalore team during Release & Sprint planning • Many Integration and post production deployment issues. • More of Scrum Fall 
  16. 16. Agile Journey for scaling • X + n Scrum Team across India and onsite. • Decentralize work & decision making • To have better coverage of Daily Time window, few Dev and Test members travelled on rotation to onsite and vice versa to empower cross functional learning. • Apply cadence, synchronize with cross-domain planning • Moved to 2 release cadences for the teams either fortnightly or monthly • Followed Service oriented approach; service and product decoupled from each other. • Service would precedes the Product Sprints, if otherwise tested through stubbing . • Held Agile focused educational workshops with the core teams • Disciplined Environment Refresh to better utilize the Real Estate • Assumed Variability and preserved options for that and improved with integrated learning cycles.
  17. 17. Agile Journey for scaling, continues…. • Hosted Big Room release planning workshop with PO, Architecture, Scrum Team and dependent teams were introduced. • For cross geography we used Tele Presence/ Video Conferencing • Continuous Backlog grooming introduced with Feature Driven teams (wherever Applicable) to best leverage domain and technology expertise. • More Telepresence and Visual Collaboration tool added for meetings • Continuous Integration and Deployment in the Production like/ Staging Environment • Incorporated Lean & Kanban principles – Visualize and limit WIP, reduce batch sizes and manage queue lengths for some Value Flow Streams. • Used Kanban for support work with WIP management. • Created SM Community of Practice (CoP) • Share experiences, common “templates”, metrics, etc.
  18. 18. Domain 1 Domain 4 Domain 5 Non-foodOnlinePortfolio Domain 3 Domain 2 W2 W3 W4 Sprint Sprint W1 Domain 6 W6 W7 W8W5 Sprint Sprint Domain 7 Domain Teams Scrum Teams Scrum Teams Scrum Teams Scrum Teams Scrum Teams Scrum Teams Scrum Teams Sprint and Release Cadence
  19. 19. Distributed Agile Team – Enterprise Level Location B Location B Location B Location B Program Manager Program Manager
  20. 20. Group Roles – Enterprise Level Product Ownership/ Management • Pool of Product owner/ managers • Some of them plays Lead PO for one or more programs based on experience • contribute to understand the product/ business vision and requirement • Add items to Product Backlogs Program Management • Pool of Program managers • Some of them plays Lead PO for one or more programs based on experience • help to run programs achieving Business roadmap Scrum of Scrum • For all the scrum in a vertical or Domain • Sometime cross domain to handle bigger programs Lead PO PO Group Lead SM SM Group Lead PgM Pgm Group
  21. 21. Team Structure & Roles – Org level
  22. 22. Team Structure & Roles – Scrum level Scrum Master Test Test/ Automation Dev Tech Expert/ Dev Dev Dev Test/ Automation Dev UX DBA DEV OPs UX Testers SME Product Owner
  23. 23. W1 W2 W3 W4 W5 DevOps Overnight Automation Regression Pack Shared Resources Like UI/UX, Architect Sprint 1 Sprint 2 ALIGNMENT Chief Architect/ Architecture Board [responsible for initial technical architecture of Epics and Features] ReleasetoProd Execute S p r i n t P l a n n i n g S p r i n t P l a n n i n g Scrum Team & Sprint Backlog Release on Demand HardeningActivities Product Backlog UX Regression pack Chief Product Owner [responsible for initial Idea and Epics]
  24. 24. Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec Jan Coordinate release planning with generic framework Planning cycle for next release RELEASES Release Cycle
  25. 25. Continuous Release Plan & Backlog grooming Cadence
  26. 26. Continuous Backlog Grooming • Continuous Backlog grooming 3-6 hours a week between PO, Architect and focused group from Scrum team • Grooming done for next Sprint – Story Split, Acceptance Criteria Finalization, Estimation, Business Value, Dependency call out etc.
  27. 27. Release Plan and Program Board
  28. 28. States and Sub-states for Managing Engineering Flow IDEA REFINE BUILD DEPLOY LIVE To do In Progress Done To Be Refined In Refine Ready for Build In Build In Test Ready to Deploy In Deploy Deployed Done  High level T Shirt sizing done  Features called out as feature story  Tech design blue print created  High level Technical Dependencie s called out  High Functional Dependencie s called out  Epics reviewed with Technical Expert  Low level Functional dependencies called out  Low Level Technical dependencies called out  User story with clear acceptance criteria defined  Low level Tech Design discussion Start  NFR's defined  Business value defined at story level  Stories prioritized in the backlog  Story definition and technical documents discussion developers  MVP definition created  Estimation done in story points  Wire frames created and reviewed  UX and Tech design starts  User stories walkthroug h by PO  Wireframes 1st level review by PO  Tech design reviewed by SA  Test scenarios reviewed with PO  Sonar quality metrics met  Peer code review completed and code review comments incorporated  Static checks and gated check-in passed  Unit testing completed  Switch / dormant configuration document updated  Any new stories added back to the backlog  Test automation suite extended for new functionality  Integration testing completed via stubs / virtualization  Any alerting or monitoring implemented and verified  Performance baslining completed  Any knowledge transfer document / page / LLD updated  UX regression completed  Regression Automation Suit passed  DB Backward Compatibilit y testing in NFT  App roll forward in NFT  Functional Sanity in NFT with Automation  NFT Base line Test for NFRs  Measure Site confidence journey timings  Operational Acceptance test (optional)  Prod Package Build and RFC creation  Execute Pre- Deploymen t Steps  UXP repoint to live copy  Execute Post UXP Steps (publishing changes_)  DB Roll forward in Prod  App roll forward in Prod  Post App roll forward steps  Hyper Care Testing by POs  Cutovers Steps
  29. 29. End to End visualization on Scrum Board
  30. 30. Delivering early and often – Environment Usage Development Environment Functional Test Environment Non- Functional Test Environment Production Development Environment Non- Functional Test Environment Production Systems Integrated Testing (SIT) Environment before Scaling Functional Test Environment Systems Integrated Testing (SIT) Environment After Scaling
  31. 31. Continuous Integration, Deploy, Delivery & Support Done in Dev Local box Check-in in central source control repository ( with Gated Checking), Static Code analysis done post check-in (PMD , Check Styles, Sonar) Deployed in on a production like environment Check if packages installed correctly? Automated Regression suit pass? Done using automation when we release once or twice in a month Supports all above and post production activities
  32. 32. CHARACTERISTIC OUTCOME(S) Scrum Team Performance Generally good to excellent –  60 % fewer bugs  Throughput of the team increased substantially  Collaboration within Team greatly increased; teams functioning as teams more engaged and empowered Executive Team Activities  Adopted mindset of Minimum Marketable Features (MMF) for customers  Excellent engagement with their Customers Customer Satisfaction  Generally quite higher at the Scrum team level via continuous delivery of working software and making adjustments due to feedback  Moderate improvement at the Customer’s Executive levels? Portfolio level Did Scaling happen?  Yes – at least for the Domain and Team targeted, with more planned upon leaving Delivery Cycle Time  Average Delivery Cycle time is down from 3+ months to 1 month resulted from 4 released to 10 in a year  More than 96% project delivered on Time and in Budget  30% cost to Deliver Reduction Product Management  Significant improvement in Product Management and Development Team work. Outcomes
  33. 33. What factors enabled greater success?  Tremendous work ethic  Belief in product  Demonstrating Agile Principles at 3 levels  Dedicated, Continuous Teams  Sprint Review Participation  Execs/Mgmt. Curiosity Work through pivots  Set foundation to scale  Actions
  34. 34.  Teams ready to work towards the same goal, in a rhythm and keep them in sync?  Coordination exists between the teams (resolving dependencies between the smaller teams)?  Do you have a decision making framework in place?  Do you have plot to integrate teams’ work products (working software)?  Have platform to Involving all major stakeholders during planning, discussion and demonstration  Do you practice Program, Portfolio management and Market releases?  How Immature is your Agile teams? Can they be Trained on priority (consistent Agile Practices)?  Is your Organizational structure Simple or overtly complex?  Do you have Infrastructure for Scaling and following process supporting Agile and continuous delivery? Challenges when SCALING
  35. 35.  Do your Executives:  Believe there is a problem with the status quo of the organization?  Agree there is need to alter their behavior in order for the organization to change?  Understand they need to reestablish relationships with their top customers, help their customers come along with the transformation journey as well?  Have the fortitude to prioritize on a limited set of key strategic initiatives and let others go?  When it comes to the act of releasing product incrementally:  Is your organization ready to go for incremental releases?  Are your customers willing to accept incremental releases?  Ready roll out a set of Standard practices incrementally across organization? Challenges when SCALING? Continued…
  36. 36. QUESTIONS? https://in.linkedin.com/in/saikatdas16 @dsaikats
  37. 37. REFERENCES Books:  A Tale of Two Transformations: Bringing Lean and Agile Software Development ... By Michael K. Levine Books:  Agile estimation and planning – Mike Cohn  Software Estimation : Demystifying the black art – Steve McConnell Organizations: • Scrum Alliance (www.scrumalliance.com) • Mountain Goat Software (www.mountaingoatsoftware.com/) • Scaled Agile Framework (www.scaledagileframework.com) • Discipline Agile Development (www.disciplinedagileconsortium.org) Online Resources: • www.slideshare.net

×