"How to create usless software... and distribute it" (Alto university lecture, Helsinki)

616 views

Published on

My presentation as a guest speaker at Alto University in Helsinki

Published in: Business, Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
616
On SlideShare
0
From Embeds
0
Number of Embeds
5
Actions
Shares
0
Downloads
0
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

"How to create usless software... and distribute it" (Alto university lecture, Helsinki)

  1. 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. 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. 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. 4. What models do we have?• Badly• Hope and Prayer• Dictate and motivate• With great difficult4 © 2012 Tieto Corporation
  5. 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 weeks5 © 2012 Tieto Corporation
  6. 6. Some industry experienceSource:Standish GroupChaos Report 20096 © 2012 Tieto Corporation Motivation
  7. 7. Innevitable trade-off1. Good (Quality)2. Fast (Time to Market)3. Cheap (Cost Effectivness)4. Done …pick any 3 and you will not have the 4th one7 © 2012 Tieto Corporation
  8. 8. Finaly we know how DONE we are! DOD-STD-2167A8 © 2012 Tieto Corporation
  9. 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. 10. Virtual progress What are your answers to “How‟s it going?”, “When are you done?” © 2012 Tieto Corporation 10
  11. 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. 12. What is wrong with the traditional (waterfall) way of working? 3. Loss of 1. Restrictive contract information settled too earlyProject Plan/EstimationRequirements 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. 13. What is the result then? (if there is any) Standish Group Reports, „02 www.standishgroup.com © 2012 Tieto Corporation 13
  14. 14. Requirements gathering © 2012 Tieto Corporation 14
  15. 15. Traditional way of working• Requirements from customer © 2012 Tieto Corporation 15
  16. 16. Traditional way of working• How the System Analyst understood it... © 2012 Tieto Corporation 16
  17. 17. Traditional way of working• How the Designer designed it... © 2012 Tieto Corporation 17
  18. 18. Traditional way of working• How the Programmer wrote it... © 2012 Tieto Corporation 18
  19. 19. Traditional way of working• What sales guys promised to be delivered … © 2012 Tieto Corporation 19
  20. 20. Traditional way of working• How the project was documented... © 2012 Tieto Corporation 20
  21. 21. Traditional way of working• What was installed... © 2012 Tieto Corporation 21
  22. 22. Traditional way of working• What was charged to customer … © 2012 Tieto Corporation 22
  23. 23. Traditional way of working• How the product was supported... © 2012 Tieto Corporation 23
  24. 24. Traditional way of working• Finally, what the customer really needed... © 2012 Tieto Corporation 24
  25. 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. 26. Agile It’s NOT about getting FASTER Its NOT about way to get project QUICKER Its about to know HOW SCREWED YOU ARE EARLY ENOUGH26 © 2012 Tieto Corporation
  27. 27. Scrum http://www.epfwiki.net/wikis/scrum © 2012 Tieto Corporation Page 27
  28. 28. Process vs. principles28 © 2012 Tieto Corporation
  29. 29. Let’s make it even more complicated Global Development© 2012 Tieto Corporation
  30. 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 Redbook2008-03-09 © 2012 Tieto Corporation Page 30
  31. 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 contracts31 © 2012 Tieto Corporation
  32. 32. Outsourcing communication specifics… © 2012 Tieto Corporation
  33. 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 improve33 © 2012 Tieto Corporation
  34. 34. © 2012 Tieto Corporation
  35. 35. Typical ramp-up risks Global delivery© 2012 Tieto Corporation
  36. 36. Experience report:Typical transfer project risks1. Unrealistic expectations2. Local inefficiencies get multiplied by distribution3. Poor transfer planning4. Too big, fast and insufficiently controlled change5. Lack of support and experience reuse6. Insufficient and ineffective knowledge transfer7. Poor team co-ordination8. Psychological factors neglected9. Sub-optimization © 2012 Tieto Corporation 2009-07- 31
  37. 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 Energi37 © 2012 Tieto Corporation
  38. 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. 39. Risk mitigation Global delivery© 2012 Tieto Corporation
  40. 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. 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. 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. 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 Ostrava43 © 2012 Tieto Corporation
  44. 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 risk44 © 2012 Tieto Corporation
  45. 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 change45 © 2012 Tieto Corporation
  46. 46. Practice: Iterative development +learning by doing Production scope Competence plan Separated originally Backlog + Delivery … Iteration 1 Iteration 246 © 2012 Tieto Corporation
  47. 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-optimization47 © 2012 Tieto Corporation
  48. 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#748 © 2012 Tieto Corporation
  49. 49. Measurements: Burn-down chart800700 Re-planning to avoid failure again 678.5 647 621600500400 339.5300 256.5 264.5 236.5 223.5 220.5200 193.5 147.5 115.5 112.5100 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. 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. 51. Typical transfer project risks andmitigation 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. 52. Summary: what have you learnt• Discuss and explain: • Transfer risks • Mitigation actions • Obstacles to adopt Agile in distributed environment52 © 2012 Tieto Corporation Global delivery
  53. 53. © 2012 Tieto Corporation Processes & Methods team Tieto, Processes & Quality te.rup@tieto.com

×