Agile business analysis the changing role of business analysts in agile software development

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

• nari@appsparq.com

• 502.749.3049 10

/26

/20

11

32