The Lessons Learned of a BA on an Agile Project Presented by - PowerPoint PPT Presentation

F O C U S Q U A L I T Y E X P E R I E N C E The Lessons Learned of a BA on an Agile Project Presented by Jacqueline Sanders, PMP, CBAP

Outline  What Agile is NOT  Key Components of Agile  The Conversion to Agile  The New Development Project using Agile  The Maintenance Releases using Agile  The Future of BA’s on Agile Projects

What Agile is NOT  Big “A”: Formal Agile – a disciplined methodology (i.e. stand up meetings, co-located, iterations)  Little “a”: Informal agile – teams just trying to do things quickly, haphazard and chaotic

Agile Manifesto Agile Values: Over Individuals and interactions Process and tools Over Working Software Comprehensive documentation Over Customer Collaboration Contract negotiation Responding to change Over Following a plan

Key Components of Agile  Short Iterations  Design/Build/Test as you go  Small Dedicated Project Teams  Highly Functioning and Self-managed Team  Co-located Teams  Task Board and Burn  Pairings down Chart  Assigned SME  Retrospectives  Weekly Sprints  Daily Standup Meetings

Converting to Agile  Brought in Agile Coaches  Gave Exit Packages to Non-Agile Resources  Brought in New Agile-minded Resources  Sent the Team to Agile Boot Camp  Co-Located the Team  Conducted Team Building Exercises  Created a Fun Environment  Made “Most” Resources 100% Dedicated

New Development Project using Agile Semi- Weekly Iteration 0 Deploy Scoping of & The Project Retrospectives Initial Weekly Backlog Stakeholder Decomposition Demos Sprint Daily Scrum Semi Weekly Team Sprint Planning Meetings Meetings

The Project Parameters  Government Regulation  Hard Deadline  Existing Application  New Data Fields  Significant Changes to Business Rules & Process  Impact to 12 Different Departments  Impact to Entire Customer Base  Coincided with Media & Marketing Campaigns  Two Executive Sponsors  The #1 Priority for the 4th Quarter

The BA’s Project Initiation Tasks  Iteration (0) Zero  Sponsor Consensus on Approach  Assist with High Level Technical Design  Interviews and Facilitated Sessions  1 or more Iterations Ahead of Development  Wiki Set Up  Artifacts: • User List • User Stories

The User Story List

User Stories

The BA’s On-going Activities  Daily Stand Up & Follow Up  Spontaneous and As Needed • Meetings with Stakeholders • Monitor Development Work • Respond to QA  Multi-Tasking • Working The Open Issues • UAT Preparation • Weekly Demo Prep • Research User Stories for Next Iterations • Maintain Project Wiki

The Backlog Story/Task Board

User Story Cards

Behind The Scenes Activities  Manage Multiple Viewpoints  Modeling and Diagrams during Design Discussions  SME Intimidated by Developers  Backend Process Requirements  Rework was Necessary  Document Needed During Implementation  Compensated for Lack of BA Skills  Focus on Exceptions and Alternatives  Issue Log (In Scope and Out of Scope Negotiation)

New Development – Retrospect What Worked Well  Access to Software Designers/Architect  Iteration Zero  Having Agile Coaches  Incorporating Lessons Learned Quickly  Sponsor Accepted Risk

New Development – Retrospect What We Could Do Differently  Underestimating the Rework  Underestimating Backend Processes  Managing Unrealistic, Hard Deadlines  Addressing People not embracing Agile  Handling Process Development Differently  Upfront Database schema changes

Maintenance Projects using Agile Semi- Weekly Iteration 0 Deploy Not & Applicable Retrospectives Initial Weekly Backlog Stakeholder Sprint Demos Not Applicable Daily Scrum Semi Weekly Team Sprint Planning Meetings Meetings

The Maintenance Project Parameters  Developer Initiative  2 Week Iterations  As Needed Requirements or Just In Time  Not Co-located  Semi-Weekly Demos  Semi-Weekly Planning Sessions  Business was not Agile  PM tolerated Agile but was not Agile  No executive sponsor for Agile

The BA’s Activities  2 Week Iterations  As-Needed / Just-In-Time Requirements  Semi-Weekly Demos  Semi-Weekly Planning Sessions  Provided Documentation to the Business  Facilitated Demos  Unofficially attended stand ups  Unofficially attended sprints

Maintenance Project - Retrospect What Worked Well:  Developers Fully Engaged  User Involvement Early and Often  Cohesive Team

Maintenance Project - Retrospect What Could Have Been Done Different:  Executive Sponsor Buy In  Realistic Dates  Appreciations of Burn down and Velocity  Dysfunctional Organization  Developers Input Respected

Conclusion