Posts Tagged ‘myt’

h1

Är du skrockfull? Ny blogg belyser myter kring agil testning

onsdag, 19 december, 2012

I fredags var det premiär för en ny blogg som bryter isär och reder ut myter kring agile; ”Agila Myter BUSTED (och några bekräftade)”.

Mer specifikt så kommer de första 25 inläggen handla om myter kring agil testning.

Agila Myter BUSTED har som syfte att pröva intressanta och provocerande myter inom agile för att
1) undersöka ursprunget och
2) utvärdera, utforska, analysera och eventuellt avslöja myterna som BUSTED, eller i vissa fall – APPROVED.

Jag är en av författarna och i första inlägget genomlyser vi myten ”Alla agila testare måste vara tekniska”. Är den myten BUSTED eller APPROVED? Läs och se om du håller med om vår slutsats! Debatten hittills har varit intensiv och spännande. Haka på!

Snart dissekerar vi myt nummer 2; ”Regressionstester hinns inte med” (när vi jobbar agilt som t.ex. i Scrum). Busted eller Approved? Följ redan nu diskussionen på Twitter #agilamyter.

Annons
h1

Mini-seminarie på Sogeti Sverige Alumni ikväll – ”Scrum – Myths, Misconceptions and Superstition”

torsdag, 10 februari, 2011

Ikväll kommer jag få äran att hålla ett kort mini-seminarie om Scrum på Sogetis Alumnikväll i Stockholm. Vinklen jag valt är ”Scrum – Myths, Misconceptions and Superstition”.

.


Sogeti Sverige Alumni är ett nätverk för dig som vill hålla kontakt med Sogeti och alla dina tidigare och kanske även framtida kollegor. På Alumnikvällar är man välkommen att träffa vänner och knyta nya kontakter samt få en spännande uppdatering om vad som händer på Sogeti.

Mini-seminariet kommer fångas på film och publiceras några dagar senare här på bloggen.

Kanske ses vi redan ikväll!

.

.
Sogeti Sverige Alumni

Läs mer om Alumnikvällen:
http://www.sogeti.se/Nyheter-Media/Kalendarium/Alumnikvall-pa-Sogeti-2011/

Gå med i vår alumnigrupp
Sogeti Sverige Alumni på LinkedIn:
http://www.linkedin.com/groups?mostPopular=&gid=2591690

.

h1

Genvägarna till det hyperproduktiva teamet

onsdag, 7 april, 2010

Det hyperproduktiva teamet är ett uttryck som ofta florerar i Scrum litteratur och i diverse bloggar och som syftar på teamet som har nått en nivå av ansvarstagande, hängivelse, produktivitet och samarbete som låter dem vara långt mer effektiva i sin leverans av kvalitativa och värdehöjande funktioner och features än ”normalt” – hyperproduktivitet. Här och nu avslöjar jag genvägarna dit!

.

*trumvirvel och en konstpaus*

.

Dom genvägarna finns såklart inte. Tyvärr. Förlåt om jag i ingressen ingöt falska förhoppningar. Det innebär såklart hårt arbete, mycket träning och ibland en stor dos tålamod. Men – jag tror å andra sidan följande punkter är förutsättningar för att över huvud taget nå en högre nivå av produktivitet inom ett team:

  • Följ och efterlev agiles värderingar och de agila principerna. Kör projektet Scrum – kör Scrum fullt ut! Varje moment och regel finns där av ett skäl. Bemästra processen och verktygen.
  • Stakeholders och produktägaren måste visa (och bevisa) för teamet att teamet har  mandat att organisera och styra sig själva och att de (stekeholders och produktägaren) har förtroende och tillit till teamet.
  • Praktisera ”Inspect Adapt Improve”. Ta Sprint Retrospectives på allvar. Säkra stöd hos styrgrupp och organisation att genomdriva nödvändiga förändringar.

Jag är övertygad om att ifall teamet upplever stöd och tillit från ledare och ledning och ges tid att organisera sig själva så kommer dom nå ett tillstånd av hyperproduktivitet.

.

Om du fick samla nio valfria polare, skulle ni också kunna bygga ett hus på en helg?

.

Om du ändå gärna vill tro på att det verkligen existerar enkla genvägar till hyperproduktivitet föreslår jag följande länkar:

Self-Organization in Scrum
Powerpoint från Jeff Sutherland,
http://jeffsutherland.com/SelfOrganizationGoogle5Sep2008.pdf

The Secret Sauce for Improving your Scrum team
Google techtalk från februari 2009. Talare Jeff Sutherland.
http://www.youtube.com/watch?v=M1q6b9JI2Wc

Shock Therapy:  A Bootstrap for Hyper-Productive Scrum
Artikel på rapidscrum.com,
http://www.rapidscrum.com/Shock_Therapy.html

h1

Scrum myt #4: Zoomar man in är Scrum bara små, små vattenfall

onsdag, 31 mars, 2010

”Om man zoomar in tillräckligt mycket i Scrum, in i en sprint så är det ju bara små, små vattenfall. Inget nytt under solen.” FEL!

.
.
.

Scrum är inte små, små vattenfall.

Det grundläggande arbetssättet:
1) planera,
2) utföra,
3) kontrollera och
4) agera

dvs. att man tänker och planerar innan man handlar är inte synonymt med vattenfall.  Så gör man i alla situationer, oavsett uppgift.

.

Så, till skillnad från vattenfall så…

  • Levererar Scrum affärsvärde och ROI väldigt tidigt.
  • Scrums korta feedback cykler förändrar dagligen planen och planering.
  • Planering i Scrum fokuserar på att leverera affärsvärde (inte sprida ut arbetsuppgifter och deadlines i en kalender).
  • Scrum processen är själv-justerande och själv-förbättrande genom kontinuerlig utvärdering och granskning (i motsats till att ha en projektutvärdering i slutet).
  • Scrum välkomnar förändringar, till och med sent i processen, och detta är en naturlig del av processen.
  • Springer man in i bekymmer och tidsnöd så anpassar man i Scrum omfattningen (i motsats till att låta arbetsuppgifterna i planen skjutas framåt som ett tåg av dominobrickor).
  • I Scrum räknas inte framgång i antalet implementerade krav per deadline utan i levererat affärsvärde och kundnytta per sprint.
  • Levereras projektet enligt Scrum kan beställaren efter valfri* Sprint säga ”Nu är jag nöjd” (till skillnad från vattenfallsapproachen då allt eller inget levereras).
  • Scrum levererar potentiellt installerbar system/levererbar produkt varje sprint. Dvs. dokumentation, test, förvaltningsöverlämning etc. ska ske kontinuerligt (i stället för att komma som faser i slutet).

* Brasklapp. Det kan såklart dröja några sprintar innan man nått en minimal nivå av funktioner för att produkten ska gå att använda över huvud taget. Och ibland kanske det också krävs en stabiliserings- och Deploy sprint efter att beställaren ”är nöjd”.

.

Jag kan fortsätta rada upp skillnader. Jag hoppas dock i och med detta utbrott att det en gång för alla är vederlagt och fastslaget att det är stor skillnad mellan sekvensiell up-front planering/big-bang leverans (a la vattenfall) och agil planering/iterativ inkrementell leverans (Scrum). Fast att tro något sådant kanske vore nog naivt…

h1

Scrum myt #3: Agil utveckling är odisciplinerad

tisdag, 23 mars, 2010

”Agila metoder är bara utvecklarnas ursäkt för att få göra som dom vill”, eller Extreme Programming är ju bara ett fint ord för fulkodning eller hack-n-fix” är påstående jag hört från olika håll, och ibland fortfarande känner bubbla under ytan. Sanningen är snarare motsatta.

För att överhuvud taget lyckats producera högkvalitativ, levererbar kod varje sprint i ett Scrum projekt, och samtidigt undvika att bygga på teknisk, skuld behövs ordentlig disciplin i teamet. Scrum beskriver inga best-practices för programmering eller test – det gör däremot XP och därför är XP ett kraftfullt,  populärt och nästintill nödvändigt komplement till Scrum (vissa XP principer är t.o.m. inbyggda i Scrum).

Men det är absolut inget extremt alls med XP principerna. Var och en av dem beskriver ett verktyg, eller trycker på vikten av olika metoder eller tekniker för att utveckla kod på ett strukturerat sätt som i sin tur skapar högre kvalitet. Ingen av dem säger ”Gör som du vill så blir det bra”. Jag vet inget som kräver så mycket disciplin, tålamod och ödmjukhet som till exempel par programmering. Jag har å andra sidan svårt att komma på något som höjer kvaliten så mycket som just par programmering.

Nu kan det ju dock såklart vara så att du har en person i Scrum teamet som gått på myten och tagit med sig missuppfattningen in i teamet och som hävdar att alla förslag på att införa stuktur, design patterns, templates, etc. går emot Agile värderingar och principer. Det finns inget enklare sätt att uttrycka det på – den personen är låååångt ute på åkern och cyklar.

Agil utveckling och Scrum kräver disciplin!

h1

Scrum myt #2: Scrum är en hype

lördag, 6 mars, 2010

”Scrum är bara en hype. Det är bara coolt just nu att säga att man jobbar agilt men eftersom allt fler bevisligen springer in i bekymmer med Scrum kommer det snart självdö.”

Visst, fler och fler byter från tradionella sekvensiellt planerade projekt (a la vattenfall) till agila utvecklingsmetoder vilket byter att allt fler exempelvis kör Scrum. Scrum har en fantastisk förmåga att snabbt lyfta fram och synliggöra brister i organisationen, i rutiner och processer och i samarbete och kommunikationen kollegor och kund emellan, etc. Dessa ”brister” görs synliga genom Scrum. De skapas inte av Scrum utan har alltid funnits där. Misstaget är att anklaga Scrum för dessa problem och att inte utnyttja tillfället att addressera dem.

Dessa är definitivt en kortvarig hype! Eller är det bara jag som inser det?

Men visst, det är väldigt populärt att vilja säga att man jobbar agilt. Ordets hypade betydelse kommer dock förhoppnings svalna allt eftersom folk förstår den faktiska innebörden av att en utvecklignsprocess är agil.

Och visst, Scrum kanske är den populäraste projektmodellen just nu och kommer kanske om några år ersätts av Scrum 2. Men agila utvecklingsmetoder är definitivt här för att stanna! Var så säker på det.

h1

Scrum myt #1: Agilt betyder ”Ad hoc”

fredag, 5 mars, 2010

Överhörde häromdagen ”Jag angriper det här väldigt agilt, det vill säga jag tar det som det kommer”.

Suck.

Om personen ifråga menade ”Jag planerar inte mitt hobbyprojekt utan gör vad jag känner för från dag till dag” är det ändå verkligen långt ifrån Just-In-Time and Just-Enough planering, ett angreppssätt som tillämpas i Scrum. Att jobba ”Ad Hoc” är inte att jobba agilt.

Det vore som att säga att man är kristen bara för att man håller med om att ett slumpvis valt budorden verkar vettigt att följa, t.ex. ”Du skall icke dräpa”.