Så er det tid til Julemad

Er du ingeniør, eller har du bare en hjerne der kræver at alle omkring dig er super præcise?

Tjek Cooking For Engineers , et meget seriøst site med diverse opskrifter :-)

Hvad med planlægningen af julen og nytårs festen... bruger i SCRUM principper?

Måske er LEAN eller SCRUM vejen frem til en stress fri jul? Tjek DR.dk for et perspektiv på den sag.

Glædelig jul til jer alle,

Rune og Daniel

Teams #2 - Tillid

Hvad skaber grobunden for et velkonsolideret og high-performance team? Jeg tror, at det er det samme, som venskaber er bygget ovenpå: tillid og respekt. Tillid: at man har tillid til den andens adfærd og handlinger udføres med det bedste ønske i forhold til en selv. Respekt: at man respekterer hinanden og de forskelligheder man måtte have, og faktisk bruger respekten til at lære hinanden noget nyt hele tiden.

Vi har under Scrum-møder den sidste måneds tid stillet det samme spørgsmål (efter de tre andre..): Respekterer vi hinanden og hinandens forskelligheder? Det virker måske lidt too-much-agtigt og akavet, men formålet med spørgsmålet har været at bringe et konstant fokus på, at man skal se hinanden som ligeværdige i forhold til teamets mål og opgaver, og kunne stole på hinanden i forhold til, at hvis en udfører en opgave på en bestemt måde, så har andre på teamet respekt nok til at lade denne person udføre opgaven på denne måde, og ikke mindre, hvis nu opgaven er forkert udført, så har andre personer respekt nok til at turde indgå i dialog herom.

Tilliden har jeg hele tænkt som et biprodukt af fokuseringen på respekt, men efter at have læst en slide-præsentation af Diana Larsen om tillid og teams, så ser jeg nok lidt anderledes på det. Her er f.eks 21 gode tips (på engelsk) til at forbedre/skabe tilliden på ens teams:


1. Trust first—To get trust, give trust and act trustworthy
2. Set a tone for interaction and collaboration from the beginning
3. Identify clear, consistent purpose and performance goals
4. Communicate openly, freely, and honestly
5. Listen carefully and seek fairness
6. Develop comfort with discussing mistakes, concerns, and limitations
7. Respect each other’s opinions
8. Learn about each other’s perspectives
9. Establish strong business ethics
10. Visibly do what you say you’ll do
11. Interact with the team consistently and predictably
12. Decide how the team will decide
13. Take responsibility for team action
14. Give credit to team members
15. Empower team members to take risks and act
16. Make yourself available, accessible, and responsive
17. Show awareness, sensitivity, and support for the needs of other team members
18. Maintain confidences
19. Watch your language
20. Create social time for the team
21. Expect and allow emotional release, find a safe space to vent

Lidt ferielæsning

Jeg er ivrigt læser af bloggen All About Agile Development og har med stor interesse fulgt med i føljetonen 10 Key Principles of Agile Development. I den forbindelse har jeg samlet alle indlæggene til et lille hæfte, som jeg synes i skal bruge en ledig stund på at læse:

10KeyPrinciplesOfAgile.pdf

God jul og happy agiling :)

"How big can an effective standup be?"

I forlængelse af Runes artikel omkring team størrelse, faldt jeg over denne artikel af David Anderson:
How big can an effective standup be?

Det kunne være interessant at afprøve denne form for projekt portefølje ("scrum") møder, hvor alle mødes og går gennem projekterne og de store opgaver i hvert projekt.

Er der nogen er jer der har erfaring med store effektive status møder?

Jeff Sutherland om Scrum og lean...

Her er en yderst interessant artikel, som ridser det historiske perspektiv for både Scrum og lean op:

http://jeffsutherland.com/scrum/2007/11/is-it-scrum-or-lean.html

Spændende pointer og uddrag til dem som ikke har lyst til at læse hele artiklen:

Fastest path to appearance of the next feature:

"The reason the first Scrum team called Sprint Backlog items SyncSteps was that developers executed the Sprint Backlog in a carefully chosen order - that order which produced the fastest path to appearance of the next feature from the users point of view. Just as proper ordering of the Product Backlog optimizes revenue, proper ordering of the Sprint Backlog optimizes production of value. It accelerates software evolution and can produce effects seen in biological systems."

Hele tanken om, at arbejde med sprint backloggen på den måde er super interessant. Gad godt høre om nogle af jer har specifikke erfaringer med dette?

Punctuated equilibrium:

"The "punctuated equilibrium" effect is achieved at Toyota using set-based concurrent engineering. As an example, Toyota does not build one radiator for a new car. They build six, and wait to the last possible moment to choose the best radiator to deploy in production. This is similar to competition between biological species in an ecosystem and the species that adapts best to the environment wins. The Scrumcommunity has yet to implement set based concurrent engineering strategies"

Kunne man gøre brug af denne tankegang i software-udvikling? Det er en naturlig konkurrence situation, som jeg i hvert fald føler vi ofte mangler på vores software-projekter.

Scrum failure:

"Less than 10% of the Scrum teams worldwide can pass the Nokia test, primarily because they cannot deliver potentially shippable (fully tested) software at the end of a Sprint."

Skræmmende! Ifølge ovenstående er vi i øjeblikket også temmelig langt fra at have implementeret korrekt Scrum. Vi øver os, men det som oftest viser at spænde ben, er opstarten af projekter, hvor der bruges alt for lang tid på arkitektur upfront.

On teams:

"A project team is typically 3 developers, 3 QA people, 3 doc people, and one or two users. They meet daily and all agree on steps completed and next steps. For large projects, small teams of this size build components and a SCRUM of SCRUMs meets less frequently to work out interfaces between components. Developers must be outnumbered on the team by QA and documentation people or they generate too much code too fast (malignant functionality)."

Jeg har i lang tid syslet med, at der ikke måtte være flere end 4 udviklere på et team. Ovenstående går meget godt i spænd med den tankegang. Men uha. Vi har ikke en eneste QA person tilknyttet teamet fast. Tesen om, at udviklere skal være i mindretal i forhold til testere, fortæller mig et og andet, om at vi også har en del arbejde på den front, der skal gøres før vi er i mål. Hvordan ser jeres teams ud?

Tip of the iceberg...

Har du nogensinde tænkt over, hvorfor et isbjerg sagtens kan bevæge sig op mod selv den stejleste vind?

En kort og fantastisk artikel om hvorfor man som projektleder lige netop skal bruge langt mere tid på at få kommunikationen og teamet til at fungere end på at lave administrative opgaver ala budgettering, timetracking etc (det betyder dog ikke at man ikke skal lave de administrative, men blot at hvis det er det eneste man fokuserer på så vinder man ikke):

http://www.think-box.co.uk/blog/2007/11/xpday7-why-do-agile-projects-fail.html