1. Agile Business Analysis – The
10/26/2011
Changing Role of Business
Analysts in Agile Software
Development
Nari Kannan
Chief Executive Officer
appsparq, Inc.
www.appsparq.com
1

2. 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

3. 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

4. Software Development –
Theory and Practice
10/26/2011
4

5. 10/26/2011
5

6. Software Development –
Theory and Practice
10/26/2011
• Software Development is Hard
• Getting it Wrong Happens more often than
Getting It Right!
• Methodologies have been constantly
Evolving! 6

7. Evolution of Software
Development Methodologies
• Programming the Machine Physically
10/26/2011
• Punch Cards
• Structured Programming – Fortran2, COBOL
• Software Development Life Cycle (SDLC)
• Waterfall Model
• Agile Methodologies – Scrum, Extreme Programming, Hybrid Models
7
• ???

8. Evolution of Software
Development Methodologies
10/26/2011
The problem is that we don’t
know where we are currently!
8

9. The What
10/26/2011
9

10. 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

11. The Why
10/26/2011
11

12. The Why
• The Problem with Requirements!
10/26/2011
12

13. 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”

14. The Why
10/26/2011
14
Courtesy: Russell Miles - Blog

15. 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

16. 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!

17. 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!

18. 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

19. 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

20. The How - Mechanics of Agile
Methods
• 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 that's the best way to achieve
the relevant goals. 20

21. The How - Mechanics of Agile
Methods
• 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

22. Problems With Traditional
Business Analysis
10/26/2011
22

23. Potential Problems with
Traditional 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

24. 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

25. 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

26. Our Development Process - Hybrid Waterfall-Agile Methodology
Start
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

27. Our Process For Repairing Off-Track Software Projects
Start
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

28. 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.

29. My Own Experiences So Far
With 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!

30. 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

31. Conclusions
• Agile Business Analysis Needs Commitment from all
Stakeholders including BAs
10/26/2011
• Agile for Agile’ s sake not very successful!
31

32. Q&A
• Contact Information
• Nari Kannan
10/26/2011
• nari@appsparq.com
• 502.749.3049
32