Applying both of Waterfall and Iterative Dev.

in DSF Operating Lease Phase -1

Deny Prasetia, CBAPid.linkedin.com/in/denyprasetia

PT. Berlian Sistem Informasi - Jakarta, 2015

2

What will be talked today:

• What are the challenges?

• What is waterfall model and iterative dev. Model?

• Project approaches consideration.

• Why apply Iterative Dev. in Waterfall Project?

• Project Factors of successfully applied Iterative Dev.

• Lesson Learned

3

2014 Jun Jul Aug Sep Oct Nov Dec

Works STEP-1 STEP-2

Aiming

What are main challenges?

Basic 3 Policies of this Project

Develop a Simple tool

A tool with Minimum

Functionality

Develop in a Short Time

Assessment Development

Submit Proposal for

Development

1st Go Live

Submit Proposal for Operation

2nd Go Live

• Business Direction:Mantra: “Develop minimum functionalities in short time, then go to the permanent solution”

Schedule:

4

What are main challenges? (Cont.)

Units

Time

600

1500 Growing of Operating Lease Business

SOP Global Business Flow

Until March 2015, the number of units are projected will be growing up to 1,500.

DSF was trying to fix SOP and Global Business Flow for operating lease business.

DSF is facing several problem due to difficulty of managing the units (contracts).

Data Input and Reporting still input manually by excel

May

‘14

Mar

‘15

• Business case:

5

What are main challenges? (Cont.)• Consideration Issue :

What is important for this project?• Goal?• Schedule?• Cost?

If Goal?• Be clear with management goal should be define through on the Assessment.• Be clear with the management what is in the project scope versus what is in the project

out of scope.

If Schedule or Cost?• Need to setup clear and project cost and project schedule;• Need to communicate clear and often about all updates and changes.

What is a pain of this project?• Requirements (how rigid and well defined?);• Duration (how long is the planned duration?);• Technology/ business domain knowledge (Do we have a quite knowledge?)• Project resources and team sizes (Do we have a available team? And how big?);

6

• Waterfall model:

• Iterative development model:

What is waterfall model and iterative dev. Model?

Analysis

Design

Coding

Testing

Training

Phase by phase: Analysis > Design > Coding > Testing and delivery of functionalities as whole product.

Project Setup/ Envision

Analysis & Design Develop Develop Develop & Release

Iteration 0 Iteration 1 Iteration 2 Iteration 3 Iteration 4 For small set of functionality Analysis and Design will be completed first before coding and testing within same iteration.

Release

Initiation

7

The main challenges in applying Iterative Dev. in Waterfall project are to define where exactly in the project to do that and

how deep. And make it timely.

Intermezzo!

Bad Construction Better Construction

8

Step – 1: Assessment

Project approaches consideration

Requirement Assessment

Review & Get Feedback

Sign Requirement

Sheet

Alternative way to define a Development Goal

Through this Assessment, we had define new business flow & clarify requirement.

Based on definition above, we have:• Determine Scope of the

Development• Determine Schedule and Cost for

the Development

System Design & Prototyping

Review & Give Feedback

Brush-up & Retrospective

Prototype and Design as Certain Goal Image

DevelopA System

Testing and Training

Go Live!

To keep the accuracy of system requirements, shorten of design time, and minimize rework, we propose “Prototyping” . DSF can have certain goal image (especially for screen and report) from the Prototype

These “output” is a basis for development.

Step – 2: Development

9

• Schedule

Project approaches consideration (Cont.)

10

When and why to apply Iterative Dev.?• When to use Waterfall and Iterative Dev.?

• Why apply Iterative Dev. in Waterfall Project?

Waterfall Iterative Development

• Requirements are very well known; • Product definition is clearly stable and deep.• End users are limited involved on

development side.• Full feature application must be delivered

within determined timeline.• Project is large, expensive, complicated.

• Business objective are will defined;• Functionality of the system is clearly visible;• Working closely with customer with

collaborative environment.• System can be modularized with rapid

deployment.• Project can be simplified into smaller and

less complex.

• Better control of budget and schedule;• Quick responding to changes. • Better to speed-up development process. • Better improve quality of the delivered product;• Better to give more opportunities for customers to collaborate in development.

Also, iterative development is best suited to project where the problem is complex and may not be fully understood at the beginning of the project.

11

• Did we build the thing right?• Does the solutions satisfy the requirements that we defined?

• We haven’t ensured that we truly understand user needs and that our solution will meet those needs?

Intermezzo!

12

Project Factors of successfully applied Iterative Dev.• Approach planning in a customer-centric way.

Involve design and usability up front to ensure you are not just lumping together killer features, but creating a comprehensive product that customer love.

• Use rapid prototyping tools.Clickable wireframes can be done to plan out a substantial mock-up of the product before development begins. It fast easy to modify and get customer feedback on.

• Define and get approval on Metadata ahead of development.Often simple spreadsheets can be constructed and presented to the customers and sign-off during initiation and planning.

• Start technically difficult but research development during planning.There is no reason why a really difficult domain can’t be started on early to get schedule traction.

• Applying a collaborative environmentCross-functional team (e.g., includes members with domain experts); customer collaboration with Intensely collaborative

• One team philosophyOne fails we all fail. The project manager needs to enforce team accountability.

• Do regularly monitoring by daily basis (AM & PM time) Do daily meeting to retrospective and discuss impediments. It allows for earlier identification and management of risks and issues along with an immediate opportunity to escalate to senior management, if needed.

• Don’t wait to start QA until the endInject sprint testing into your rigid development!

• Continual improvement on the each iterationLesson learned from previous iteration implemented in the next iteration

13

Lesson learned• Closely manage risks and issues.

Agile tends to only focus on current impediments. Take the time to more formally track risks and issues and schedule frequent discussions to track and manage project risks and issues across the overall duration of the project.

• Ensure quality and thoroughness throughout the Agile process. For example, a high-level requirements document may be constructed during Assessment or Iteration 0. This document should be iteratively built and update throughout the development iteration so that by the end of the project, a comprehensive and accurate requirements document exists. This will facilitate knowledge transfer, support, and maintenance activities.

• Story point relative estimation can be adoptedEstimating software development projects is hard. Traditional approaches involve a large upfront detailed requirements gathering effort resulting in pages of complex documentation and a project plan with estimated hours and moneys. Given the rising popularity of Agile development methodologies and our customer’s increased focus on saving time and money we advocate quickly building a high-level feature list and using Story Point Relative Estimation to more accurately estimate costs and level of effort.

“Regardless of methodology, the majority of the strengths of both approaches come from people working together towards a common goal”—accountability leads to high-performing teams!

14

http://agilemethodology.org/ http://agilemanifesto.org/https://msdn.microsoft.com/en-us/library/dd997574.aspxhttp://www.modernanalyst.com/Resources/Articles/tabid/115/ID/2878/Do-Agile-Projects-Need-Written-Requirements.aspxhttp://scrumreferencecard.com/scrum-reference-card/http://blog.celerity.com/why-your-agile-team-should-use-story-point-relative-estimation

THANK YOU!