Scrum

442 views

Published on

Published in: Technology, Business
1 Comment
0 Likes
Statistics
Notes
  • very bakwas slide
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • Be the first to like this

No Downloads
Views
Total views
442
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
26
Comments
1
Likes
0
Embeds 0
No embeds

No notes for slide
  • Greet\nIntroduce Parking Lot\n\n
  • \n
  • \n
  • [Standisch 1994]Liste der Erfolgsfaktoren, die von der Standish Group durch Untersuchung von über 40.000 Projekten zwischen 1994-2002 zusammengetragen wurden.\n
  • \n
  • Body-Leasing Ansatz: Teams werden ad hoc zusammengestellt, ein Prozess wird vorgeschrieben und alles soll bestens funktionieren.\nTeamdynamische Aspekte werden vernachlässigt. \nDas Team ist aber mehr als die Summe der einzelnen Individuen. Es wird meistens nichts getan, um einen positiven Teamgeist zu fördern.\nDer Erfolg eines Projektes hing nicht von der angewendeten Methodologie ab. \nViel Projekte liefen aber auch ohne Verwendung einer explizit genannten Methodologie.\n
  • \n
  • Adapt - inspect\nMarket might change\nyou learn as you go\n
  • Adapt - inspect\nMarket might change\nyou learn as you go\n
  • Adapt - inspect\nMarket might change\nyou learn as you go\n
  • Adapt - inspect\nMarket might change\nyou learn as you go\n
  • Adapt - inspect\nMarket might change\nyou learn as you go\n
  • Adapt - inspect\nMarket might change\nyou learn as you go\n
  • Adapt - inspect\nMarket might change\nyou learn as you go\n
  • Adapt - inspect\nMarket might change\nyou learn as you go\n
  • Der wesentlichste Lösungsansatz\nAllerdings ....\n
  • Der wesentlichste Lösungsansatz\nAllerdings ....\n
  • Der wesentlichste Lösungsansatz\nAllerdings ....\n
  • Der wesentlichste Lösungsansatz\nAllerdings ....\n
  • Der wesentlichste Lösungsansatz\nAllerdings ....\n
  • Der wesentlichste Lösungsansatz\nAllerdings ....\n
  • Der wesentlichste Lösungsansatz\nAllerdings ....\n
  • Der wesentlichste Lösungsansatz\nAllerdings ....\n
  • Der wesentlichste Lösungsansatz\nAllerdings ....\n
  • Der wesentlichste Lösungsansatz\nAllerdings ....\n
  • Der wesentlichste Lösungsansatz\nAllerdings ....\n
  • Der wesentlichste Lösungsansatz\nAllerdings ....\n
  • man versucht Wissenschaftliche vorgehensweisen zu Adaptieren.\nHeute noch weit verbreitete Annahme das man den Erfolg von SW-Projekte durch klare Prozessvorgabe lösen kann. „Indistriuelle Fertigung am Fließband“ Ford / Tailorismus\nBspl. RUP ~20 Rollen; ~100 Artefakte\nHochgradige Spezialliesierung\nXY Spricht im Buch nie wieder Projekte von der grössten organisirerter Kriminalität\nProzesse wie Automobilindustrie \nSoftwareENTWICKLUNG\nSoftwareentwicklung vs Softwareproduktion. Was ist eine Entwicklungsabteilung in der Industrie\nEin oft vernachlässigter Faktor Änderungsmanagement im Entwicklungsprozess\nAuch wenn anforderungen klar formuliert sind ändern sie sich im laufe des Projektes \nDies wird oft dadurch forciert das der Anwender erst dann eine Vorstellung von dem System erhält wenn es sich beginnt abzuzeichnen.\nBig bang release at the end of the cycle\nGreat if you know exactly what you want and won’t change your mind\n
  • man versucht Wissenschaftliche vorgehensweisen zu Adaptieren.\nHeute noch weit verbreitete Annahme das man den Erfolg von SW-Projekte durch klare Prozessvorgabe lösen kann. „Indistriuelle Fertigung am Fließband“ Ford / Tailorismus\nBspl. RUP ~20 Rollen; ~100 Artefakte\nHochgradige Spezialliesierung\nXY Spricht im Buch nie wieder Projekte von der grössten organisirerter Kriminalität\nProzesse wie Automobilindustrie \nSoftwareENTWICKLUNG\nSoftwareentwicklung vs Softwareproduktion. Was ist eine Entwicklungsabteilung in der Industrie\nEin oft vernachlässigter Faktor Änderungsmanagement im Entwicklungsprozess\nAuch wenn anforderungen klar formuliert sind ändern sie sich im laufe des Projektes \nDies wird oft dadurch forciert das der Anwender erst dann eine Vorstellung von dem System erhält wenn es sich beginnt abzuzeichnen.\nBig bang release at the end of the cycle\nGreat if you know exactly what you want and won’t change your mind\n
  • man versucht Wissenschaftliche vorgehensweisen zu Adaptieren.\nHeute noch weit verbreitete Annahme das man den Erfolg von SW-Projekte durch klare Prozessvorgabe lösen kann. „Indistriuelle Fertigung am Fließband“ Ford / Tailorismus\nBspl. RUP ~20 Rollen; ~100 Artefakte\nHochgradige Spezialliesierung\nXY Spricht im Buch nie wieder Projekte von der grössten organisirerter Kriminalität\nProzesse wie Automobilindustrie \nSoftwareENTWICKLUNG\nSoftwareentwicklung vs Softwareproduktion. Was ist eine Entwicklungsabteilung in der Industrie\nEin oft vernachlässigter Faktor Änderungsmanagement im Entwicklungsprozess\nAuch wenn anforderungen klar formuliert sind ändern sie sich im laufe des Projektes \nDies wird oft dadurch forciert das der Anwender erst dann eine Vorstellung von dem System erhält wenn es sich beginnt abzuzeichnen.\nBig bang release at the end of the cycle\nGreat if you know exactly what you want and won’t change your mind\n
  • man versucht Wissenschaftliche vorgehensweisen zu Adaptieren.\nHeute noch weit verbreitete Annahme das man den Erfolg von SW-Projekte durch klare Prozessvorgabe lösen kann. „Indistriuelle Fertigung am Fließband“ Ford / Tailorismus\nBspl. RUP ~20 Rollen; ~100 Artefakte\nHochgradige Spezialliesierung\nXY Spricht im Buch nie wieder Projekte von der grössten organisirerter Kriminalität\nProzesse wie Automobilindustrie \nSoftwareENTWICKLUNG\nSoftwareentwicklung vs Softwareproduktion. Was ist eine Entwicklungsabteilung in der Industrie\nEin oft vernachlässigter Faktor Änderungsmanagement im Entwicklungsprozess\nAuch wenn anforderungen klar formuliert sind ändern sie sich im laufe des Projektes \nDies wird oft dadurch forciert das der Anwender erst dann eine Vorstellung von dem System erhält wenn es sich beginnt abzuzeichnen.\nBig bang release at the end of the cycle\nGreat if you know exactly what you want and won’t change your mind\n
  • man versucht Wissenschaftliche vorgehensweisen zu Adaptieren.\nHeute noch weit verbreitete Annahme das man den Erfolg von SW-Projekte durch klare Prozessvorgabe lösen kann. „Indistriuelle Fertigung am Fließband“ Ford / Tailorismus\nBspl. RUP ~20 Rollen; ~100 Artefakte\nHochgradige Spezialliesierung\nXY Spricht im Buch nie wieder Projekte von der grössten organisirerter Kriminalität\nProzesse wie Automobilindustrie \nSoftwareENTWICKLUNG\nSoftwareentwicklung vs Softwareproduktion. Was ist eine Entwicklungsabteilung in der Industrie\nEin oft vernachlässigter Faktor Änderungsmanagement im Entwicklungsprozess\nAuch wenn anforderungen klar formuliert sind ändern sie sich im laufe des Projektes \nDies wird oft dadurch forciert das der Anwender erst dann eine Vorstellung von dem System erhält wenn es sich beginnt abzuzeichnen.\nBig bang release at the end of the cycle\nGreat if you know exactly what you want and won’t change your mind\n
  • man versucht Wissenschaftliche vorgehensweisen zu Adaptieren.\nHeute noch weit verbreitete Annahme das man den Erfolg von SW-Projekte durch klare Prozessvorgabe lösen kann. „Indistriuelle Fertigung am Fließband“ Ford / Tailorismus\nBspl. RUP ~20 Rollen; ~100 Artefakte\nHochgradige Spezialliesierung\nXY Spricht im Buch nie wieder Projekte von der grössten organisirerter Kriminalität\nProzesse wie Automobilindustrie \nSoftwareENTWICKLUNG\nSoftwareentwicklung vs Softwareproduktion. Was ist eine Entwicklungsabteilung in der Industrie\nEin oft vernachlässigter Faktor Änderungsmanagement im Entwicklungsprozess\nAuch wenn anforderungen klar formuliert sind ändern sie sich im laufe des Projektes \nDies wird oft dadurch forciert das der Anwender erst dann eine Vorstellung von dem System erhält wenn es sich beginnt abzuzeichnen.\nBig bang release at the end of the cycle\nGreat if you know exactly what you want and won’t change your mind\n
  • man versucht Wissenschaftliche vorgehensweisen zu Adaptieren.\nHeute noch weit verbreitete Annahme das man den Erfolg von SW-Projekte durch klare Prozessvorgabe lösen kann. „Indistriuelle Fertigung am Fließband“ Ford / Tailorismus\nBspl. RUP ~20 Rollen; ~100 Artefakte\nHochgradige Spezialliesierung\nXY Spricht im Buch nie wieder Projekte von der grössten organisirerter Kriminalität\nProzesse wie Automobilindustrie \nSoftwareENTWICKLUNG\nSoftwareentwicklung vs Softwareproduktion. Was ist eine Entwicklungsabteilung in der Industrie\nEin oft vernachlässigter Faktor Änderungsmanagement im Entwicklungsprozess\nAuch wenn anforderungen klar formuliert sind ändern sie sich im laufe des Projektes \nDies wird oft dadurch forciert das der Anwender erst dann eine Vorstellung von dem System erhält wenn es sich beginnt abzuzeichnen.\nBig bang release at the end of the cycle\nGreat if you know exactly what you want and won’t change your mind\n
  • example of tradeengine\ngives visibility and control\n
  • other way to view iterative development - we aim for distributed spread accros QA and testing\nthis is what we are up to! - how do we get there? How to deal with the force dragging us down\nIt’s all about the right process, right?\n
  • other way to view iterative development - we aim for distributed spread accros QA and testing\nthis is what we are up to! - how do we get there? How to deal with the force dragging us down\nIt’s all about the right process, right?\n
  • other way to view iterative development - we aim for distributed spread accros QA and testing\nthis is what we are up to! - how do we get there? How to deal with the force dragging us down\nIt’s all about the right process, right?\n
  • other way to view iterative development - we aim for distributed spread accros QA and testing\nthis is what we are up to! - how do we get there? How to deal with the force dragging us down\nIt’s all about the right process, right?\n
  • other way to view iterative development - we aim for distributed spread accros QA and testing\nthis is what we are up to! - how do we get there? How to deal with the force dragging us down\nIt’s all about the right process, right?\n
  • other way to view iterative development - we aim for distributed spread accros QA and testing\nthis is what we are up to! - how do we get there? How to deal with the force dragging us down\nIt’s all about the right process, right?\n
  • \n
  • Hierbei wurden \nProjekte in der Größenordnung von 5 Mio. DEM \nbei Unternehmen in der Größenordnung mit 1 Mrd. DEM Umsatz pro Jahr untersucht\nMan beachte die hohe Projektsterblichkeit von fast einem Drittel!!!!\n[Stanlisch 1994]\n
  • Software-Entwicklung kann man auffassen als das Erreichen einer Kompromisslösung (ein lokales Optimum) angesichts sich scheinbar widersprechender Ansprüche\nIn jeden Projekt bewegen wir uns daher in einem Spannungsfeld, das hier modellhaft abgebildet ist\nAlle Variablen sind voneinander abhängig – Die Änderung einer Variable beinflusst die andern\nVeranschaulichung durch Gummibänder (für Physiker: nicht wirklich Gummiband, nicht-lineare Rückstellkräfte etc.)\nFrage ans Publikum: Was machen Projektleiter normalerweise, wenn sie feststellen, dass ein Projekt kritisch wird?\nWelche Kontrollvariablen ändern sie?\n
  • Software-Entwicklung kann man auffassen als das Erreichen einer Kompromisslösung (ein lokales Optimum) angesichts sich scheinbar widersprechender Ansprüche\nIn jeden Projekt bewegen wir uns daher in einem Spannungsfeld, das hier modellhaft abgebildet ist\nAlle Variablen sind voneinander abhängig – Die Änderung einer Variable beinflusst die andern\nVeranschaulichung durch Gummibänder (für Physiker: nicht wirklich Gummiband, nicht-lineare Rückstellkräfte etc.)\nFrage ans Publikum: Was machen Projektleiter normalerweise, wenn sie feststellen, dass ein Projekt kritisch wird?\nWelche Kontrollvariablen ändern sie?\n
  • Software-Entwicklung kann man auffassen als das Erreichen einer Kompromisslösung (ein lokales Optimum) angesichts sich scheinbar widersprechender Ansprüche\nIn jeden Projekt bewegen wir uns daher in einem Spannungsfeld, das hier modellhaft abgebildet ist\nAlle Variablen sind voneinander abhängig – Die Änderung einer Variable beinflusst die andern\nVeranschaulichung durch Gummibänder (für Physiker: nicht wirklich Gummiband, nicht-lineare Rückstellkräfte etc.)\nFrage ans Publikum: Was machen Projektleiter normalerweise, wenn sie feststellen, dass ein Projekt kritisch wird?\nWelche Kontrollvariablen ändern sie?\n
  • Software-Entwicklung kann man auffassen als das Erreichen einer Kompromisslösung (ein lokales Optimum) angesichts sich scheinbar widersprechender Ansprüche\nIn jeden Projekt bewegen wir uns daher in einem Spannungsfeld, das hier modellhaft abgebildet ist\nAlle Variablen sind voneinander abhängig – Die Änderung einer Variable beinflusst die andern\nVeranschaulichung durch Gummibänder (für Physiker: nicht wirklich Gummiband, nicht-lineare Rückstellkräfte etc.)\nFrage ans Publikum: Was machen Projektleiter normalerweise, wenn sie feststellen, dass ein Projekt kritisch wird?\nWelche Kontrollvariablen ändern sie?\n
  • Software-Entwicklung kann man auffassen als das Erreichen einer Kompromisslösung (ein lokales Optimum) angesichts sich scheinbar widersprechender Ansprüche\nIn jeden Projekt bewegen wir uns daher in einem Spannungsfeld, das hier modellhaft abgebildet ist\nAlle Variablen sind voneinander abhängig – Die Änderung einer Variable beinflusst die andern\nVeranschaulichung durch Gummibänder (für Physiker: nicht wirklich Gummiband, nicht-lineare Rückstellkräfte etc.)\nFrage ans Publikum: Was machen Projektleiter normalerweise, wenn sie feststellen, dass ein Projekt kritisch wird?\nWelche Kontrollvariablen ändern sie?\n
  • \n
  • Die Aufgabe des Projektmanager ist, für eine ausgewogene Balance der Projektvariablen zu sorgen.\nAls PM im Festpreisprojekt sind ein Teil der Variablen per Definition schon festgelegt.\nKosten und Zeit – Festpreis!? Budget!?\nMan kann nicht alles vorschreiben\nMacht deutlich gemacht das, das Management nicht alle Projektparameter bestimmen können\nEin Parameter muss dem Projektmanagement überlassen werden\nWo kein Spielraum ist gibt es auch nichts zu managen\nBestimmt das Management Budget, macht Zeitvorgaben und setzt die Funktionalität fest. Dann ist es an Ihnen Qualität zu definieren die sie unter den gegebenen Parameterwerten liefern können\nMacht das Management eine Zeitvorgabe, definiert die Qualität und setzt einen Kostenrahmen. Dann bestimmen Sie wieviel und welche Funktionalität umgesetzt wird\nIn Zukunft nicht unwohl fühlen. Legen Sie den Finger in die Wunde und machen Sie dem Managment klar das das nicht alles vorgeschrieben werden kann.\nAlso ...\n
  • Aufblähen des Inhalts/Umfangs (a.k.a. „Featuritis“) \nSie sehen, daß dadurch mehr Zeit benötigt wird, daß die Qualität sinkt und die Kosten steigen.\n
  • \n
  • Also ... bleibt nur der Scope\nGrundvorraussetzung ist das die Variation des Umpfangs gemeinsam mit dem Kunden erfolgt\nEin weiters Kernproblem der SE ... \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • User Stories\nChoose highest ROI\nTeam Plans and commits to sprint\nTeam is left alone\nDelivers after 3 weeks\nManaged by Scope - a story might drop out\n
  • \n
  • \n
  • \n
  • \n
  • \n
  • When we say an Agile team is self-organizing, we mean that a group of peers has assembled for the purpose of bringing a software development project to completion. The team members share a goal and a common belief that their work is interdependent and collaboration is the best way to accomplish their goal. \nEmpowered team members’ reduce their dependency on management as they accept accountability, and the team structure places ownership and control close to the core of the work. Rather than having a manager with responsibility for planning, managing and controlling the work, the team members share increasing responsibility for managing their own work and also share responsibility for problem-solving and continuous improvement of their work processes.\n\n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • - problems arise. the focus is on what we can learn from what happened\n- they are free flowing brainstorm on opportunities and ways to resolve them\n\n
  • \n
  • complementary and good synergy\nbest of two worlds - management and engineering\nWho is using XP or Scrum?\nexplain both of them would be a talk itself - you got some summary I just give a brief intro\n
  • \n
  • \n
  • Simple rules lead to intelligent behavior, Complex rules lead to stupid behavior\nJim Highsmith\n
  • \n
  • Scrum

    1. 1. SCRUM Workshop May 2009Presented by Manfred.Friedrich@AdScale.deMay 5th, 2009
    2. 2. Scrum Overview 2
    3. 3. Workshop ObjectionsBy the end of the workshop you will:• Have a clear understanding of Scrum• Know how to apply Scrum to our projectwww.adscale.de 3
    4. 4. 3/4 SW Projects Fail• Uncertainty Principle of SE• Did not understand requirement• No change management procedure• Problems or failures occur to late• Budget has been dropped• Unreliable integration and release cycles [ct 2001][Standisch Group1994-2002] Based on 40.000 projects between 1994-2002 www.adscale.de 4
    5. 5. Common Examples of Uncertainty and ChangeUncertainty• I won’t know if it’s right until I see it• I don’t know what will go wrong• We don’t know what the competition will do• We don’t know what the customer will likeChange• I just had a great new idea• The customer just changed his mind• The competition just changed his mind• Our CEO just changed his mindwww.adscale.de 5
    6. 6. Common Project Management Myths • One Process guaranties success • One process is never the problem of bad interaction, it optimizes interaction • People grow together as a good team by them self • People are interchangeable „Plug Compatible Units“ • We did not archive our goals -> lets go and get a better “heavy weigh” processwww.adscale.de 6
    7. 7. A Defined Process Muffin Mix Yummy Muffinswww.adscale.de 7
    8. 8. Following a Planwww.adscale.de 8
    9. 9. Following a Plan A – Start B – Planned Resultwww.adscale.de 8
    10. 10. Following a Plan A – Start B – Planned Result C – Guided Resultwww.adscale.de 8
    11. 11. Following a Plan „...following a plan p roduces the product just not the product y you intended, ou need“ Jim Highsmith [Hig 20 00] A – Start B – Planned Result C – Guided Result ered eede d & what we deliv “what th ey thought they n ey w ere 100% satisfie d were complete ly different, but th ” with what we deliveredwww.adscale.de 8
    12. 12. Planned Iterative ...www.adscale.de 9
    13. 13. Planned Iterative ...www.adscale.de 9
    14. 14. Planned Iterative ...www.adscale.de 9
    15. 15. Planned Iterative ... Requirements Analysiswww.adscale.de 9
    16. 16. Planned Iterative ... Requirements Analysis Designwww.adscale.de 9
    17. 17. Planned Iterative ... Requirements Analysis Coding, Unit Testing Designwww.adscale.de 9
    18. 18. Planned Iterative ... Integration, Test Requirements Analysis Coding, Unit Testing Designwww.adscale.de 9
    19. 19. Planned Iterative ... Integration, Test Requirements Analysis Coding, Unit Testing Designwww.adscale.de 9
    20. 20. Planned Iterative ... Integration, Test Requirements Analysis Coding, Unit Testing Designwww.adscale.de 9
    21. 21. Planned Iterative ... Integration, Test Requirements Analysis Coding, Unit Testing Designwww.adscale.de 9
    22. 22. Planned Iterative ... Integration, Test Requirements Analysis Coding, Unit Testing Designwww.adscale.de 9
    23. 23. Planned Iterative ... Integration, Test Requirements Analysis Coding, Unit Testing Designwww.adscale.de 9
    24. 24. Planned Iterative ... uct P rod 0 . V. 1 Integration, Test Requirements Analysis Coding, Unit Testing Designwww.adscale.de 9
    25. 25. ... but degenerate to waterfallwww.adscale.de 10
    26. 26. ... but degenerate to waterfall A A A A D D D D C C C C T T T Twww.adscale.de 10
    27. 27. ... but degenerate to waterfall A A A A D D D D C C C C T T T T A D C Twww.adscale.de 10
    28. 28. ... but degenerate to waterfall A A A A D D D D C C C C T T T T A t se a ng relea cycle D Bi g ba of the d th e en C Twww.adscale.de 10
    29. 29. ... but degenerate to waterfall A A A A D D D D C C C C T T T T A t se a ng relea cycle D Bi g ba of the d th e en C Twww.adscale.de 10
    30. 30. ... but degenerate to waterfall A A A A D D D D C C C C T T T T A t se a ng relea cycle D Bi g ba of the d th e en C Twww.adscale.de 10
    31. 31. ... but degenerate to waterfall A A A A D D D D C C C C T T T T A D C Twww.adscale.de 10
    32. 32. ... but degenerate to waterfall A A A A D D D D C C C C T T T T ? ? ? ? A D C Twww.adscale.de 10
    33. 33. Iterative Development Visibility & Adaptability All-at-once Development Timewww.adscale.de 11
    34. 34. Iterative Development Iterative Development Visibility & Adaptability All-at-once Development Timewww.adscale.de 11
    35. 35. Development CycleScope Classic Iterative Test Code Design Analyse Time www.adscale.de 12
    36. 36. Development CycleScope Classic Iterative Test Code Design Analyse Time www.adscale.de 12
    37. 37. Development CycleScope Agile Cycles Test Code Design Analyse Time www.adscale.de 12
    38. 38. Timeboxing Requirements Requirements Design Coding Unit Integration, Analysis Analysis Testing Test Project Management Quality Management Systematische Test - Acceptance / Validierung Verifikation Testobjekte/ Regression Regressions - Other QA Vollständigkeit Integration Tests Load Test Testfälle durchführung Tests Tests Tasks test der Struktur Short iterations of 1-4 weeks; Incremental releaseswww.adscale.de 13
    39. 39. Control Variables are crucial• 61,5% of all finished projects were out of time, cost, scope and quality• 29,5% of all projects have been cancelled• 9% of all projects have been finished within the project boundaries.www.adscale.de 14
    40. 40. Project Dimensionswww.adscale.de 15
    41. 41. Project Dimensionswww.adscale.de 15
    42. 42. Project Dimensionswww.adscale.de 15
    43. 43. Project Dimensionswww.adscale.de 15
    44. 44. Project Dimensionswww.adscale.de 15
    45. 45. Project Dimensionswww.adscale.de 15
    46. 46. Influencewww.adscale.de 16
    47. 47. Top Scope, Top Quality but crappie time and costwww.adscale.de 17
    48. 48. Management by Qualitywww.adscale.de 18
    49. 49. Management by Qualitywww.adscale.de 18
    50. 50. Quality is the Top PriorityIf it didn’t have to work, you could build it pretty quickly.It is always fastest to do the job right the first time.Rework and repair is wasteful.The sooner you fix it the better.Focus on quality from the beginning of the job.Quality without numbers is just talk. www.adscale.de 19
    51. 51. Management by Scopewww.adscale.de 20
    52. 52. Empirical Processes “It is typical to adopt the defined (theoretical) modeling approach when the underlying mechanisms by which a process operates are reasonably well understood. When the process is too complicated for the defined approach, the empirical approach is the appropriate choice.” [Process Dynamics, Modeling, and Control, Ogunnaike and Ray, Oxford University Press, 1992)] Abstract: Inspect and Adaptwww.adscale.de 21
    53. 53. Agile 22
    54. 54. Agile Agile is a great buzzword. Who doesn’t want to be Agile? No one says, “Thanks, I’d rather be inflexible and slow to respond.”www.adscale.de 23
    55. 55. Agile• Umbrella of different frameworks and practices driven by common values• The most popular are Scrum, XP and Leanwww.adscale.de 24
    56. 56. The Agile Manifesto individuals and over Process and Tools interaction Working over Comprehensive Software documentation Customer over Contract Collaboration negotiation Responding to over Following a Plan Change While we value the items on the right, we value the items on the left more.www.adscale.de 25
    57. 57. Agile Values• Communication• Simplicity• Feedback• Courage• Respectwww.adscale.de 26
    58. 58. Agile Myths• No Design• No Planning• No Documentation• Poor Quality• “Hacking” Code• Only Works on Small Projectswww.adscale.de 27
    59. 59. Agile Myths• No Design• No Planning• No Documentation• Poor Quality• “Hacking” Code• Only Works on Small Projectswww.adscale.de 27
    60. 60. Scrum 28
    61. 61. Scrum is NOTwww.adscale.de 29
    62. 62. What is Scrum A flexible framework that is: • Collaborative • Iterative & Incremental • Very simple but very hard; it causes changewww.adscale.de 30
    63. 63. Origins The New, New Lean Iterative, Incremental Product Development Development, Game* Timeboxes Smalltalk Engineering Tools Scrum (Schwaber & Sutherland 1993)*Harvad Business Review, Jan.1986, Takeuchi and Nonaka www.adscale.de 31
    64. 64. “The problem we face has nothing to do with processand technology, but with people.Scrum and Agile are based on the hypothesis that thereis no meta-solution for software development. Just aframework within which we will be empirical –inspectand adapt.This is very frustrating for those looking for proceduresand final answers.” - Ken Schwaber -www.adscale.de 32
    65. 65. Scrum Processwww.adscale.de 33
    66. 66. Module: Roles Product Sprint Sprint Daily Sprint SprintRoles Backlog Planning Tracking Scrum Review Retro 34
    67. 67. Scrum Roles Product Owner Scrum Master Scrum Teamwww.adscale.de 35
    68. 68. Role: Product Owner• Defines the features of the product,• decides on release date and content• Is responsible for the profitability of the product (ROI)• Prioritises features according to market value• Can change features and priority every 30 days• Accepts or rejects work resultswww.adscale.de 36
    69. 69. Role: Scrum Master• Ensures that the team is fully functional and productive• Enables close cooperation across all roles and functions and removes barriers• Shields the team from external interferences• Ensures that the process is followed.• Invites to daily scrum, iteration review and planning meetingswww.adscale.de 37
    70. 70. Role: Scrum Team• Cross-functional, seven plus/minus two members• Selects the iteration goal and specifies work results• Has the right to do everything• within the boundaries of the project• guidelines to reach the iteration goal• Organizes itself and its work• Demonstrates work results to the Product Ownerwww.adscale.de 38
    71. 71. A Self-Organizing Team...• is group of peers assembled for the purpose of bringing a software development project to completion• shares a goal• shares belief that their work is interdependent => therefore collaboration is the best way to accomplish goal• reduces their dependency on management through empowerment• accepts accountability• takes ownership and controls close to the core of their work• shares responsibility for managing their own work• shares responsibility for problem-solving and continuous improvement of their work processeswww.adscale.de 39
    72. 72. Self-Organizing Team• When we say an Agile team is self-organizing, we mean that a group of peers has assembled for the purpose of bringing a software development project to completion. The team members share a goal and a common belief that their work is interdependent and collaboration is the best way to accomplish their goal.• Empowered team members’ reduce their dependency on management as they accept accountability, and the team structure places ownership and control close to the core of the work. Rather than having a manager with responsibility for planning, managing and controlling the work, the team members share increasing responsibility for managing their own work and also share responsibility for problem-solving and continuous improvement of their work processes.•www.adscale.de 40
    73. 73. self-organizingThe team collectively selects requirements from a prioritized list, selecting only asmuch as it believes it can turn into an increment of working product functionalityduring the next Sprint. The only constraints on the team are any existingorganizational standards, conventions, and previously constructed productfunctionality. The team commits to management that it will turn these requirementsinto working product functionality by the end of the Sprint. The team is the left aloneto do so for the duration of the Sprint. Left alone! No one to tell the team what todo? No methodology to tell the team how to transform the requirements intofunctionality? No one to blame if the team fails? No one to grab the glory if the teamsucceeds? That’s right, left alone. It is solely and utterly the team’s responsibility tofigure out what to do, and to do it. The old saying, Be careful what you ask for,because you might get it! describes the dilemma and opportunity of the team. In myexperience, every team is at first shocked by this responsibility. However, as theteam realizes that it has the full authority to do whatever it deems necessary, asense of liberation and empowerment (that usually trite phrase) occurs. The teamstarts talking, drawing designs on whiteboards, figuring of what work needs to bedone. People start defining what work they’ll do, and what help they need to do it.Some people ask to do work that they’ve always wanted to learn, signing up forother additional work to offset their learning curve. The team collectively simmers,brainstorms, and works to meet its commitment. The team self-organizes. -- JeffSutherlandwww.adscale.de 41
    74. 74. Scrum Team Metaphor A scrum is a team of eight individuals in Rugby.Everyone in the pack acts together with everyone else to move the ball down the field. For those who know rugby, the image is clear. Teams work as tight, integrated units with each team member playing a well-defined role and the whole team focusing on a single goal. In development teams, each teammember must understand his or her role and the tasks for each increment. The entire team must have a single focus. The priorities must be clear. As we now describe, the Scrum development process facilitates this team focus.www.adscale.de 42
    75. 75. Software development is a cooperative game „Software development is a (series of) cooperative game(s), in which people use markers and props to inform, remind and inspire themselves and each other in getting to the next move in the game. The endpoint of the game is an operating software system; the residue of the game is a set of markers to inform and assist the players of the next game. The next game is the alteration or replacement of the system, or creation of a neighboring system." ---Alistair Cockburnwww.adscale.de 43
    76. 76. Module: Product Backlog Product Sprint Sprint Daily Sprint SprintRoles Backlog Planning Tracking Scrum Review Retro 44
    77. 77. Product Backlog • List of functionality, technology, issues • Issues are placeholders that are later defined as work • More detail on higher priority backlog • Product Owner responsible for priority • Anyone can contributeThis is the Product Backlog • Maintained and posted visibly • Derived from Business Plan or Vision Statement, which sometimes have to be created with customer 45www.adscale.de
    78. 78. Planning Product Vision Roadmap Release Plan Sprint Plan Daily Planwww.adscale.de 46
    79. 79. Estimation over Time Roadmap Product Back-Log Sprint Back-Log Sprint Plan Implementedwww.adscale.de 47
    80. 80. Module: Sprint Planning Product Sprint Sprint Daily Sprint SprintRoles Backlog Planning Tracking Scrum Review Retro 48
    81. 81. User Stories• A short description of the behavior of the system from the point of view of the Customer• Use the Customer’s terminology without technical jargon• One for each major feature in the system• Must be written by the users• Are used to create time estimates for release planning• Replace a large Requirements Documentwww.adscale.de 49
    82. 82. Sample User Story Create new Customer As an Supporter I want to be able to create an new Customer-Account Acceptance Criteria: + EMail address valid and Unique + User Name Uniquewww.adscale.de 50
    83. 83. User Story as Automated Testwww.adscale.de 51
    84. 84. Sprint Planning • Team plans out what they will commit to delivering for the next Sprint • Team creates tasks, estimates, and volunteers for them This is the Sprint Planning Meetingwww.adscale.de 52
    85. 85. Sprint Planning - Step 1 1 As a Guest, I can add one photo to my profile 2 As a premium member I can add up to ten photos to my profile page Product owner and team 3 As a premium member, I can add video to my profile page 4 As a Guest, I can add one photo to my profile discuss the latest 5 As a User I can add photos to my profile page product backlog and the 6 As a user I can create a profile to display goals of the Sprint information about myself 7 As a User I can add people I like to a “hot list”www.adscale.de 53
    86. 86. Sprint Planning - Step 2 The team works out their collective hours available for the Sprint Name Base Less Less Less Total Hours Holidays Vacation Other Anne 6h 1d --- --- 54h Warwick 3h 1d --- --- 30h Tom 5h 1d 2d --- 42h Ben 8h 1d --- --- 52hwww.adscale.de 54
    87. 87. Sprint Planning - Step 3 • Team breaks Product Backlog items into tasks • Each Task is estimated (Done! incl. Test ) Task: Configure Database (7h @ Scott) • Each Task has a volunteerwww.adscale.de 55
    88. 88. Sprint Backlog • Before each Sprint, the highest prioritised goals are transferred to a Sprint Backlog. • List of tasks to turn product backlog into working product • Tasks are estimated in hours • Tasks >1day are broken down later • Team members sign up for tasks, they aren’t assigned Sprint Backlog • Estimate work remaining is updated dailywww.adscale.de 56
    89. 89. Sprint A time-boxed iteration During the Sprint: • Analysis • Design • Coding Sprint • Testwww.adscale.de 57
    90. 90. No Changes During Sprint• No Changes to Deliverables • Once team has committed, no changes • Details will emerge during Sprint, but no work or substantionally changed work• No Changes to Sprint Duration • Sprint ends on planned date whether team has comleted all its commitment or notwww.adscale.de 58
    91. 91. Module: Sprint Tracking Product Sprint Sprint Daily Sprint SprintRoles Backlog Planning Tracking Scrum Review Retro 59
    92. 92. Tracking Progress• Scrum tracks the work remaining.• Does not track actual time worked Updated dailywww.adscale.de 60
    93. 93. Scrum Task Boardwww.adscale.de 61
    94. 94. Task List Updated Daily Hours of work Remaining on Each Day of the Sprint Task Task Day Day Day Day Day Day Day Day Day Day Owner 01 02 03 04 05 06 07 08 09 10 Use test data to tune the impression handler Warwick 4 3 6 1 0 0 Set-up Teracotta Server Ben 2 1 1 1 1 0 Implement pre-login handler Amanda 6 3 3 2 2 1 Merge RB branch Jason 8 5 4 2 2 2 Rework login page - use email Joost 4 4 3 2 3 3 Configure Database and Stored Procedures Markus 2 2 0 0 0 0 Total 26 18 17 8 8 6www.adscale.de 62
    95. 95. Burndown Chart Where the team is now Steady pacewww.adscale.de 63
    96. 96. Module: Daily Scrum Product Sprint Sprint Daily Sprint SprintRoles Backlog Planning Tracking Scrum Review Retro 64
    97. 97. Daily Scrum Daily Scrum ~ 15 minute meeting: • What I did yesterday • What I plan on doing today • What is blocking mewww.adscale.de 65
    98. 98. Standup Meeting Why get a sense of the trouble spots identify who might be able to help communication surprises to exploit or prepare for make sure you are starting the day right What What did you do yesterday that might affect others? What progress did you make yesterday? What do you plan to do today?www.adscale.de 66
    99. 99. Daily Scrum• Scrum Master facilitates Stand-Up• Side conversations are put on the parking lot• Blocks and issues are identified, and action plans are created• Follow-up on resolutionswww.adscale.de 67
    100. 100. A Standup Meeting is a Starters Gun The standup meeting is a practice borrowed from the Scrum process. The team stands, and each person briefly reports what they did yesterday, what they plan to do today, and whats in their way. Well, 25 years, and 50 kilograms ago, I ran track. Before a race, the runners do a little warmup running and a few practice starts, but theyre not starting to race yet. When its time, the starter says, "On your mark, get set, go!" and everybody starts running full speed, at the same time and in the same direction. A morning standup meeting feels like that to me. Without a meeting, people trickle in; some people hear things and others dont. With a standup meeting, we get everybody together at the same time, pointed in the same direction, and the days race begins in earnest. -- [William C. Wake 2002]www.adscale.de 68
    101. 101. Module: Sprint Review Product Sprint Sprint Daily Sprint SprintRoles Backlog Planning Tracking Scrum Review Retro 69
    102. 102. Sprint Review This is the Sprint reviewwww.adscale.de 70
    103. 103. Sprint Review A demo by the team of: • Complete • Fully tested • Potentially shippable features • High quality This is the Sprint review • Tested • “Done”!www.adscale.de 70
    104. 104. Module: Sprint Retrospective Product Sprint Sprint Daily Sprint SprintRoles Backlog Planning Tracking Scrum Review Retro 71
    105. 105. Sprint Retrospective A meeting at the end of each Sprint so the Team can Inspect and Adapt the processwww.adscale.de 72
    106. 106. Sprint RetrospectiveTopics covered are:•What progress did the team make during the Sprint•What worked well during the sprint, and the team should continue doing•What improvements can the team make for things that didn’t work so wellwww.adscale.de 73
    107. 107. Sprint Retrospective• Capture all input• Aim for 1-3 improvements for next Sprint• Review past retrospectives, to see how team is doing.www.adscale.de 74
    108. 108. What a Retrospective is NOT• Retrospectives are NOT about blame• Retrospectives are NOT a witch hunt• Retrospectives are NOT about gathering specific informationwww.adscale.de 75
    109. 109. Our Process ...... not just SCRUM 76
    110. 110. Scrum with XP complementary practices and rules Scrum XP Management Practices Engineering Practices Product Backlog Simple system design Sprint Backlog Test-Driven-Development Sprint Continuous integration Burn Down Re-factoring Daily Scrum Pair programming Sprint Retrospective Collective Code Ownership overlap at the planning game (XP) and sprint planning (Scrum)www.adscale.de
    111. 111. Scrum  Product development methodology consisting of practices and rules to be used by management, customers, and project management  Maximize productivity and value of a development effort.  Takes the responsibility for development projects out of engineering and IT and puts them squarely back in the business.  Businesses own and manage projects rather than "tossing them over the wall" to IT and hoping for the best.  Reintroduces accountability for IT projects to the business, requiring the business to maximize the ROI, without excuses.  NO engineering practices. When engineering practices are weak, overall productivity is lessened.www.adscale.de
    112. 112. eXtreme Programming  eXtreme Programming (XP) is an engineering methodology consisting of practices that ensure top- quality, focused code.  It builds up to a dozen practices, weaving them into a synergistic whole in which each one is reinforced by the others  Teams that use XP practices are adhering to strong engineering disciplines. Like guilds, the teams that follow these practices generate good products.  NO management practices. XP tells management where it needs them, but offers few insights into maximizing value.www.adscale.de
    113. 113. SW Development RulesPlanning CodingUser stories are written The customer is always availableProject is divided into Sprints Code must be written to agreed standardsSprint planning creates the schedule Code the unit test firstSprint planning starts each SprintMake frequent small releases All production code is pair programmedProject-velocity is measured Integrate oftenMove people around Use collective code ownershipStand-up meeting starts each day Leave optimization till lastFix ASP when it breaks No overtimeDesigning TestingSimplicity (Innovative but Sufficient to Purpose) Follow TDD principalsChoose a system metaphor All code must have unit testsCreate spike solutions to reduce risk All code must pass all unit tests before it can beNo functionality is added early releasedRe-factor whenever and wherever possible When a bug is found tests are created first Acceptance tests are run often and the score is published www.adscale.de 80
    114. 114. Discussion What are your challenges? How can we learn from and support each other?www.adscale.de 81

    ×