My presentation as a guest speaker at Alto University in Helsinki

1. How to create
usless software
…and distribute it
Marcin Kokott
Agile/Lean Coach, Senior Consultant
Tieto,
marcin.kokott@tieto.com
© 2012 Tieto Corporation

2. • 16 000 IT professionals in close to • Net sales approximately EUR
Tieto 30 countries
• Customers on all continents
1.8 billion
• Listed in NASDAQ OMX Helsinki
today • One of the leading IT service
companies in Northern Europe and
and Stockholm
• Founded in 1968
global leader in selected segments
© 2009 Tieto Corporation

3. Introduction
• Marcin Kokott
• ...more than 8 years experience from various roles
in IT industry
• Currently Agile/Lean Coach of business critical
cases in Tieto
• ...has been implementing Agile & Lean in various types of projects for last 3 years in
context of distributed teams (whole Scandinavia, Germany, Netherlands, Poland, India
and China)
• ...conducting trainings and sessions from the area of Agile and Lean to more than 1800
people already
© 2012 Tieto Corporation

4. What models do we have?
• Badly
• Hope and Prayer
• Dictate and motivate
• With great difficult
4 © 2012 Tieto Corporation

5. Cost of mismanaged projects
• Producing the wrong product
• Developing the project for six months and Customer is syaing that this is
not what they want
• Producing the product of inferior quality
• Rebooting the systems f.e. car
• Being late
• Working 80 hours weeks
5 © 2012 Tieto Corporation

6. Some industry experience
Source:
Standish Group
Chaos Report 2009
6 © 2012 Tieto Corporation Motivation

7. Innevitable trade-off
1. Good (Quality)
2. Fast (Time to Market)
3. Cheap (Cost Effectivness)
4. Done
…pick any 3 and you will not have the 4th one
7 © 2012 Tieto Corporation

8. Finaly we know how DONE we are!
DOD-STD-2167A
8 © 2012 Tieto Corporation

9. But…
• „I believe in this concept, but the
implementation described above is risky
and invites failure.
• […] Either the requirements must be modified,
or a substantial change in the design is
required. In effect the development process
has returned to the origin and one can expect
up to a l00% overrun in schedule and/or
costs.”
9 © 2012 Tieto Corporation

10. Virtual progress
What are your answers to “How‟s it going?”, “When are you done?”
© 2012 Tieto Corporation 10

11. What is the reality?
• 28% of projects completed on time and on budget
• 49% of projects overran original estimates.
• Time overrun averaged 63%
• Cost overrun averaged 45%
• 23% of projects cancelled before completion
Standish Group Reports, ‘01
www.standishgroup.com
© 2012 Tieto Corporation 11

12. What is wrong with the traditional (waterfall) way of working?
3. Loss of
1. Restrictive contract
information
settled too early
Project Plan/Estimation
Requirements Gathering 8.
Functional
Squeezed
Specifications
Design
Specifications
Code
2. Analysis 9. Big surprise
paralysis Test
+ Delay
4. Virtual reality, Fix / Integrate $
progress measured by
7. Holy hacking
document reviews
5. Chill out, dude 6. Hurry up!!
© 2012 Tieto Corporation 12

13. What is the result then? (if there is any)
Standish Group Reports, „02
www.standishgroup.com
© 2012 Tieto Corporation 13

14. Requirements gathering
© 2012 Tieto Corporation 14

15. Traditional way of working
• Requirements from customer
© 2012 Tieto Corporation 15

16. Traditional way of working
• How the System Analyst understood it...
© 2012 Tieto Corporation 16

17. Traditional way of working
• How the Designer designed it...
© 2012 Tieto Corporation 17

18. Traditional way of working
• How the Programmer wrote it...
© 2012 Tieto Corporation 18

19. Traditional way of working
• What sales guys promised to be delivered …
© 2012 Tieto Corporation 19

20. Traditional way of working
• How the project was documented...
© 2012 Tieto Corporation 20

21. Traditional way of working
• What was installed...
© 2012 Tieto Corporation 21

22. Traditional way of working
• What was charged to customer …
© 2012 Tieto Corporation 22

23. Traditional way of working
• How the product was supported...
© 2012 Tieto Corporation 23

24. Traditional way of working
• Finally, what the customer really needed...
© 2012 Tieto Corporation 24

25. Agile
• Agile manifesto
• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan
• Key points: iterative and incremental development with prioritized
(based on risk and business value) tasks!
• See http://www.agilemanifesto.org/
• Agile frameworks:
• RUP, Open up, Scrum, XP Crystal-clear, …
,
© 2012 Tieto Corporation 25

26. Agile
It’s NOT about getting FASTER
It's NOT about way to get project QUICKER
It's about to know HOW SCREWED YOU ARE EARLY ENOUGH
26 © 2012 Tieto Corporation

27. Scrum
http://www.epfwiki.net/wikis/scrum
© 2012 Tieto Corporation Page 27

28. Process vs. principles
28 © 2012 Tieto Corporation

29. Let’s make it even
more complicated
Global Development
© 2012 Tieto Corporation

30. Global Development
& Delivery
• Why?
• Cost benefits
• Skilled labour (more resources)
• Strategic advantage
• …
• Geographical models
• Onsite (internal, external staff sitting on the same site)
• Near shore (neighbouring countries, same region – reduces travel costs,
communication easier than in the offshore model)
• Offshore (own premises, project based, task based)
Source: IBM GDD Redbook
200
8-
03-
09 © 2012 Tieto Corporation Page 30

31. Weird problems
• You can’t find developers between managers
• „The Others” are taking over the WORLD
• On time, on budget… not usefull
• Have you heard about developers from Rain Forest?
• Late with deadlines
• Maintanance contracts
31 © 2012 Tieto Corporation

32. Outsourcing communication specifics…
© 2012 Tieto Corporation

33. Hand of lessons
• Divide around architecture
• Easy to have progress of „DONE-DONE”
• Have contact with customer
• So teams knows what is value for customer
• See whole elephant
• Involving people in improvements, not sub-optimizing
• Authonomy, purpous and learning = MOTIVATION
• People working even for free
• Focus on removing waste
• …and improve
33 © 2012 Tieto Corporation

34. © 2012 Tieto Corporation

35. Typical
ramp-up risks
Global delivery
© 2012 Tieto Corporation

36. Experience report:
Typical transfer project risks
1. Unrealistic expectations
2. Local inefficiencies get multiplied by distribution
3. Poor transfer planning
4. Too big, fast and insufficiently controlled change
5. Lack of support and experience reuse
6. Insufficient and ineffective knowledge transfer
7. Poor team co-ordination
8. Psychological factors neglected
9. Sub-optimization
© 2012 Tieto Corporation 2009-07-
31

37. A project story: Energy sector
• Customer provides gas, electricity, district heating & cooling, …
• Around 2M end customers (customers of customer)
• 30 people in Norway, 12 people in Czech Rep.
• Project consists of 6 sub-projects
• Each has its team, leader and business guys
• Each delivers an application with interfaces
to other sub-projects
customers
• Needs for transfer: Ääneseudun Energia
Trondheim Energi
• Red numbers Umeå Energi
Outokummun Energia
Vang / Jotun Etelä-Savon Energia
• Lack of people Fortum Norge
Dalakraft Parikkalan Valo
Imatran Seudun Sähkö
Scandem
Joutsenon Energia
• Tieto strategy Vantaan energia
Turku Energia
Fortum Sverige
• Frustration Kraft och Kultur
Jönköping Energi
Göteborg Energi
37 © 2012 Tieto Corporation

38. Unrealistic
expectations
Project challenges Too big and
fast change
• Need of another 30 people in Czech Rep.
Psychological
• Huge HR problem, how to find instantly 30 people? factors
• How to build “A team”? neglected
• Time limit for the transfer (1st of May – 20th of October)
• How to transfer business and technical knowledge from 6 projects older than
10 years in such a short time?
Local inefficiencies
• Technical struggles get multiplied by
• Legacy code, not documented, mix of technologies, distribution
• Waterfall based way of working
• Promised scope to customers, how to keep the promise?
• Phases based on roles (req/an/des/tst) are not suitable for knowledge
transfer
Lack of support
• Lack of mentors on Norwegian side
• How to support Norwegian part of the teams on daily basis?
38 © 2012 Tieto Corporation 2009-07-
31

39. Risk mitigation
Global delivery
© 2012 Tieto Corporation

40. 1. Mapping phase:
Go deep to understand context
• Kaizen workshop
• Value stream mapping
• Root cause analysis
• Business objectives and expectations (IBM MCIF)
• Mapping business objectives, operational objectives and practices
• Transfer project road-map – incremental adoption of practices
(IBM MCIF)
• Backlog and prioritization (of Release planning)
• Iterative practice (learning by doing)
• Whole team (cross-functional, self-managed team)
40 © 2012 Tieto Corporation

41. 2. Setup phase:
Establish improvement framework
• Steering Model, Mentor Team, Initial Backlog
• Agile courses
• Setup iterations – first iteration planning & assessment
facilitation
• Measures:
• Agile self-check (IBM MCIF)
• Iteration burn-down chart
• Iteration evaluation criteria: passed/failed
• Day by day support (mentoring)
41 © 2012 Tieto Corporation

42. 3. Mentoring phase
“Give a man a fish; you have fed him for
today.
Teach a man to fish; and you have fed him for a
lifetime.”
42 © 2012 Tieto Corporation

43. Practice:
Backlog and prioritization - before
• Scope defined based on paid Change Requests estimated upfront
• Consequence:
• Push & stress
• Technical debt
• Productivity slowdown
• Delays
• Production errors
• Angry customers
• Risk: Poor transfer planning
• Busy people in Norway
• Idle people in Ostrava
43 © 2012 Tieto Corporation

44. Practice:
Backlog and prioritization - after
• All requirements (Change requests + Error corrections)
prioritized:
• Business importance
• Technical complexity
• Dependence on other components
• Knowledge transfer ratio
• Consequence:
• Critical stuff done first, less stress eventually
• Team keeps focus on important stuff
• Practical way to organize knowledge transfer
Mitigation of:
• Unrealistic expectations
• Poor transfer planning risk
44 © 2012 Tieto Corporation

45. Practice: Iterative development +
learning by doing
• Before:
• Customer waiting for a change 8 -12 months
• Knowledge transfer organized separately from production project
• Big theory first, practice later (based on examples)
• After:
• Learning by doing based on real implementation tasks
• Tangible results tested & delivered in iterations
• Trainees experienced whole lifecycle every iteration
Mitigation of:
• Local inefficiencies get multiplied by distribution
• Insufficient and ineffective knowledge transfer
• Too big, fast and insufficiently controlled change
45 © 2012 Tieto Corporation

46. Practice: Iterative development +
learning by doing
Production scope Competence plan
Separated originally
Backlog
+
Delivery
…
Iteration 1 Iteration 2
46 © 2012 Tieto Corporation

47. Practice: Whole team
• Before:
• Norwegian Team leaders and Project manager plan the release
• Czech team receives development tasks
• Low communication, low motivation
• After:
• Whole team planning and assessment
• Daily meetings (Norway – Czech)
• Team = analysis, design, coding, testing
Mitigation of:
• Poor team co-ordination
• Psychological factors neglected
• Sub-optimization
47 © 2012 Tieto Corporation

48. Measurements:
IBM MCIF Agile Self-check
5.0
4.0
Time boxed iterations
Working Increment
3.0 Feedback Used
Estimating
Prioritized Backlog
Collaboration
2.0
1.0
it#1 it#2 it#3 it#4+5 it#6 it#7
48 © 2012 Tieto Corporation

49. Measurements: Burn-down chart
800
700
Re-planning to avoid failure again
678.5
647
621
600
500
400
339.5
300
256.5 264.5
236.5
223.5 220.5
200 193.5
147.5
115.5 112.5
100
0
27.1.201028.1.201029.1.2010 1.2.2010 2.2.2010 3.2.2010 4.2.2010 5.2.2010 8.2.2010 9.2.2010 10.2.201011.2.201012.2.201015.2.201016.2.2010
Remaining work Completed work Amount of work Ideal line
49 © 2012 Tieto Corporation

50. Transfer project evaluation
• Transfer project manager:
“I see the project as very successful and I‟m happy we have decided
to go for Agile and we wouldn‟t be where we are without your help.”
• Release project manager:
“It wouldn‟t work without iterations at all. I wouldn‟t
take the job if we didn‟t change our way of working.”
• Product manager:
“This is really good way of working.”
Source: interviews at the end of Transfer project.
50 © 2012 Tieto Corporation 1/25/2012

51. Typical transfer project risks and
mitigation actions - recap
1. Unrealistic expectations Connect business objectives
2. Local inefficiencies get multiplied and operational objectives
by distribution Deploy Agile & Lean practices
3. Poor transfer planning Do changes incrementally
4. Too big, fast and insufficiently controlled according priority
change Produce tangible result
6. Lack of support and experience reuse (measurable) and learn by
7. Insufficient and ineffective knowledge doing – make your hands dirty
transfer Replace management keeping
the status quo by leadership of
8. Poor team co-ordination change
9. Psychological factors neglected Optimize the whole – involve
10. Sub-optimization whole team (all stakeholders)
51 © 2012 Tieto Corporation

52. Summary: what have you learnt
• Discuss and explain:
• Transfer risks
• Mitigation actions
• Obstacles to adopt Agile in distributed environment
52 © 2012 Tieto Corporation Global delivery

53. © 2012 Tieto Corporation
Processes & Methods team
Tieto, Processes & Quality
te.rup@tieto.com