Applying both of waterfall and iterative development

Applying both of waterfall and iterative development

• 1.
  Applying both of Waterfalland 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 betalked 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 JulAug 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 mainchallenges? (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 mainchallenges? (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 challengesin 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 approachesconsideration (Cont.) 9
• 10.
  When and whyto 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 webuild 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 ofsuccessfully 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 • Closelymanage 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!