Successfully reported this slideshow.
Your SlideShare is downloading. ×

James Hannon: A case study of an Agile Transformation - in a FINTECH firm

Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad

Check these out next

1 of 16 Ad

More Related Content

Slideshows for you (20)

Similar to James Hannon: A case study of an Agile Transformation - in a FINTECH firm (20)

Advertisement

More from Edunomica (20)

Recently uploaded (20)

Advertisement

James Hannon: A case study of an Agile Transformation - in a FINTECH firm

  1. 1. An Agile Transformation Journey- A case study of a FinTech company Agile transformations look different across organizations but they share a common goal : a desire to deliver more value Presentation for . Global One PM Day By Jim Hannon July 2021 jhreds@gmail. com 1
  2. 2. My Agile/PMP History • MBA/EdD candidate 2022/Masters in IT Ops • CSP/CSM/PMP, PMI-ACP, PM-RMP,AHF, PaRP Trainer , eduScrum -Teacher, Scrum@Scale practitioner, SA, ICC-ACC, ATP Instructor, ICC- ATF • Enterprise Coach –over 15 years of practical on ground team and C-Level experience • Managing director/founder-BU Agile Innovation Labwww.buagileinnovationlab.com • Adjunct faculty numerous school and Lasell • Jim H | LinkedIn
  3. 3. Agenda 3 • Adoptionvs.Transformation • WhatDoes it Mean to be “Agile”? • ExpectationVs. Reality • SuccessPractices • Elementsof Development“Ecosystem” • Whatwe change and what we don’t • Keybarriers to agiletransformation • Case- we experienced and we suggested • AdoptionPhases and BaselineStory
  4. 4. Adoption vs. Transformation 4 AgileAdoption is about, what wedo… practices, tools, ceremonies etc. AgileTransformation is about, who weare… it reflects in the organization structure and culture, and impacts the people. For long term success, BothTransformationand Adoption are essential.
  5. 5. What Doesit Mean to be “Agile”? Being Agile means taking a disciplined approach to decision making in order to make the best possible decisions with the information known at the time. 5 Being “Agile” simply means Reacting quickly to every little issue that arises, right?
  6. 6. Expectation vs Reality 6
  7. 7. Success Practices Leaders/ Scrum Masters 7 Business / Product Management Team Practices Technical Practices ProjectVision Customer Representativein theTeam Standup meetings Pair Programming Stakeholder Roles AgileRequirement Analysis Iteration /Sprint Planning Collectivecode Ownership Project &Release Management Requirement Definition Cross functional Team Test Driven Development Information Radiator Requirement Prioritization Collaborative workshops AutomatedTesting Minimumsub-set of Requirements Team Deliveries Continuous Integrationand Build Team Retrospective SimpleArchitecture and Design Team Rewards Refactoring
  8. 8. Elements of Development “Ecosystem” 8
  9. 9. Whatwe change? 9 What we don’t change? Organization Structure Roles and Responsibilities Tools Process Values Belief Mindset Customs Traditions Behavior
  10. 10. Keybarriers to agile transformation • Requires role changes • Requires structural changes • Requires cultural shift • Requires governance changes • Human resource policies • Complex product organizations • Uneven portfolio investment • Project based organizations • Local optimization • Practices over principles • Need for certainty • Value vs. Valuable • Neglecting distributed teams • Forgetting to celebrate successes A0n 9 July e 20x 16perienced Agile Practitioner can help an organization avoid missteps9
  11. 11. Our case 11 • Horizontal and Vertical reporting structure. • Frequent change • Priority • Scope • Resource • Allocating Sprint and non sprint work leading to delay in delivery • No communication on Plans (Release, major milestones, etc) • Different practices within project • Release time = Hardening timeline • No Ownership of responsibilities • Not Reviewing the learning. • No Grooming • Overall No Transparency • Half Yearly Release • Progress Tracking on AC’s not on Stories • My work and Your work
  12. 12. 12 Solutions • Try to work with Co- located team • Avoid movement of • Resources • Bring Transparency in planes • Trust team about work • Communicate all stuff • Mindset shift • Reporting structure shift • From Component level estimation to velocity • All document first to • evolving requirement • No Ac tracking, story tracking • Size Stories Properly • Remove some fields from JIRA(Todo-progress- done) • Estimate the work
  13. 13. We Suggested Scrum Master role introduced, defined Release scope and iteration plan for one team and Leaders HAVE to trained Introduced Scrum events (daily standups), and artifacts (Jira for sprint planning and Burndown metrics) Provided walkthrough to stakeholders for Agile concepts and Jira Started using Jira for Product backlog, sprint backlog, grooming. Introduced Acceptance Criteria 13 Challenges: 1. Team structure – multiple applications, smaller teams, no L3, Config managers. Cross-functionality is not achieved. 2. UX and SIT are separate teams, so Pipeline Iteration structure suggested. ((BA  Dev+CIT  SIT)
  14. 14. ParadigmShift Tries to be predictable FixesTime,Price andScope Measures Project Success by conformance to the plan Values methodology and processes more than people Resists requirements and development process changes Considers systemspecification as the generated documentation Accepts that complete predictability is impossible to achieve FixesTime, Price but notScope Success is measured by theValue tocustomer Values people morethan process, hence accepts process rather than imposing one Adapts to requirements and development process changes Considers system specification as the developedcode The ‘Waterfall Mindset’ The ‘Ágile Mindset’ Agile Transformation 14
  15. 15. AdoptionPhases Start Small And / Or Simple Agile Enterprise over Time Non-Agile Enterprise 15 Exploration Process Definition Strategic Alignment Transformation Baseline story is
  16. 16. What have you taken away? 16

×