4. Agility in IT projects
600 Minutes IT Helsinki 17.03.2015
Marek Niziołek CIO Synthos SA POLAND
Certified PMP, SCRUM MASTER, APMG Agile Practitioner
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
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
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
marek.niziolek@synthosgroup.com
PMP, ITIL Expert, SCRUM MASTER, APMG Agile Foundation / Practitioner
