Sharing my project experience

1. Applying both of
Waterfall and Iterative Dev.
in DSF Operating Lease Phase -1
Deny Prasetia, CBAP
id.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
2

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
3
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.)
4
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
• Business case:

5. What are main challenges? (Cont.)
5
• 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?
6
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!
7
Bad Construction Better Construction

8. Step – 1: Assessment
Project approaches consideration
8
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
Develop
A 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.)
9

10. When and why to apply Iterative Dev.?
10
• 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!
11

12. Project Factors of successfully applied Iterative Dev.
12
• 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 environment
Cross-functional team (e.g., includes members with domain experts); customer collaboration with
Intensely collaborative
• One team philosophy
One 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 end
Inject sprint testing into your rigid development!
• Continual improvement on the each iteration
Lesson learned from previous iteration implemented in the next iteration

13. Lesson learned
13
• 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 adopted
Estimating 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. 14
http://agilemethodology.org/
http://agilemanifesto.org/
https://msdn.microsoft.com/en-us/library/dd997574.aspx
http://www.modernanalyst.com/Resources/Articles/tabid/115/ID/2878/Do-Agile-Projects-Need-Written-Requirements.aspx
http://scrumreferencecard.com/scrum-reference-card/
http://blog.celerity.com/why-your-agile-team-should-use-story-point-relative-estimation
THANK YOU!