Archive for Henrik Berglund, Author at ProAgile

En feedback loop

Va? Är inte Sprint Demo en fantastisk idé?

Visst, grundtanken när man kör en Sprint Demo är ofta god. Man vill ha feedback. Så långt är allt bra, men att köra Sprint Demo för med sig ett antal problem också.

Att köra en demo efter varje sprint leder oftast till missade releasedatum, teknisk skuld och till felaktiga prioriteringar!

Så många och stora problem orsakas av Sprint Demos att jag skulle vilja be er alla att genast plocka bort dem från era kalendrar.

Men Sprint Demo är väl en del av Scrum?

Nej, faktiskt inte. Det finns en liknande sak i Scrum som heter sprintgranskning (eng. Sprint Review), men det är en väldigt annorlunda aktivitet jämfört med det som oftast kallas “demo”.

Inte för att det spelar någon roll om ni följer Scrum eller inte, men i just det här fallet tror jag att de flesta skulle kunna få ut mer värde genom att byta från “demo” till “granskning”.

Vad är skillnaden på en demo och en granskning?

Syftet

  • Tänk dig att en försäljare demonstrerar en produkt för dig. Syftet är att få den att se bra ut. Kanske att ge en applåd från publiken när de ser hur snyggt och bra allt ser ut!

  • En granskning har däremot syftet att skapa en verklig förståelse av hur det ligger till med något. Utan försköning. Bra eller dåligt. Om man vet hur man ligger till kan man göra planer, prioriteringar och fatta beslut som bygger på fakta. Får man en felaktig uppfattning om hur man ligger till blir planerna opålitliga och besluten fel.

Samspelet

  • En demo är oftast en enkelriktad aktivitet. Någon visar upp/demonstrerar något.

  • Deltagarna i en granskning däremot är aktiva och letar efter fel som kan åtgärdas och förbättringar som kan göras.

Kvalité

  • Jag har varit med och byggt demos för många olika kunder. Det kan vara för en kundpresentation eller för en mässa t ex. Stressen är ofta stor för att få med så mycket som möjligt och för att få produkten att se bra ut.

    Tillfälliga lösningar och genvägar tas till för att hinna. Kvalitén är långt ifrån det man vill ha i produktion och alltihopa borde helst kastas bort och göras om för att kunna vara en del av en kvalitetsprodukt. Kunderna får dock intrycket av att det är klart vilket ökar pressen ännu mer. Dålig kvalité börjar smyga sig in i produkten.

  • På en sprintgranskning går man bara igenom de saker som lagts till i produkten och som uppfyller Definition of Done. Dvs de har full tekniskt kvalitet och är klara för produktion.

    En bra Definition of Done innebär att man kan lägga en story/feature åt sidan när den passerat. Man behöver inte gå tillbaks till den för att göra klart någon del eller rätta tekniska defekter i framtiden.

    Eftersom man inte behöver gå tillbaka till en feature/story kommer den inte att påverka de framtida planerna.

    Det kan ta ett par år att komma hit som organisation. Automatisering av test/regressionstest brukar t ex vara en utmaning. Likaså brukar det ta ett tag att införa vanan att refaktorera fungerande kod tills den är lätt att läsa och ändra innan man räknar den som “Done”. Men när man lyckats blir allt mycket lättare. Tid som man förr lade på att rätta gamla saker frigörs. Man kan fokusera på nya saker, får snabbare progress och en roligare arbetsmiljö.

Ett exempel

 

15 teams som integrerar

I en organisation som jag jobbade med hade vi ca 15 teams och körde demos efter varje sprint. Alla teams hade jobbat hårt och gjort en massa saker. På demon berättade de om allt de gjort och visade små filmer. Alla var glada och det verkade rulla på bra med utvecklingen. Det verkade dock som att det alltid var något lite kvar att göra för varje sak innan den var riktigt klar. Det mesta var 90% klart…

Efter demon skulle produktägarna uppdatera sina prognoser/tidplaner. Det här var en del av en stor organisation med många beroenden utåt, så det var viktigt att kunna visa hyfsade prognoser mot externa teams så att de kunde anpassa sin planering.

Vad var problemet?

Hur mycket utvecklingstid återstår då på en feature som är 90% klar? Vad skulle produktägarna räkna med i sina planer? Problemet är att ingen vet det. Innan vi är helt klara kan det alltid dyka upp nya oväntade problem. Små som stora. När det är 90% klart, kanske 90% återstår...

Effekten av att jobba så här är att när man närmar sig någon viktig leverans så är allt 90% klart och ingen har en aning om hur man ligger till. Alla får jobba övertid och endera missar man leveransen eller så släpper man ut en tekniskt undermålig produkt. Felen strömmar in och man får betala dyrt i form av bortslösad tid. Rättningar tar normalt sett minst 5-10 gånger längre tid än vad det tagit att göra rätt från början. Stressen ökar och kvalitén sjunker ännu mer.

Omgivningen blir missnöjd över kvalitén och den dåliga precisionen i planeringen. För att få koll börjar ledningen kräva mätvärden och detaljstyra teamen. Statusrapportering av felrapporter kommer i fokus istället för nyutveckling och innovation. Mätvärden i form av “velocity” gör att kvalitén försämras ytterligare när teamen tar genvägar för att visa upp bra resultat.

Vad vi gjorde

Det här var fortfarande i ett ganska tidigt skede i ett nytt utvecklingsinitiativ. För att förekomma alla de här dåliga konsekvenserna bytte vi namn på Sprint Demo till sprintgranskning och införde nya regler. Bara det som uppfyller Definition of Done får visas på sprintgranskning. Definition of Done i det här fallet innebar bl a att automatiska testfall ska finnas i CI-kedjan och att all integration mellan de 15 lokala teamen ska vara gjord.

Förändrings-smärtan

 

Irriterade teams

Förändringen gav upphov till en hel del missnöje. T ex

  • “Varför får inte vi visa vad vi gjort? Vi är ju klara. Vi väntar ju bara på att kunna integrera med det andra teamet!”

  • Våra saker är så stora att då kommer vi ju aldrig att få visa något!

  • Vi är ju klara nu! Det är ju bara problem med CI-miljön som gör att vi inte kan skriva klart testerna!

  • Energin är väldigt låg nu med det nya sprintgransknings formatet, vi måste ändra agendan för att uppmuntra våra team!

  • “Den dumma som har hittat på det här med integrerade end-to-end-feature-slices (jag ? 😉 ) kan göra nedbrytningen själv!”

När vi började hålla på de nya reglerna för sprintgranskning visade det sig också att det inte var lätt att få något helt klart. De första 3 sprintarna lyckades inget team få klart någon av totalt ca 30 saker de räknat med att göra under perioden! Efter ett kvartal började det släppa och slutligen lyckades teamen få klart ca 10 av de 60 funktioner som de själva lagt som prognos för kvartalet.

Förbättringen

Innan tyckte man alltså att det gick i stort sett bra och enligt plan. Nu visste vi mer om hur lång tid det tar att verkligen tar att göra klart något och kunde vara mer trovärdiga i våra planer/prognoser mot vår omgivning.

När slutligen progressen började komma, kom glädjen och energin tillbaka i sprintgranskingen.

Saker som är “Done” har nu automatiserade regressionstester och kommer att ställa till med mindre problem och störningar i framtiden.

Fokus på att få klart saker drev också många bra diskussioner/beteenden:

  • Fokus på samarbete/samplanering mellan team så att integration kan göras under sprinten. Mindset-förändring: I en miljö med många team och beroenden kan inte ett team vara klara utan att de andra är klara. Innan allt går att köra i den gemensamma integrerade målmiljön är det inte “Done”. Innan dess återstår ju nämligen integration, vilket är ett av de största problemen/riskerna i stora organisationer, så det vill vi inte skjuta upp, utan helst göra kontinuerligt (CI). Som senast ska det vara gjort inom sprinten.

  • Fokus på nedbrytning i mindre end-to-end slices av funktioner som kan avslutas inom sprintarna. Det ger tidigare integration, bättre förutsägbarhet och gör det lättare att alltid har en releasebar produkt. Dvs ingen övertidshets eller dålig kvalité när det närmar sig leverans.

    Mindre arbetspaket förbättrar också flödet och ökar farten. Det vet den som har koll på idéerna i Lean. 

  • Fokus på teststrategier och samarbete mellan teamen på att lösa svåra testfall drev fram bättre tekniker för test. 

Invändningar

Om vi väntar tills något är “Done” innan vi visar det på vår sprintgranskning, går vi inte miste om feedback då?

Nej, se till att ha ett nära samarbete under sprintarna med era intressenter och fånga feedbacken där. Att hitta problem på sprintgranskning är i senaste laget. Mycket arbete kan ju vara nedlagt förgäves om man väntar till sprintgranskningen med att få feedback. Låt den vara en sammanfattning istället där vi gör en sista koll av att alla är överens om att en feature/story är “Done”. Försök även så långt som möjligt granska om den löser det verkliga behovet/levererar tänkt värde.

Spelar det någon roll vad det heter? Vi kan väl kalla det Sprint Demo och ha fokus på “Done”?

Nyord

Tyvärr funkar det inte i praktiken. Många försök att ändra betydelsen av olika ord har gjorts i agile-värden. T ex att kalla något för en demo men att köra en granskning. Men vilka ord man använder påverkar mer än vad man kan tro.

Kallar man det demo så blir fokus på att visa saker och få det att se bra ut. Prio läggs på det som är lätt att presentera istället för det som har högst prio. Saker som inte går att demonstrera tas inte ens upp till granskning. Kvalitén sänks för att få saker att se bra ut.

Dvs; det går inte! Ord har en betydelse och det går inte att ändra med en annan agenda. Ni måste byta namn på er Sprint Demo om ni vill få fördelarna av en sprintgranskning.

Sammanfattning

Genom att gå över från Sprint Demo till sprintgranskning så lärde sig organisationen i exemplet ovan relativt snabbt en hel del om vad som krävs för att många teams ska kunna bygga en produkt tillsammans.

Att byta sin Sprint Demo mot en sprintgranskning är inte en helt enkel ändring att göra. Helt plötsligt blir den verkliga progressen synlig. Likaså blir alla problem som hindrar organisationen från att ta sig framåt smärtsamt tydliga.

Men fördelen med det är ju att när man vet vad man har för problem kan man åtgärda dem. Utvecklingen kommer då bara att flyta på bättre och bättre ju fler saker man lyckas åtgärda. Trivseln kommer att öka och man kan såsmåningom löpande leverera kvalitetsprodukter som alla kan vara stolta över, utan panikartade övertidsrace.

Har ni “demos” hos er, på sprintnivå eller på andra skalningsnivåer? Fundera på om det inte är dags att gå vidare och börja köra en granskning istället!

Molood Noori

Are you trying to use agile with many teams across several locations/countries? Agile Coach Molood Noori have used Sociocracy 3.0 to successfully adress this situation. Check out the interview below with her by ProAgile's Henrik Berglund.

ProAgile: Hello Molod! Really looking forward to be talking about some interesting experience you have with Sociocracy 3.0 and scaling agile.

Molood: Hi. It’s nice to be here and have the opportunity to share my experience regarding Sociocracy 3.0 in a distributed organization.


ProAgile: Before we get into that, could you just tell us a few things about who you are and what you do?

Molood: Sure. My name is Molood Noori. I’ve been practicing agile coaching for a few years now. I’m a big advocate of remote work and geographically distributed teams in the agile world. I believe that remote work is the future of work.

I help people in agile organizations to re-think and re-shape their governance structure in a way that would enable them to gain more freedom, become happier and hence more productive.


ProAgile: So, you recently coached on organization as they applied Sociocracy 3.0. From your point of view, what was interesting about this experience?

Molood: My last project was with King. They have offices in over 10 countries.

This is where I used Sociocracy 3.0 to help one department change their structure to scale in a sustainable way.

I’m gonna give you three insights that I gained through that experience.

  • While Sociocracy 3.0 can seem like a heavy framework at first, it feels like common sense after you start putting it in practice. I’ve seen it happen not only with product owners and developers, but also with managers as well.
  • Despite the threatening appearance of the idea of collaborative governance - as suggested by Sociocracy 3.0 - for people in leadership positions, they were indeed the ones that benefited the most from an S3 way of working. In my experience, a big load of work got lifted off of the leaders’ shoulders and they could focus on high impact work that really mattered.
  • I learned an important lesson as the facilitator of the self re-organization workshop using S3: do not get stuck in planning, execute the plan immediately after it’s good enough for now and safe enough to try. Then observe the impact and re-iterate to refine and improve the plan based on the feedback you receive in action.

ProAgile: That sounds great! So, what where some of the challenges that triggered this work?

Molood: There were quite a few challenges that triggered this work.

  • A fundamental problem was a lack of vision or what I call having multiple visions for the product.
  • The developers had too much work all the time. New customers meant new feature requests and more time spent on supporting the internal customers i.e. game developers and game artists. A few people had multiple responsibilities that were sometimes competing with one another which was causing conflict of interests.
  • The development teams were located in different countries and verbal conversations about design decisions or working agreements or any other decision that required consensus was time consuming and frustrating. Some decisions were dependent on the input of people with the required authority but not necessarily the needed knowledge to make those decisions.

All of these challenges affected the pace of development, the quality of the product and clearly the overall motivation of people who were creating a product that was used over one billion times every day.

I chose S3 to improve the situation.


ProAgile: Could you give an example on how S3 helped you work on these challenges?

Molood: It’s rather difficult to be specific answering this question, because S3 has made an impact on the overall structure and way of working of the organization.

Let people grow to take responsibility

Actually, before I even knew about S3, I had a mentality that was totally compatible with S3. From the very beginning of my coaching journey, I questioned the value of meetings. I therefore made attendance to all meetings optional. This suggestion helped the organizations to identify the meetings that were not adding value so they could remove or improve them.

What S3 promotes is that decisions should be made by people who are affected by the decision. With S3, decision making became so much easier for all roles in the organization. On top of that, people grew to take responsibility 

Handling multiple visions

For example for the challenge of having multiple visions, (which people often call lack of a product vision), I facilitated a few meetings/workshops with the product owners, architects and developers. In these workshops, they visualized their unique take of the product vision and roadmap and I designed a few steps in the workshop for them to combine those into one unified roadmap and vision using consent decision making promoted by S3.

This way of creating the roadmap and making decisions about adding features and improvements as time went by, became the foundation of a smooth scaling of this organization.

Making it easy to bring in new people

Another example for how S3 improved the way of working was helping the distributed teams to collaborate together.

Bringing new people onboard the organization became really easy as the organizational structure as well as agreements and processes were documented, visualized and always up-to-date. Roles and responsibilities became clearer, knowledge sharing became an innate part of the DNA of this organization; and the most important of all is that productivity and code-quality got improved as people took responsibility much more easily. 

The organization adapts to current needs

Also the organization became more dynamic as the need of the product became the defining factor for the organizational structure rather than some random governance group’s thoughts and decisions.


ProAgile: A lot of people are looking at frameworks like SAFe, LeSS and Nexus for scaling their organizations. How do you think that approach compare to this experience?

Molood: S3 is a not a replacement for any of those scaling frameworks. It’s a complementary framework that makes it easier to adopt those.

S3 allows organizations to sustainably scale

The S3 techniques for decision making and communication allow organizations to sustainably scale using any of the scaling frameworks you mentioned.

Let your needs drive your use of frameworks

However, in some cases it might seem counter intuitive to have a collaborative governance side-by-side a hierarchical management structure. What is important to remember is that S3 and SAFe (or LESS or Nexus) are frameworks and that means they are not prescriptions. Therefore organizations should pick from them what works for their specific needs.

Get more value from frameworks using botttom-up intelligence

I think if an organization understands the principles of collaborative governance using S3, they would have an easier time with scaling frameworks such as SAFe. S3 potentially enables everyone in the organization to directly impact the decisions that affect them.


ProAgile: So, if people want to learn more about this experience, I know there is an opportunity to hear you speak about it.

Molood: Yes. I will be speaking at the Agile People Sweden Conference on October 25th.  There I will share more details about how I facilitated the transition to S3 for a distributed organization. I will share about the challenges and also what I learned from the experience.


ProAgile: And for those that want to learn more about S3, we have james Priest and Liliana David coming in to do a Sociocracy 3.0 course in Gothenburg on October 27-29. You know them right?

Molood: Yes of course. Having used S3 to this extent, it’s not easy not to know James and Lilli. They are the biggest promoters of S3. They go to different countries to teach it. I owe the majority of my learning about Sociocracy 3.0 to James and Lilli. They have come to Sweden a few times to offer a course in S3 and I saw on your website that they will be in ProAgile soon for the same course. I think it's fantastic. More people need to learn about S3!


ProAgile: Thank you for taking the time to talk to us Molood. I think it will be quite interesting to see what can be done once these patterns start to spread to more organizations!

Molood: Thank you for having me!

 
Stefan & Henrik vid agendan

Igår jobbade jag och Stefan med förberedelser inför höstens kurser i ”Facilitering för Agila ledare”. Vi körde kursen två gånger under våren och fick fina omdömen av deltagarna! Men som sanna agilister nöjer vi oss såklart inte med det, vi vill göra det ännu bättre!

Här är några saker som vi planerat inför höstens kurser:

  • Mer fokus och flera nya övningar till den del som handlar ”interventioner”, dvs ingripanden som man som facilitator gör under en session. T ex, hur hanterar man låsta positioner eller att deltagarna inte förstår varandra?
  • En ny sektion om att lyckas med samarbete trots att alla inte finns på samma plats rent fysiskt.
  • Mer om ”Training from Back of the Room”. Det pedagogiska upplägget vi använder i kursen. Du lär dig genom att uppleva det under två dagar. Nu lägger vi även till lite extra innehåll runt det. Håller du ibland egna utbildningar gissar vi att du kan nå en helt ny nivå efter det här. Med mindre förberedelser från dig!
  • Under våren testade vi med upplägget att deltagarna fick ta med en vän eller kollega gratis på kursen. Det var väldigt lyckat, så vi fortsätter att köra så! Det är lättare att komma hem börja tillämpa sina nya färdigheter om man delar sin inspiration med någon annan tror vi 😉 Två för en alltså!

Hoppas vi ses på en session i höst. Här kan du och en vän/kollega boka in er!

Ladda också gärna ner och sprid en Här
Mvh

Stefan & Henrik

Ikväll hade SAST Väst temakväll om agilitet.

Talade först gjorde forskaren Lucas Gren.

Han pratade bland annat om gruppsykologi och hur man mäter en arbetsgruppsmognad. Detta sattes i relation till gruppens förmåga att ta till sig (och inte ta till sig) agila koncept och praktiker. Syftet med hans presentation var att både inspirera och ge nya perspektiv på de mänskliga aspekterna av kvalitet och test.

Sedan höll jag en session om hur man blir en agil organisation.

Ämnena hade bra beröringspunkter. Att skapa förutsättningar för högmotiverade (mogna) team genomsyrar hela vårt coachingkoncept, den agila resan. För att nå dit tillämpar vi i praktiken rön från socialpsykologin som han nämnde. Man ser det under hela resan, och i det speciella momentet som handar om teamstarter.

Kul att träffa en ny meetup grupp i Göteborg. Hoppas att vi ses igen, t ex på Agile Lindholmen eller något av våra andra evenemang!

 

 

 

Självstyre på Morningstar

november 13, 2015

En stor del av kraften i de agila teknikerna kommer från att mer självstyre införs. Den delen av den agila kartan känns dock obekvämt för de flesta. Givetvis! Det är en stor förändring jämfört med de hierarkiska system som de flesta av oss är vana att arbeta i.  Kan det fungera? Javisst! Till och med extrem delegation är beprövat sedan 80-talet och verkar kunna fungera i alla möjliga typer av verksamheter.

Ta några minuter och titta på videon ovan. Den visar hur ett företag som processar tomater skapat något utöver det vanliga!

Kan din organisation fortsätta att inte dra nytta av den här kraften? Vad är nästa steg för er mot större och mer väl fungerande självstyre?