Upload
marek-niziolek
View
256
Download
0
Embed Size (px)
Citation preview
Projects, for which
adaptative / Agile project management
approach seems to be optimal
600 Minutes IT Istanbul 03.12.2014Marek Niziołek CIO Synthos SA POLAND
Certified PMP, SCRUM MASTER, Agile Foundation/Practitioner
© 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
Projects, for which
adaptative / Agile project management
approach seems to be optimal
600 Minutes IT Istanbul 03.12.2014Marek Niziołek CIO Synthos SA POLAND
PMP, SCRUM MASTER, Agile Foundation
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
Traveling project type 1
START
ISTANBULTURKEY
START
ISTANBULTURKEY
Analysis
Detailed design
ExecutionManufacture / Build
ExecutionManufacture / Build
ExecutionManufacture / Build
ExecutionManufacture / Build
SOFIABULGARIA
ExecutionManufacture / Build
BELGRADESERBIA
BUDAPESTHUNGARY
BRATISLAVASLOVAKIA
WarsawPOLAND
VerificationTest
READY – we have done it!
Release
WarsawPOLAND
WATERFALL PROCESS
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 experiencedsupporting team, igh quality, prooved designing tools.
4) If your own team is not enough experienced in thes subject of project it isbetter 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 throughBratislav (you are executing project with government grants) in most cases it iseasier to go through it using cllasic/watterfal approach, based on good qualitydesign.
6) Riscs looks like not too meaningfull, project rather predictable??
7) Are you experineced in managing project with classic / waterfall approach, thisproject looks like other executed before?
WATERFALL PROCESS
In IT projects we can observe such conditions / situation in following cases:
- Implementation of IT infrastructure projects, and not tooinnovative technology, not too complex and unpredictable project;
- we implement technology prooved / implemented many timesbefore;
- we implement more configurable than programmable software aplication solution in well known area ie financial accountancysoftware in mature organization company.
- We implement complex, sophisticated system i.e. ERP but mature, mostly configurable project and in mature organization.
WATERFALL PROCESS
START
AIM
Travelling project– type 2 AGILE
AIMProject vision
START
AIM
12
3
4
Orderedlist of
deliverablesof the projectProject (feature)
backlog
START
AIM
START
AIM
1a
1
Release 1; iteration 1
AIM„1”
START
AIM
1a’
1’
Release 1; iteration 2
START
AIM
1a’
1’
2’
Release 2; iteration 1, 2
Sucess – we’vedone IT!
Release
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
Traditional process versus AGILE:AGILE PROCESS
„Agile samurai..” Jonathan Rasmusson
Traditional
Agile
One time tasks Continuous (ongoing) tasks
Analysis Design
Code, manufacture, build
Tests
An
alysisD
esign
Bu
ildTe
sts
Characteristics of the project:
1) We have aims defined, but it is very difficult to preciselydefine detailed requirements, tactics of implementationbecause 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, whenimplementation executed and results of the project arerevealed. We can’t precisely define what is excpected productof 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 ifthey 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 dedicatedfor 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.
AGILE PROCESS
A) Creation of innovative solution / product – we have vision and main objectives, but we dont knowpreciisely 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, whatnot 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 suchsituation in types of projects as below:
Sun shine – „new is coming:, new, innovative = difficult to estimate, forecastprojects
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 itsrequirements / aimsKEEP TEAM STRONGLY COPPERATING, ONE CLOSE TO ANOTHER
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)
AGILE PROCESS
VISION + MAIN OBJECTIVES +formal projectapproval (go)
At the beginning of the project: requirementsplanned for implementation desribedas 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 prioritiesof features / userstories for implementation
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 applicationssupporting business: i.e business trips, bonuses, Contracts, Holidays, Keizen,
- Implementation of configurable IT systems , where no cleardefinitione what may usefull in fact -> implementation of Igrafx Process Central = Business Process Management system for the Synthos Group
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
Thank you for your attention!
Marek Niziołek
IT Director Synthos SA
PMP, ITIL Expert, SCRUM MASTER, APMG Agile Foundation / Practitioner