2014 12 03 projects where agile approach seems to be optimal fin
- 1. Projects, for which adaptative / Agile project management approach seems to be optimal 600 Minutes IT Istanbul 03.12.2014 Marek Niziołek CIO Synthos SA POLAND Certified PMP, SCRUM MASTER, Agile Foundation/Practitioner
- 3. © 2014 3 SYNTHETIC RUBBER - the most important product of Synthos Group SYNTHOS GROUP Number 1 in Europe – ESBR production (basic rubber mainly for tyres) Number 2 in Europe – Nd-PBR production (advanced rubber mainly for tyres) Number 3 in Europe – Expandable Polystrene (EPS) production Number 1 in Central Europe – Extruded Polystyrene (XPS) production
- 4. Projects, for which adaptative / Agile project management approach seems to be optimal 600 Minutes IT Istanbul 03.12.2014 Marek Niziołek CIO Synthos SA POLAND PMP, SCRUM MASTER, Agile Foundation
- 5. AGENDA I. Classic (waterfall) project management process – main steps II. Projects implemented using adaptative (agile) methodology I. Travelling project (example) implemented using adaptative aproach II. Main steps of adaptative project management proces III. Main charakteristisc of adaptative aproach IV. Projects for which adaptative aproach seems to be optimal
- 10. Analysis
- 11. Detailed design
- 17. SOFIA BULGARIA
- 19. BELGRADE SERBIA
- 20. BUDAPEST HUNGARY
- 22. Warsaw POLAND
- 23. Verification Test READY – we have done it! Release Warsaw POLAND
- 25. Let’s summarize conditions of our project: 1) Our OBJECTIVES were clearly and precisely defined. 2) It was quite probably that our objectives wont be changed during execution (during the trip). 3) We had deep knowledge about the subject collected. We had experienced supporting team, igh quality, prooved designing tools. 4) If your own team is not enough experienced in thes subject of project it is better when you execute based on good quality design as basis – cllasic/waterfall approach. 5) When you have partcular conditions / limits set for the project ie go through Bratislav (you are executing project with government grants) in most cases it is easier to go through it using cllasic/watterfal approach, based on good quality design. 6) Riscs looks like not too meaningfull, project rather predictable?? 7) Are you experineced in managing project with classic / waterfall approach, this project looks like other executed before? WATERFALL PROCESS
- 26. In IT projects we can observe such conditions / situation in following cases: - Implementation of IT infrastructure projects, and not too innovative technology, not too complex and unpredictable project; - we implement technology prooved / implemented many times before; - we implement more configurable than programmable software aplication solution in well known area ie financial accountancy software in mature organization company. - We implement complex, sophisticated system i.e. ERP but mature, mostly configurable project and in mature organization. WATERFALL PROCESS
- 27. START AIM Travelling project – type 2 AGILE
- 29. START AIM 1 2 3 4 Ordered list of deliverables of the project Project (feature) backlog
- 31. START AIM
- 33. AIM „1”
- 38. Sucess – we’ve done IT! Release
- 39. Project feature backlog Project vision Release 1 iteration 1 Release 1 iteration 2 Release 2 iteration 1, 2 AGILE PROCESS From „Agile practices for Waterfall Projects..” Barbiee Davis
- 40. Traditional process versus AGILE: AGILE PROCESS „Agile samurai..” Jonathan Rasmusson Traditional Agile One time tasks Continuous (ongoing) tasks Analysis Design Code, manufa cture, build Tests AnalysisDesignBuildTests
- 41. Characteristics of the project: 1) We have aims defined, but it is very difficult to precisely define detailed requirements, tactics of implementation because we have to operate in unknown (for us) area. 2) Conditions, subobjectives, and even some of objectives change or/ad can be changed during the project, when implementation executed and results of the project are revealed. We can’t precisely define what is excpected product of the project. AGILE PROCESS 3) We have large amount of risks in the project influencing the project, way of it’s implementation. 4) Huge procustomer approach in the project + for customer more important is to achieve best results / products than to keep prepared plans, limits (time, way of implementation, in limits also even money). 5) We have experienced / interdysciplinary / crossfunctional implementation team. Best if they are experienced in cooperation in such projects where everyone feels responsible for results of the project, focusing on own area of expertise but also taking care of all aspects / integration. Implementation team dedicated for the project (if possible no time shareing). Implementation team located in one physical place. 6) Top management/ sponsors opened for adaptative approach believing that it is leading for customer satisfation. Rules of such cooperation should be properly defined, but there is TRUST between supplier and customer.
- 42. AGILE PROCESS A) Creation of innovative solution / product – we have vision and main objectives, but we dont know preciisely what precisely final products should be (what will work properly, what not); B) Implementation of new, innovative products – we dont have experience / knowledge on how to implement it in particular enviroment, what is important, how it should work, what will work properly, what not and when it is possible to implement step by step instead of big bang – ie pilots, Proofs of Concept; C) Startup - we implement new innovative product dont knowing who is the customer, who can use it and what will be appreciated but particular group of customers (Customer Driven Implementation). D) Recovery of troubled projects. In IT area we have such situation in types of projects as below:
- 43. Sun shine – „new is coming:, new, innovative = difficult to estimate, forecast projects Take attention – SWAMPS, no solid groud Many RISKS, NO CLEAR PATH, MANY CHANGES possible Troubled projects (dark clouds) Take attention – SWAMPS, no solid groud! Customer should be close to the team! Don’t loose customer and its requirements / aims KEEP TEAM STRONGLY COPPERATING, ONE CLOSE TO ANOTHER
- 44. Manifesto for Agile Software Development „We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: 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, we value the items on the left more.” 1-13 lutego 2001 roku w ośrodku wypoczynkowym Snowbird w USA (stan Utah)
- 45. AGILE PROCESS VISION + MAIN OBJECTIVES +formal project approval (go) At the beginning of the project: requirements planned for implementation desribed as product features / (user stories) At the beginning of each release: prioritise backloog / user stories by PRODUCT OWNER Each iteration /sprint: 1) Plan which features / user stories are going to be implemented, by whom in particular iteration / sprint; 2) After execution verification: a) what is done (in comparison to plans), b) What is our speed of our implementation (in comparison to plans), 3) Retrospective (how we can improve our proces of implementation / organization At the end of release: update of priorities of features / user stories for implementation
- 46. 1) Masz jasno i dokładnie zdefiniowany cel 2) Jest duża szansa, że w trakcie realizacji cel się radykalnie nie zmieni? 3) Masz wiedzę o zagadnieniu, dobry, doświadczony zespół / bardzo dobre i sprawdzone narzędzia do projektowania? 4) Jeśli Twój zespół do realizacji nie jest zbyt doświadczony to lepiej jeśli będzie realizował w oparciu o dobry, gotowy projekt. 5) Jeśli masz narzucone z góry ograniczenia np. konieczność przejazdu przez określone miejsce np. Paryż) (realizujesz projekt nadzorowany przez instytucje rządowe, unijne itp.) -> często lepiej i łatwiej przebrnąć przez taki projekt realizując go zgodnie z klasyczną metodologią i w oparciu o dobry projekt. 6) Ryzyka wyglądają na raczej niewielkie, projekt jest przyzwoicie przewidywalny? 7) Masz doświadczenie w realizacji tego typu projektów metodą klasyczną, a Twój nowy projekt nie wykazuje dużej odmienności od poprzednio - z sukcesem zrealizowanych - podobnych projektów. Practical examples: IT project in chemical manufacturing company (Synthos) implemented in Agile style: - Creation of Corporate portal; - Internal programming of set of small applications supporting business: i.e business trips, bonuses, Contracts, Holidays, Keizen, - Implementation of configurable IT systems , where no clear definitione what may usefull in fact -> implementation of Igrafx Process Central = Business Process Management system for the Synthos Group
- 47. Creation of Synthos Corporate Portal – example of Agile project • Project VISION / OBJECTIVES: Creation of modern, usefull and used by employees, ergonomic tool for communication /information sharing between Synthos’s workers/employees • WHY AGILE: • Large scope, known priorities, but we are not sure what will be usefull / used by users • We want to define main scope, estimate costs / schedule, but we want to verify step by step if products work end continue or stop • Main riscs / areas of incertainty: • broad scope, • not only application required – departament want to publish their own informations - usefull for other • the board requires communication platform usefull and utilised bu employes; • we want to have effects AS SOON AS POSSIBLE (fast implementation), • we want to spend money only for that what is usefull. • we don’t want to spent money in Time & Material mode of cooperation – flexibility and risc sharing approach required
- 48. Thank you for your attention! Marek Niziołek IT Director Synthos SA [email protected] PMP, ITIL Expert, SCRUM MASTER, APMG Agile Foundation / Practitioner