Upload
nari-kannan
View
729
Download
2
Tags:
Embed Size (px)
DESCRIPTION
Citation preview
Agile Business Analysis – The Changing Role of Business Analysts in Agile Software Development Nari Kannan Chief Executive Officer appsparq, Inc. www.appsparq.com
10
/26
/20
11
1
Agenda
• Software Development – Theory and Practice
• Evolution of Software Development Methodologies
• 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
10
/26
/20
11
2
Some Caveats
• Business Analysis Can Span many disciplines:
• Process Analysis and Improvement
• 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
• Requirements Communication
• Solution Assessment and Validation
10
/26
/20
11
3
Software Development – Theory and Practice
10
/26
/20
11
4
10
/26
/20
11
5
Software Development – Theory and Practice
• Software Development is Hard
• Getting it Wrong Happens more often than Getting It Right!
• Methodologies have been constantly Evolving!
10
/26
/20
11
6
Evolution of Software Development Methodologies
• Programming the Machine Physically
• Punch Cards
• Structured Programming – Fortran2, COBOL
• Software Development Life Cycle (SDLC)
• Waterfall Model
• Agile Methodologies – Scrum, Extreme Programming, Hybrid Models
• ???
10
/26
/20
11
7
Evolution of Software Development Methodologies
The problem is that we don’t know where we are currently!
10
/26
/20
11
8
The What
10
/26
/20
11
9
The What
• What is Agile Software Development? • Iteration!
• 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
/26
/20
11
10
The Why
10
/26
/20
11
11
The Why
• The Problem with Requirements!
10
/26
/20
11
12
The Why
• Users think they are Communicating Perfectly!
• Developers think they have understood Perfectly!
• Huge Communication Gaps!
• The World Changes, The Business and Requirements Change!
• “Adaptive Methods” nimbler than “Predictive Methods”
10
/26
/20
11
13
The Why
Courtesy: Russell Miles - Blog
10
/26
/20
11
14
The Why
• Value of Iteration
• Assumes that there is a Gap between Users’ Needs and Their expressed “Wants” – Requirements Gap!
• Gap is narrowed by iterating – Get the user a version and asking the question – Is this what you meant?
• Constant Course-Corrections!
Start
Finish
Cancelled!
Methodology 1
Methodology 2
Methodology 3
Agile
10
/26
/20
11
15
The Who
• What Software Development Efforts are suitable for Agile Methodologies?
• 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 Candidates!
10
/26
/20
11
16
The Who
• Organizations that are not well organized with “Good Conduct of Other Methodologies” • 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!”
• Agile Fix – Software Gets Tested Six Times Over the course of the Project!
10
/26
/20
11
17
The When
• Users, Development Teams all need to
• Understand WHY Agile works!
• 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
10
/26
/20
11
18
The How
• Agile Methods
• Agile Modeling • 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 • Planning poker – Estimation Technique with Developers Playing Estimation Poker • RITE Method – Rapid Iterative Testing and Evaluation
10
/26
/20
11
19
The How - Mechanics of Agile Methods • Daily Stand Up Meeting
• 15 Minute Meeting in which everyone Stands
• 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 that's the best way to achieve the relevant goals.
10
/26
/20
11
20
The How - Mechanics of Agile Methods • Documentation Principles
• Document stable things, not speculative things.
• 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.
10
/26
/20
11
21
Problems With Traditional Business Analysis
10
/26
/20
11
22
Potential Problems with Traditional Business Analysis
• Not Having the Right Skills.
• 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.
10
/26
/20
11
23
Problems with Agile
• In Practice No One Agile Software Development Methodology Works in All Cases
• 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?
10
/26
/20
11
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
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!
10
/26
/20
11
25
Our Development Process - Hybrid Waterfall-Agile Methodology
Requirements Gathering
Functional Specification Technical Specification Technical Architecture
Questions/Clarifications
Client
Questions/Clarifications Client
High Level Design Document
Periodic Builds (Weekly, Every 10 Days, or Frequent Planned Releases)
Periodic Builds (Weekly, Every 10 Days, or Frequent Planned Releases)
Client Feedback/Defects/Tickets Client Feedback/Defects/Tickets
……….
Client Testing and Acceptance Out of Scope? – Change Order Out of Scope? – Change Order
Start
Finish
10
/26
/20
11
26
Our Process For Repairing Off-Track Software Projects
Communication Completeness Check
Technical Specifications (If Any)
Technical Architecture (If Any)
Questions/Clarifications
Client
Review of Personnel, Technology Needs - Re-planned Project Plan with New Milestones and Deliverables
Periodic Builds (Weekly, Every 10 Days, or Frequent Planned Releases)
Periodic Builds (Weekly, Every 10 Days, or Frequent Planned Releases)
Client Feedback/Defects/Tickets Client Feedback/Defects/Tickets
……….
Client Testing and Acceptance Out of Scope? – Change Order Out of Scope? – Change Order
Start
Finish
Functional Specifications (If Any)
Requirements Document (If Any)
Existing Project Plan (If Any)
10
/26
/20
11
27
Agile Business Analysis – Challenges and Opportunities • Challenges
• Increasing Adoption of Agile Methodologies
• 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 adapt Agile Methodologies into their function.
10
/26
/20
11
28
My Own Experiences So Far With Agile • Previous Company – Ajira Technologies, Inc.
• 4 Software Products, 4 Versions Each, Average of 30 Builds Each 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
• Communication Problems Fixed First – Results Followed!
10
/26
/20
11
29
Conclusions
• 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
10
/26
/20
11
30
Conclusions
• Agile Business Analysis Needs Commitment from all Stakeholders including BAs
• Agile for Agile’ s sake not very successful!
10
/26
/20
11
31
Q & A
• Contact Information
• Nari Kannan
• 502.749.3049 10
/26
/20
11
32