Presentation jag höll på DevLin 2011 om hur det är att gå över från att utveckla objekt- (klass)orienterat till att utveckla i funktionella språk exemplifierat med erlang.
Agile och Kanban på driftavdelningen - Tomas Bjorkholmmanssandstrom
The document discusses using Kanban principles for operations teams. It describes some key characteristics of Kanban including limiting work in progress, visualizing workflow, and focusing on continuously improving lead time. Various examples of Kanban boards are provided, including ones tailored for non-cross functional teams and for breaking work into smaller stories less than one week. The Kanban process involves daily stand-ups, sprint planning and retrospectives to continuously improve.
Presentation jag höll på DevLin 2011 om hur det är att gå över från att utveckla objekt- (klass)orienterat till att utveckla i funktionella språk exemplifierat med erlang.
Agile och Kanban på driftavdelningen - Tomas Bjorkholmmanssandstrom
The document discusses using Kanban principles for operations teams. It describes some key characteristics of Kanban including limiting work in progress, visualizing workflow, and focusing on continuously improving lead time. Various examples of Kanban boards are provided, including ones tailored for non-cross functional teams and for breaking work into smaller stories less than one week. The Kanban process involves daily stand-ups, sprint planning and retrospectives to continuously improve.
Att lyckas med integration av arbetet från flera scrum team - Christophe Acho...manssandstrom
This document discusses strategies for integrating work from multiple Scrum teams. It outlines the role of an integration team in continuously integrating work. Key success factors for the integration team include: integrating work early, having the necessary resources and environments, practicing continuous integration, using automated tests, maintaining at least two test environments, performing early performance tests, stopping work if integration breaks, having a clear contract between development and integration teams, making the integration process and status visible.
The document discusses principles for agile software development and releasing software in a continuous manner. It outlines five steps to achieve this: 1) Learn how to plan in small iterations, 2) Organize delivery to keep focus and avoid issues, 3) Automate everything for traceability, 4) Test everything continuously, and 5) Always integrate code to ensure releases are always releasable. The goal is to release software early and often through a process of timeboxed iterations, continuous integration, and automated testing.
Att lyckas med integration av arbetet från flera scrum team - Christophe Acho...manssandstrom
This document discusses strategies for integrating work from multiple Scrum teams. It outlines the role of an integration team in continuously integrating work. Key success factors for the integration team include: integrating work early, having the necessary resources and environments, practicing continuous integration, using automated tests, maintaining at least two test environments, performing early performance tests, stopping work if integration breaks, having a clear contract between development and integration teams, making the integration process and status visible.
The document discusses principles for agile software development and releasing software in a continuous manner. It outlines five steps to achieve this: 1) Learn how to plan in small iterations, 2) Organize delivery to keep focus and avoid issues, 3) Automate everything for traceability, 4) Test everything continuously, and 5) Always integrate code to ensure releases are always releasable. The goal is to release software early and often through a process of timeboxed iterations, continuous integration, and automated testing.
Det jag vill ha sagt: Låt ditt angreppssätt variera, se till att mäta effekterna av variationen och välj sedan en ny punkt från vilken du varierar. Detta är evolution på jobbet.
När man pratar om evolution kan man inte utelämna en person
På så vis förklarade han hur livet på jorden antagit så många former.
Jag fick idén till det här talet när jag på ett möte hörde någon reflektera över något bra som en grupp hade gjort genom att säga: “Har vi skrivit ner det här så att vi vet hur vi ska göra nästa gång?”
Det verkar som att vi helst skulle se att allt vi gör kan upprepas - samma resultat på samma tid. Framtiden är tillräckigt osäker som det är.
Vi gör ett initialt val som lägger band på variationen.
Det är det som gör att vi standardiserar organisationers val, Oracles databas, RUP, Java och nu Scrum.
Jag har själv blivit ombedd att dokumentera exakt hur utvecklingsarbetet går till i Scrum så att alla kan göra på samma sätt.
Det är det som gör att vi standardiserar organisationers val, Oracles databas, RUP, Java och nu Scrum.
Jag har själv blivit ombedd att dokumentera exakt hur utvecklingsarbetet går till i Scrum så att alla kan göra på samma sätt.
Det är det som gör att vi standardiserar organisationers val, Oracles databas, RUP, Java och nu Scrum.
Jag har själv blivit ombedd att dokumentera exakt hur utvecklingsarbetet går till i Scrum så att alla kan göra på samma sätt.
Det är det som gör att vi standardiserar organisationers val, Oracles databas, RUP, Java och nu Scrum.
Jag har själv blivit ombedd att dokumentera exakt hur utvecklingsarbetet går till i Scrum så att alla kan göra på samma sätt.
Det är det som gör att vi standardiserar organisationers val, Oracles databas, RUP, Java och nu Scrum.
Jag har själv blivit ombedd att dokumentera exakt hur utvecklingsarbetet går till i Scrum så att alla kan göra på samma sätt.
Det är det som gör att vi standardiserar organisationers val, Oracles databas, RUP, Java och nu Scrum.
Jag har själv blivit ombedd att dokumentera exakt hur utvecklingsarbetet går till i Scrum så att alla kan göra på samma sätt.
Det är det som gör att vi standardiserar organisationers val, Oracles databas, RUP, Java och nu Scrum.
Jag har själv blivit ombedd att dokumentera exakt hur utvecklingsarbetet går till i Scrum så att alla kan göra på samma sätt.
Vad händer om vi inte är så rädda för variation? Vi kan införa avsiktlig variation.
Uppmuntra folk att variera sig. Mike Cohn tvingar sina utvecklingsteam att variera sig för att de ska lära sig maximalt. Utan den här typen av variation skulle aldrig företeelser som Planning Poker, Pomodoro Technique, Beyond Budgeting uppstå.
Uppmuntra folk att variera sig. Mike Cohn tvingar sina utvecklingsteam att variera sig för att de ska lära sig maximalt. Utan den här typen av variation skulle aldrig företeelser som Planning Poker, Pomodoro Technique, Beyond Budgeting uppstå.
Uppmuntra folk att variera sig. Mike Cohn tvingar sina utvecklingsteam att variera sig för att de ska lära sig maximalt. Utan den här typen av variation skulle aldrig företeelser som Planning Poker, Pomodoro Technique, Beyond Budgeting uppstå.
Uppmuntra folk att variera sig. Mike Cohn tvingar sina utvecklingsteam att variera sig för att de ska lära sig maximalt. Utan den här typen av variation skulle aldrig företeelser som Planning Poker, Pomodoro Technique, Beyond Budgeting uppstå.
Uppmuntra folk att variera sig. Mike Cohn tvingar sina utvecklingsteam att variera sig för att de ska lära sig maximalt. Utan den här typen av variation skulle aldrig företeelser som Planning Poker, Pomodoro Technique, Beyond Budgeting uppstå.
Uppmuntra folk att variera sig. Mike Cohn tvingar sina utvecklingsteam att variera sig för att de ska lära sig maximalt. Utan den här typen av variation skulle aldrig företeelser som Planning Poker, Pomodoro Technique, Beyond Budgeting uppstå.
Uppmuntra folk att variera sig. Mike Cohn tvingar sina utvecklingsteam att variera sig för att de ska lära sig maximalt. Utan den här typen av variation skulle aldrig företeelser som Planning Poker, Pomodoro Technique, Beyond Budgeting uppstå.
Uppmuntra folk att variera sig. Mike Cohn tvingar sina utvecklingsteam att variera sig för att de ska lära sig maximalt. Utan den här typen av variation skulle aldrig företeelser som Planning Poker, Pomodoro Technique, Beyond Budgeting uppstå.
Uppmuntra folk att variera sig. Mike Cohn tvingar sina utvecklingsteam att variera sig för att de ska lära sig maximalt. Utan den här typen av variation skulle aldrig företeelser som Planning Poker, Pomodoro Technique, Beyond Budgeting uppstå.
Uppmuntra folk att variera sig. Mike Cohn tvingar sina utvecklingsteam att variera sig för att de ska lära sig maximalt. Utan den här typen av variation skulle aldrig företeelser som Planning Poker, Pomodoro Technique, Beyond Budgeting uppstå.
Uppmuntra folk att variera sig. Mike Cohn tvingar sina utvecklingsteam att variera sig för att de ska lära sig maximalt. Utan den här typen av variation skulle aldrig företeelser som Planning Poker, Pomodoro Technique, Beyond Budgeting uppstå.
Uppmuntra folk att variera sig. Mike Cohn tvingar sina utvecklingsteam att variera sig för att de ska lära sig maximalt. Utan den här typen av variation skulle aldrig företeelser som Planning Poker, Pomodoro Technique, Beyond Budgeting uppstå.
Men variation utan selektion är inte heller bra, god variation ska utvärderas och väljas eller väljas bort.
För att kunna identifiera en förbättring/försämring så måste vi göra en mätning före och efter förändringen. Mätningar är dock vanksliga, vad var det man ville åstadkomma. Har vi ett bra mått på det?
Accuracy over precision säger Mike Cohn - han tycker att det är bättre att ge ett korrekt estimat än ett precist. På samma sätt tycker jag att man kn mäta sig. Var för inte mäta egenskaper som “upplevd yrkesstolthet”, “kundnöjdhet”, “glädje på jobbet”.
