Agile business analysis the changing role of business analysts in agile software development
Agile Business Analysis – The 10/26/2011Changing Role of BusinessAnalysts in Agile SoftwareDevelopmentNari KannanChief Executive Officerappsparq, Inc.www.appsparq.com 1
Agenda• Software Development – Theory and Practice• Evolution of Software Development Methodologies 10/26/2011• The What, Why, Who, When, How of Agile Development• Problems with Traditional Business Analysis• Hybrid Waterfall/Agile Models – Having the Cake and Eating it Too• Business Analysis – Oil and Water or Recipe for Success?• Agile Business Analysis – Challenges and Opportunities• My Own Experiences So Far With Agile• Conclusion• Q&A 2
Some Caveats• Business Analysis Can Span many disciplines: • Process Analysis and Improvement 10/26/2011 • Strategic Planning • Organizational Change • Policy Development and Implementation • Business Systems Analysis (BSA)• Scope of this talk is only with BSAs • Enterprise Analysis • Requirements Planning and Management • Requirements Elicitation. • Requirements Analysis 3 • Requirements Communication • Solution Assessment and Validation
Software Development –Theory and Practice 10/26/2011 4
The What• What is Agile Software Development? • Iteration! 10/26/2011• The Agile Manifesto states: • We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: • Individuals and interactions over processes and tools • Working software over comprehensive documentation • Customer collaboration over contract negotiation • Responding to change over following a plan • That is, while there is value in the items on the right, we value the items on the left more. 10
The Why• The Problem with Requirements! 10/26/2011 12
The Why• Users think they are Communicating Perfectly! 10/26/2011• Developers think they have understood Perfectly!• Huge Communication Gaps!• The World Changes, The Business and Requirements Change!• “Adaptive Methods” nimbler than 13 “Predictive Methods”
The Why 10/26/2011 14Courtesy: Russell Miles - Blog
The Why• Value of Iteration • Assumes that there is a Gap between Users’ Needs and Their 10/26/2011 expressed “Wants” – Requirements Gap! • Gap is narrowed by iterating – Get the user a version and asking the question – Is this what you meant? Methodology 3 • Constant Course-Corrections! Finish Agile Methodology 1 Cancelled! Start Methodology 2 15
The Who• What Software Development Efforts are suitable for Agile Methodologies? 10/26/2011 • Almost All! • Well Understood Domains, Applications, Ports from Existing Applications To Other Platforms • Fast Changing Businesses, Unclear Requirements – Better Candidates! • Short Development Cycle, Long Development Cycle – all Good 16 Candidates!
The Who• Organizations that are not well organized with “Good Conduct of Other Methodologies” 10/26/2011 • Waterfall Model • Theory – Comprehensive and Clear Requirements • Reality – Some Requirements Well Thought-Out, Some-Last Minute “Scribbles” • Agile Fix – Iteration Fine Tunes Requirements by seeing Deliverables • Theory – Thorough Review of Design • Reality – “What the heck is a Three Tier Architecture!?” • Agile Fix – Software Code is something I understand as a User • Theory – Thorough Review of Quality in One Shot • Reality – Coding Overran by Two Months – You have One week to test instead of three months like we planned!” 17 • Agile Fix – Software Gets Tested Six Times Over the course of the Project!
The When• Users, Development Teams all need to • Understand WHY Agile works! 10/26/2011 • Buy into it completely! • Be Comfortable with Software that is Work In Progress and understand that they have a say in where it is going!• New Projects• Projects that are Off The Rails • First Validate Communication of Overall Goals, Domain Information between all • Re-plan Milestones and Deliverables with Frequent Releases 18
The How• Agile Methods • Agile Modeling 10/26/2011 • Agile Unified Process (AUP) – Agile Version of Rational Unified Process • Dynamic Systems Development Method (DSDM) – Agile RAD • Essential Unified Process (EssUP) – Another Agile Version of RUP • Extreme Programming (XP) – Traditional Models taken to “Extreme” • Feature Driven Development (FDD) – Plan and Build by Feature • Open Unified Process (OpenUP) - Another Agile Version of RUP • Scrum – Comes from Product Development World• Agile Practices • Test Driven Development (TDD) – Automated Tests and Development Interleaved • Behavior Driven Development (BDD) – Emphasizes all Stakeholders, not just Testing • Code Refactoring – Improving Code within without changing Behavior of Code • Continuous Integration – Testing and Bug Fixing don’t wait till all of Development • Pair Programming – Two Programmers alternating as Coder and Reviewer 19 • Planning poker – Estimation Technique with Developers Playing Estimation Poker • RITE Method – Rapid Iterative Testing and Evaluation
The How - Mechanics of AgileMethods• Daily Stand Up Meeting • 15 Minute Meeting in which everyone Stands 10/26/2011 • Goals are: • Share Commitment • Communicate daily status, progress, and plans to the team and any observers • Identify obstacles so that the team can take steps to remove them • Set direction and focus • Build a team • Documentation Principles • The fundamental issue is communication, not documentation. • Agilists write documentation only if thats the best way to achieve the relevant goals. 20
The How - Mechanics of AgileMethods• Documentation Principles • Document stable things, not speculative things. 10/26/2011 • Evolutionary approach to documentation development • Prefer executable work products such as customer tests and developer tests over static work products such as plain old documentation (POD). • Documentation should be concise: overviews/roadmaps are generally preferred over detailed documentation. • Documentation should be just barely good enough. • Your team’s primary goal is to develop software, its secondary goal is to enable your next effort. • Update documentation only when it hurts. 21
Problems With TraditionalBusiness Analysis 10/26/2011 22
Potential Problems withTraditional Business Analysis• Not Having the Right Skills. 10/26/2011• Undue Project Influence.• Can be out of date.• Can act as a Communication Barrier.• Can reduce Direct Stakeholder Influence.• Over Analysis• Can reduce Opportunities for Developers to Gain Communication Skills. 23
Problems with Agile• In Practice No One Agile Software Development Methodology Works in All Cases 10/26/2011• Build a Hybrid Agile Methodology Based on: • How Formal is Your Organization Currently? • Many Business Analysts? • Rigorous Vs. Shoot From The Hip? • What is the Path of Least Resistance? 24
Agile Business Analysis – Oil and Water?or Recipe for Success?• Why Hybrid Models? • Pure Agile Methods as ineffective as Pure Waterfall Methods in many 10/26/2011 cases • Sometimes “Agile Rituals” become Rituals for Rituals Sake – People get hung up on the mechanics and forget the spirit! • Bridging the Communication Gap is the whole Idea behind Agile! • Pure Agile does not work well for Distributed Software Development • Time Zone Differences amplify difficulty in having daily Stand Up Meetings • Organizations fall back on Weekly Releases and Meetings • Pure Agile does not work well in Outsourcing Situations • Clients complain about Teams on Endless Time & Materials Basis • Service Providers complain about Scope Creep if it is a Fixed Price Project • Theory of Agile works well in Outsourcing but not Practice! 25
Our Development Process - Hybrid Waterfall-Agile MethodologyStart Requirements Gathering Client Questions/Clarifications 10/26/2011 Functional Specification Technical Specification Technical Architecture Questions/Clarifications Client High Level Design Document Periodic Builds (Weekly, Every 10 Periodic Builds (Weekly, Every 10 ………. Days, or Frequent Planned Releases) Days, or Frequent Planned Releases) Client Feedback/Defects/Tickets Client Feedback/Defects/Tickets Client Testing Out of Scope? – Change Order Out of Scope? – Change Order and Acceptance 26 Finish
Our Process For Repairing Off-Track Software ProjectsStart Communication Completeness Check Client Requirements Document (If Any) Functional Specifications (If Any) Questions/Clarifications 10/26/2011 Technical Specifications (If Any) Technical Architecture (If Any) Existing Project Plan (If Any) Review of Personnel, Technology Needs - Re-planned Project Plan with New Milestones and Deliverables Periodic Builds (Weekly, Every 10 Periodic Builds (Weekly, Every 10 ………. Days, or Frequent Planned Releases) Days, or Frequent Planned Releases) Client Feedback/Defects/Tickets Client Feedback/Defects/Tickets Client Testing Out of Scope? – Change Order Out of Scope? – Change Order and Acceptance 27 Finish
Agile Business Analysis –Challenges and Opportunities• Challenges • Increasing Adoption of Agile Methodologies 10/26/2011 • Rapid Technology and Business Change • Disillusionment with Traditional Systems Analysis and Software Development• Opportunities • Hybrid Models are proving that Business Analysis is needed upfront • Increasing Software Development Outsourcing and Distributed Teams need Formal Approaches to Systems Development • BAs have the opportunity to understand, embrace, adopt and 28 adapt Agile Methodologies into their function.
My Own Experiences So FarWith Agile• Previous Company – Ajira Technologies, Inc. • 4 Software Products, 4 Versions Each, Average of 30 Builds Each 10/26/2011 Version, 6 Years • Small Engineering Team in India, the same team working on all products, a Build every 10 days or so • Stand Up Meeting after each Build but all Communications Mechanisms Used – Skype Daily, Team Webex/Conference Call every 10 days, Personal Visit Every 3 months or so.• Our Processes • Using Agile in Every Project – Old or New • Significant changes in Delivery Predictability and Results 29 • Communication Problems Fixed First – Results Followed!
Conclusions 10/26/2011• Business Analysis is Changing and BAs Worried about the effect of Agile Development Methodologies.• Pure Agile does not work with Distributed Teams! • Golden opportunity for BAs to understand, adopt and adapt Agile Software Development and redefine a new discipline – Agile Business Analysis 30
Conclusions• Agile Business Analysis Needs Commitment from all Stakeholders including BAs 10/26/2011• Agile for Agile’ s sake not very successful! 31