Mangler du en pragmatisk introduktion til Scrum og Agile? Leder du efter startblokken for at komme i gang med agile projekter? Eller er dit behov essentiel viden om den agile proces, så du forstår hvad der forventes af dig? På en aften vil du få løftet din forståelse af de tre mest udbredte agile metoder: Scrum, Kanban og XP. Du vil få præsenteret de enkelte metoders bestanddele og hvordan de hænger sammen. Du vil forstå metodernes forskelle og vil også få et indblik i hvordan de kan kombineres. Alt i alt vil du få et godt grundlag på din vej til at blive en dygtig agil praktiker.

1. VELKOMMEN
VI STARTER MED AT MINGLE!
men med regler:
• Gå igang med det samme!
(må gerne smide overtøjet først)
• Find eller dan en gruppe og snak
om “hvad I kender til agile?”
• Hvis gruppen bliver flere end
3 personer, så split gruppen i to

2. 3 AGILE METODER PÅ ÉN AFTEN
Cafémøde hos BestBrains, 31. august 2015
af Nino Stokbro Ag

3. PROGRAM
• Det agile fundament
• Scrum Framework
• Kanban Software Development
• eXtreme Programming
Spørg endelig undervejs!

4. DET AGILE FUNDAMENT
Et fælles værdisæt for alle agile praktikker
• agile kendetegn
• værdierne i det agile manifest
• principperne i det agile manifest

5. AGILE KENDETEGN
EMPIRISK PROCES KONTROL
kontrol af uforudsigelige systemer gennem
transparens, inspektion og tilpasning

6. AGILE KENDETEGN
ITERATIVT & INKREMENTELT
via gentagne forløb af identiske skridt
leveres trinvist i dele der bygger oven på hinanden

7. AGILE KENDETEGN
SELVORGANISERING
teamet gøres handlekraftigt og beslutningsdygtig

8. AGILE KENDETEGN
HURTIG FEEDBACK
hurtig feedback søges aktivt
og bruges til at skabe forbedringer

9. AGILE KENDETEGN
OPTIMERING AF FLOW
fokus på optimering af hele kæden, ikke enkelt led
fokus på at afslutte opgaver

10. AGILE KENDETEGN
LETVÆGTSPLANLÆGNING
planlæg kun tilstrækkeligt, fokuser på afhængigheder
planlægning er vigtig, planen er ikke

11. AGILE KENDETEGN
KONTINUERLIGE FORBEDRINGER
et konstant fokus på små forbedringer driver fremgang

12. AGILE KENDETEGN
SPILLE FOR AT VINDE
Fokus på fælles sejr, ikke individuelt-styrket i nederlag

13. AGILE MANIFEST
4 VÆRDISÆTNINGER
• Individer og samspil
frem for arbejdsgange og værktøjer
• Software der virker
frem for omfattende dokumentation
• Kunde-samarbejde
frem for kontraktforhandling
• Handle på forandringer
frem for fastholdelse af en plan

14. 4. Forretningsrepræsentanter og udviklere skal
samarbejde dagligt gennem hele projektet.
5. Opbyg projekter omkring motiverede
personer. Giv dem de rette omgivelser og
den støtte de behøver, og hav tillid til at de
klarer opgaven.
6. Den mest effektive måde til videregivelse af
oplysninger til og inden for en gruppe er
ansigt-til-ansigt samtale.
AGILE MANIFESTO
12 PRINCIPPER, 1-6
1. Vores højeste prioritet er at tilfredsstille
kunden gennem tidlig og kontinuerlig
levering værdifuld software.
2. Tag imod skiftende krav, selv sent i
udviklingsforløbet. Agile processer tøjler
ændringer til kundens konkurrencemæssige
fordel.
3. Vi leverer brugbart software ofte, fra et par
uger til et par måneder, med præference for
kortere intervaller.
Kontinuerlige leverancer
værdsæt ændringer
Korte iterationer
Samarbejde
Motivation
Ansigt-til-ansigt

15. 10. Enkelhed
— kunsten at maksimere mængden af arbejde,
der ikke udføres —
er afgørende.
11. De bedste arkitekturer, krav og designs opstår ud
af selv-organiserende teams.
12. Med jævne mellemrum reflekterer teamet over,
hvordan de kan blive mere effektive, op justerer
deres adfærd i overensstemmelse hermed.
AGILE MANIFESTO
12 PRINCIPPER, 7-12
7. Software der virker, er den primære målestok for
fremdrift.
8. Agile processer fremmer bæredygtig udvikling.
Sponsorere, udviklere og brugere skal kunne
opretholde et fast udviklingstempo på ubestemt
tid.
9. Konstant opmærksomhed på teknisk ekspertise
og godt design øger agilitet.
Software, der virker
Bæredygtig udvikling
Teknisk ekspertise
Enkelthed
Selvorganisering
Kontinuerlig forbedring

16. 10 MIN PAUSE
Snak i pausen om:
- hvordan relaterer det sig til din hverdag?
- hvad giver mening i forhold til din kontekst?

17. SCRUM FRAMEWORK
JEFF SUTHERLAND & KEN SCHWABER
Et framework for samarbejde i produktudvikling

18. SCRUM FRAMEWORK
UDVIKLINGSPROCESSEN
Scrum artifakter:
‣ Product Backlog
‣ Sprint Backlog
‣ Product Increment
‣ Definition of Ready
‣ Definition of Done
Scrum aktiviteter:
‣ Backlog Refinement
‣ Sprint Planning I & II
‣ Daily Scrum
‣ Sprint Review
‣ Sprint Retrospective
Scrum roller:
‣ Product Owner
‣ Scrummaster
‣ Development Team

19. Emphasis on Process
Linear Process Style
Focus on Upfront Planning
Comprehensive Documentation
Centralized Managed Organisation
Command and Control Management Style
Plan Conformity is the Primary Succes Criteria
Customer Involvement in Project Start and Finish
Return of Investment upon Project Completion
Process Centric Quality Assurance
Emphasis on People
Iterative Process Style
Limiting Upfront Planning
Only Required Documentation
Decentralized Self-Organisation
Servant Leadership Management Style
Business Value is the Primary Succes Criteria
Customer Involvement Throughout Project
Return of Investment Early and Throughout
Customer Centric Quality Assurance
SCRUM TRADITIONAL
⬌
⬌
⬌
⬌
⬌
⬌
⬌
⬌
⬌
⬌

20. KANBAN SOFTWARE DEVELOPMENT
DAVID J. ANDERSON
Sæt farten ned, for at komme hurtigere frem

21. KANBAN SYSTEMS (VISUELT KORT / OPGAVETAVLE)
THE IMPERIAL GARDEN I TOKYO

22. KANBAN SOFTWARE DEVELOPMENT
INSPIRERET AF LEAN THINKING
Kanban kerne praktikker:
‣ Visualize the workflow
‣ Limit work in process (WIP)
‣ Make process policies explicit
‣ Manage flow
‣ Improve collaboratively

23. No prescribed roles
Continuous Delivery
Work is ‘pulled’ through the system
(single piece flow)
Changes can be made at any time
Important measures: Lead time & Cycle time
Can work in operational environments with a high
degree of variability in priority
Pre-defined roles of
Scrum master, Product owner and team member
Timeboxed sprints
Work is ‘pushed’ through the system in batches
(the sprint backlog)
No changes allowed mid-sprint
Important measure: Velocity
Requires situations where work can be prioritized in
batches that can be left alone
SCRUM KANBAN
⬌
⬌
⬌
⬌
⬌
⬌

24. 10 MIN PAUSE
Snak i pausen om:
- hvordan adskiller disse idéer sig jeres arbejdspraksis?
- kan I bruge nogle af disse idéer til at forbedre jer?

25. EXTREME PROGRAMMING
KENT BECK
Gode velkendte udviklingspraktikker ført ud i ekstremet

26. EXTREME PROGRAMMING
Praktikker:
‣ User Stories
‣ The Planning Game
‣ Whole Team
‣ On-site customer
‣ Acceptance Tests
‣ Small Releases
‣ Continuous Integration
‣ Collective Ownership
‣ Coding Standard
‣ Metaphor
‣ Sustainable Pace
‣ Pair Programming
‣ Test Driven Development
‣ Refactoring
‣ Simple Design

27. EXTREME PROGRAMMING
Primære principper:
‣ Rapid feedback
‣ Assume simplicity
‣ Incremental change
‣ Embracing change
‣ Quality work
Sekundære principper:
‣ Teach learning
‣ Small initial investment
‣ Play to win
‣ Open, honest communication
‣ Accepted responsibility
‣ Local adaptation

28. Regler
Planning
‣ User stories are written.
‣ Release planning creates the release schedule.
‣ Make frequent small releases.
‣ The project is divided into iterations.
‣ Iteration planning starts each iteration.
Managing
‣ Give the team a dedicated open work space.
‣ Set a sustainable pace.
‣ A stand up meeting starts each day.
‣ The Project Velocity is measured.
‣ Move people around.
‣ Fix XP when it breaks.
Designing
‣ Simplicity.
‣ Choose a system metaphor.
‣ Use CRC cards for design sessions.
‣ Create spike solutions to reduce risk.
‣ No functionality is added early.
‣ Refactor whenever and wherever possible.
Coding
‣ The customer is always available.
‣ Code must be written to agreed standards.
‣ Code the unit test first.
‣ All production code is pair programmed.
‣ Only one pair integrates code at a time.
‣ Integrate often.
‣ Set up a dedicated integration computer.
‣ Use collective ownership.
Testing
‣ All code must have unit tests.
‣ All code must pass all unit tests before it can be released.
‣ When a bug is found tests are created.
‣ Acceptance tests are run often and the score is published.
EXTREME PROGRAMMING

29. AGILE, FRA IDÉ TIL VÆRDI
DEN AGILE PROCES MED SCRUM

30. SOFTWARE ENGINEERING
EN KLASSISK METAFOR FOR SOFTWARE UDVIKLING

31. SOFTWARE SURGERY
EN ALTERNATIV METAFOR FOR SOFTWARE UDVIKLING

32. SOFTWARE EXPEDITION
ENDNU EN METAFOR FOR SOFTWARE UDVIKLING

33. TAK, OG FORTSAT GOD AFTEN
Og husk evalueringer, tak.