5/23/2011

Agile Adoption: Success or Failure

Agile Adoption: Success or Failure

Julen C Mohanty
Citicorp Services India Ltd

5/23/2011

DISCLAIMERS

Any views or opinions showcased in this presentation are solely those of the author and may not necessarily represent those of the Citigroup. This document is meant for use of Business Analyst World or its members. Has to be used within Business Analyst World or its members and not to be forwarded to anyone outside Business Analyst World or its members.

INDEX
What is Agile Why to go for agile (problem with water fall model) Difference between Agile & Iterative INVEST model for requirements Why Agile Projects Fail? CASE STUDY - Approach for Agile The agile Business Analyst A day with Agile BA

5/23/2011

What is Agile

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, Agile value the items on the left more.

Source: http://agilemanifesto.org/

Problems with Waterfall Development

Value to Customer isnt realized until the end of a project All requirements are delivered at once, instead of phasing by priority Defects and integration issues are found very late in the project Major risks arent identified and mitigated early Change isnt easily accommodated Quality is often compromised to meet deadlines

5/23/2011

Effect of Delays
Typical Project Plan:
Start- Initiup ation
Concept Design

Func Tech Design Design

Build / Test

Deploy

Typical Project Execution:

Option A: Reduce Build / Test / Deploy Time. This will compromise the Quality

Startup

Initiation

Concept Design

Func Design

Tech Design

Build / Test

Deploy

OR
Option B: Extend Project End Date and Increase Cost

StartInitiation up

Concept Design

Func Design

Tech Design

Build / Test

Deploy

Clients Perception
12 Month Project (originally a 9 month project) StartInitiation up Concept Design Func Tech Design Design

Build / Test

Deploy

Months 1-9: No Visible Value

Month 10: Value Is Visible (Client begins testing) Month 12: Value Is Achieved

5/23/2011

Lack flexibility to change

12 Month Project (originally a 9 month project)
Startup Concept Design Functional Tech Design Design

Initiation

Build / Test

Deploy

Theory: All requirements should be defined

More requirements / problems discovered More during build. Functional requirements Design / Technical Design discovered. changes Conceptual Design changes More requirements discovered. Functional Design changes

Testing at the End (Fail Late)

12 Month Project (originally a 9 month project)
Startup Concept Design Functional Tech Design Design

Initiation

Build / Test

Deploy

Bugs and critical Integration issues arent driven out until here resulting in delays

5/23/2011

Agile : Iterations
Agile Development is focused on an iterative (addressing all aspects of the lifecycle in each iteration) and flexible approach to software development

Deliver Value to Customer

Agile allows for recurring releases that can be either internal or external Prioritization of requirements means the highest value is delivered first Customer sees growing value at the end of each iteration If at any point project is halted, most critical value has already been delivered
Customer may choose to halt project once key requirements delivered, saving money

5/23/2011

Attack Critical Risks Early

9 month project

Iter 1

Iter 2

Iter 3

Iter 4

Iter 5

Problem: Assumptions were made in Conceptual that werent proven until Functional and Technical Design. These assumptions ended up being incorrect resulting in serious delays Solution: Identify and attack those risks early on

Test Early and Test Often

Perform testing with each iteration Most critical bugs are driven out early & resolved Reducing overall cost and time of project Each iteration is well tested, allowing for faster delivery of functionality If at any point a project is halted, functionality to-date can be delivered and has been tested Removes complexity of deferred testing

5/23/2011

Difference between Agile & Iterative

PLAN BUILD TEST REVIEW PLAN
BUILD

Waterfall

TEST

REVIEW

DEPLOY

DEPLOY

Iterative

PLAN

BUILD

TEST

REVIEW

DEPLOY

Difference between Agile & Iterative

PLAN PLAN PLAN PLAN

BUILD

BUILD

BUILD

BUILD

REVIEW

DEPLOY

TEST
REVIEW

TEST
REVIEW

TEST
REVIEW

TEST
REVIEW

Agile

PLAN

PLAN

PLAN

PLAN

Agile = Iterative + Incremental

IT1 IT2 IT3

BUILD

BUILD

BUILD

BUILD

REVIEW
Delivery

DEPLOY

C A B A
Time

D C B A B

TEST
REVIEW

TEST
REVIEW

TEST
REVIEW

TEST
REVIEW

5/23/2011

Agile Requirements Characteristics

Independent
Avoid dependencies with other stories Write stories to establish foundation Combine stories to deliver in a single iteration

INVEST

Negotiable
Stories are not a contract Not every story must be negotiable,

Testable
Acceptance criteria should be stated in customer terms Tests should be automated whenever possible Team members should demand clear acceptance criteria

Valuable

Each story should show value to the Users, Customers and Stakeholders

Estimable
Enough detail should be listed to allow team to estimate The team will encounter problems estimating if the story is too big, if insufficient information is provided / if there is a lack of domain knowledge

Sized Appropriately
Each story should be small enough to be completed in a single iteration Stories that may be worked on in the near future should be smaller Larger stories are acceptable if planned further out
Courtesy : Bill Wake

Not Looking at the bigger Picture Not having proper tools No feedback system Not coming out from rigid plans No Response to change Agile is not a silver bullet. Dont expect Charismatic Results Agile process fixation Lack of Powerful Communication Not Measuring Value delivered Team keeps on missing iteration deliverables Team priorities change rapidly leading to productivity undermine

No Agile Mindset No Collaboration with Customer Absence of Team Work OR collaboration among team members Sticking to contract and not the need of the situation

WHY AGILE FAILS

Agile without explanation Agile as an excuse for having no discipline Time Value of Money Not Having Test Driven Development People in fear to lose title Bugs found by QA after the iteration completes The design & architecture is a mess!

5/23/2011

Failure Category

Technology
CULTURE

Organization Structure

Leadership

People

CASE STUDY 1
Global regulatory project to be rolled out to 70 countrys business users. Involves consolidation of 15-20 stock exchanges of the world Involves integration of 45 feeds from different countries Have 15 languages to be incorporated to roll out 95% of the application in No UI but in Mainframe
Some of the issues: 1. Interacting with business users with different regions for same parameters of data 2. Non availability of requirements on time from scattered business users 3. Most users werent 100% sure about the aggregation logic 4. Regulatory reporting requirement for countries were different

10

5/23/2011

CASE STUDY 1
Global regulatory project to be rolled out to 70 countrys business users. Involves consolidation of 15-20 stock exchanges of the world Involves integration of 45 feeds from different countries Have 15 languages to be incorporated to roll out 95% of the application in No UI but in Mainframe
group into 4 major regions Taking care of regional specific requirements One large exchange from each region 4 different tracks of development with agile

Integrating to global

Incrementing to region

How to Measure Agility

Thinking:
Are all team members aware of their progress toward meeting team goals? Does the team improve their process in some way at least once per month?

YES
4 5

NO
0 0

Collaborating:
Do team members generally communicate without confusion? Do nearly all team members trust each other? 4 5 0 0

Releasing:
Can any programmer on the team currently build a tested, deployable release with a single command? Do all programmers integrate their work with the main body of code at least once per day? 5 4 0 0

11

5/23/2011

How to Measure Agility

Planning:
Does the team have a plan for achieving success? Does the team regularly seek out new information and use it to improve their plan for success?

YES
4 2

NO
0 0

Developing:
Are all programmers comfortable making changes to the code? Do unexpected design changes require difficult or costly changes to existing code? 3 0 0 3

How to Measure Agility

Planning

Thinking

Collaborating

Developing

Releasing

12

5/23/2011

How to Measure Agility

7.5 points or less 7.5 9.5 Points 9.5 10 Points 10 Points : immediate improvement required (red) : improvement necessary (yellow) : improvement possible (green) : no further improvement needed

Suggested way to approach Agile

Project
undertakes

Team

applies

shapes & follows the

Agile is all about people, its people who build software not processes

Process

Developer

Business Analyst

Developer Tester

Business Analyst/ SME Agile

Tester

13

5/23/2011

The Agile Business Analyst

In agile the analysis phase is not just set of analysis documents and artifacts In Agile the Analysis Document is not a deliverable, unlike in Waterfall model. In Waterfall model analysis documents : - do not show what is unknown about the project, - do not show the true risks associated with the project - user shows confidence as so much effort have gone in - becomes the Bible for the stakeholders to follow & benchmark

business analysts spend a majority of their time on creating documentation rather than performing analysis, that is, learning about the problem

The Agile Business Analyst

The Agile Business Analyst in Analysis learn about the problem Agile analysis is highly iterative and incremental process In Agile Analysts, developers and project stakeholders actively work together - to understand the domain - to identify what needs to be built - to estimate that functionality - to prioritize the functionality - produces artifacts that are just barely good enough. In agile the Analysis Phase isnt a phase of a project isnt a task on a project schedule isnt a means unto itself

14

5/23/2011

The Agile Business Analyst

Process Parameters: Agile analysis should be communication rich Agile analysis is highly iterative Agile analysis is incremental Agile analysis explores and illuminates the problem space Agile analysis includes estimation and prioritization of requirements Agile analysis results in artifacts that are just good enough

The Agile Business Analyst

Things to keep in mind significant amount of business analysis must be performed to understand what the features and tasks must be before they can be estimated design depends upon analysis, Neither can be done without the other It need not identify classes, relationships, and methods, Rather those tasks, and their estimates, describe external behaviors that are visible and demonstrable to the stakeholders the stakeholders could choose a few of the most important features. The team could break them into tasks, estimate them, prioritize them, and choose a months worth of the highest priority tasks to implement

In an agile project team repeat this activity

15

5/23/2011

A day with Agile BA

1. Identify System Users 2. Define Main Users Goals 3. Define System Usage Patterns 4. Invent Functional Solution to Meet Users Goals and Usage Patterns 5. Define Main Navigation Paths 6. Create UI Mockups 7. Polish UI Elements
Who will use the system? What I (as a user ___) want to achieve with help of the system? What are the typical user behaviors (daily, specific situations, etc.)? What is the best way to satisfy usage pattern? What functional areas/action should user execute to complete usage pattern? Prototype showcase Can we improve UI to reduce clicks, provide better visibility, etc?

Agile is like a
If u use it properly in your work

If u use it wrongly, it will put you into trouble

16

5/23/2011

Thank You
julenmohanty@gmail.com www.twitter.com/julenmohanty www.linkedin.com/julenmohanty julenmohanty

17