Julen Mohanty - Agile Adoption

7/29/2019 Julen Mohanty - Agile Adoption

1/17

5/23/2011

1

Agile AdoptionAgile AdoptionAgile AdoptionAgile Adoption:Success or Failure

Agile AdoptionAgile AdoptionAgile AdoptionAgile Adoption: Success or Failure

Julen C Mohanty

Citicorp Services India Ltd


2/17

5/23/2011

2

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


3/17

5/23/2011

3

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

Source: http://agilemanifesto.org/

What is Agile

That is, while there is value in the items on

the right, Agile value the items on the left more.

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

Problems with Waterfall Development


4/17

5/23/2011

4

Effect of Delays

Start-

up

Initi-

ationConcept

Design

Func

DesignBuild / Test

Tech

DesignDeploy

Start-

upInitiation

Concept

Design

Func

DesignBuild / Test

Tech

DesignDeploy

Start-

upInitiation

Concept

Design

Func

Design

Tech

DesignBuild / Test Deploy

Typical Project Plan:

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

Option B: Extend Project End Date and Increase Cost

OR

Typical Project Execution:

Clients Perception

Start-

upInitiation

Concept

Design

Func

Design

Tech


12 Month Project (originally a 9 month project)

Month 10:

Value Is Visible

(Client begins

testing)

Month 12:

Value Is

Achieved

Months 1-9: No Visible Value


5/17

5/23/2011

5

Lack flexibility to change

Start-

upInitiation

Concept

Design

Functional

Design

Tech



Theory:

All

requirements

should be

defined

More

requirements

discovered.

Conceptual

Design changes

More requirements /

problems discovered

during build. Functional

Design / Technical Design

changes

More requirements

discovered.

Functional Design

changes

Testing at the End (Fail Late)

Start-

upInitiation

Concept

Design

Functional

DesignTech



Bugs and critical

Integration issues

arent driven out until

here resulting in delays


6/17

5/23/2011

6

Agile Development is focused on an iterative (addressing all

aspects of the lifecycle in each iteration) and flexible approach

to software development

Agile : Iterations

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

Deliver Value to Customer


7/17

5/23/2011

7

Attack Critical Risks Early

Iter 1

9 month project

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

Iter 2 Iter 3 Iter 4 Iter 5

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

Test Early and Test Often


8/17


9/17

5/23/2011

9

Agile Requirements Characteristics

Independent Avoid dependencies with other stories

Write stories to establish foundation

Combine stories to deliver in a single iteration

Negotiable Stories are not a contract

Not every story must be negotiable,

Courtesy : Bill Wake

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

Testable Acceptance criteria should be stated in customer terms

Tests should be automated whenever possible

Team members should demand clear acceptance criteria

INVEST

WHY AGILE

FAILS

Not Looking at the bigger Picture

Not having proper tools No Collaboration with Customer

No Agile Mindset

Absence of Team Work OR

collaboration among team membersNo feedback system

Not coming out from rigid

plans

No Response to change

Sticking to contract and not the

need of the situation

Agile is not a silver bullet. Dont

expect Charismatic ResultsAgile as an excuse for having no

discipline

Agile without explanation

Agile process fixation Time Value of Money

Lack of Powerful CommunicationNot Having Test Driven

DevelopmentNot Measuring Value

deliveredPeople in fear to lose title

Team priorities change rapidly

leading to productivity undermine

Team keeps on missing

iteration deliverables

Bugs found by QA after the

iteration completes

The design & architecture is a mess!


10/17

5/23/2011

10

TechnologyOrganization

Structure

Leadership People

CULTURE

Failure Category

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


11/17

5/23/2011

11

group into 4

major regions

One large exchange

from each region

4 different tracks of

development with agile

Incrementing to regionIntegrating to globalTaking care ofregional specific

requirements

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

CASE STUDY 1

Thinking:

Are all team members aware of their progress 4 0

toward meeting team goals?

Does the team improve their process in some way 5 0

at least once per month?

Collaborating:

Do team members generally communicate without confusion? 4 0

Do nearly al l team members trust each other? 5 0

YES NO

Releasing:Can any programmer on the team currently build a tested, 5 0

deployable release with a single command?

Do all programmers integrate their work with the main body 4 0

of code at least once per day?

How to Measure Agility


12/17

5/23/2011

12

Planning:

Does the team have a plan for achieving success? 4 0

Does the team regularly seek out new information and 2 0

use it to improve their plan for success?

YES NO

Developing:

Are all programmers comfortable making changes to the code? 3 0

Do unexpected design changes require difficult or costly 0 3

changes to existing code?


Collaborating

Developing

Thinking

Planning

Releasing



13/17

5/23/2011

13

7.5 points or less : immediate improvement required (red)

7.5 9.5 Points : improvement necessary (yellow)

9.5 10 Points : improvement possible (green)

10 Points : no further improvement needed


DeveloperBusiness

Analyst

TesterTester

Developer

Business

Analyst/SME

TeamProject

Process

undertakes

shapes & follows theapplies

Agile is all about people, its people who

build software not processes

Agile

Suggested way to approach Agile


14/17

5/23/2011

14

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 creatingdocumentation rather than performing analysis, that is, learning about

the problem

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 Phaseisnt a phase of a project

isnt a task on a project schedule

isnt a means unto itself



15/17

5/23/2011

15

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


Process Parameters:

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 choosea months worth of the highest priority tasks to implement

In an agile project team repeat this activity

The Agile Business AnalystThings to keep in mind


16/17

5/23/2011

16

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 Can we improve UI to reduce clicks, providebetter visibility, etc?

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

Agile is like a

If u use it properly in your work

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


17/17

5/23/2011

17

Thank You

www.twitter.com/julenmohanty

www.linkedin.com/julenmohanty

julenmohanty

[email protected]

Date post:	04-Apr-2018
Category:	Documents
Upload:	raja2jaya
View:	222 times
Download:	0 times

Julen Mohanty - Agile Adoption

Documents