Martin Jünckow

Fake agile

Altså den erfaring jeg har med SAFe matcher meget godt din beskrivelse af det blog-indlæg du refererer til.

Det er et monstrum skabt ud fra et enterprise mindset og har meget lidt med agile at gøre - det er process sat over individuals og interactions.

Man skal være varsom med de her enterprise scrum frameworks - der er en årsag til at der ingen alignment er imellem de forskellige organisationer indenfor scrum og agile når det kommer til skalering af scrum.

Der er god alignment når vi taler om hvordan man arbejder agile på projekter op til omkring 10 mand - alt derover og vi er stadig ved at prøve at finde ud af det og problemet er nok at der begynder at være alt for mange faktorer der spiller ind til at det er let at generalisere over.

26. oktober 2018 kl. 18:43
Fake agile

Jeg har været rundt i en del større enterprise-virksomheder grundet mit arbejde som konsulent og jeg har endnu til gode at møde "ægte" scrum i disse store virksomheder.

Jeg startede sidste måned hos en stor IT virksomhed som under interview-delen brystede sig af at være førende indenfor Scrum og SAFe, blot for tørt at måtte konstatere at vores Scrum Master agerer klassisk Projektmanager, at vores team på 15 mand er spredt ud over hele globen, at vores reviews er indstuderede demoer der foregår foran 100 mennesker på en scene - og at vi stadig har vores første retrospektive til gode.

Står det bedre til i SMB segmentet?

25. oktober 2018 kl. 08:41
Umuligt at udskifte Edge som standard-browser i Microsofts svar på Chrome OS

Ret væsentlig forskel er at Windows 10 S kører x86 og at man kan installere og afvikle win32 applikationer. Begrænsningen er dog at de skal installeres via det centrale Windows Store, men det er jo ikke så ulig andre platforme.

Væsentligt i forhold til RT er altså at man ikke er begrænset til UWP apps.

4. maj 2017 kl. 06:58
Anders Hejlsberg: Typescript-compiler giver Javascript-udviklere mere intelligente værktøjer

Der er ikke mange der skriver ren vanilla javascript mere og der er massere af alternativer til Typescript.

Men med Typescript får du alt det du nævner plus type-support og ES7 features såsom decorators.

I mine øjne er Typescript den mest gennemførte løsning til store frontend applikationer og det faktum at selv Google har valgt at omfavne det med Angular vidner også derom.

Typescript = ES6 + ES7 + typer

20. april 2017 kl. 08:31
Ni djøf'ere og én fhv. KMD-direktør skal stoppe it-skandaler: »Der kommer intet banebrydende«

Sålænge opskriften for projekter i det offentlige ser således ud:

Processes and tools over individuals and interactions Comprehensive documentation over working software Contract negotiation over customer collaboration Following a plan over responding to change

Kan resultatet vel heller ikke overraske

22. marts 2017 kl. 17:52
Agilefall og watergile: Virksomheder går i stå i vadestedet på vej mod agil

Hej Leif

Jeg kan se artiklen er blevet opdateret i mellemtiden og formuleringen ændret i det problematiske afsnit.

Ellers ganske enig i dine pointer og et vigtigt emne at få mere spot på. Jeg er bekymret over den negative holdning jeg oftere og oftere møder angående Scrum, fordi de færreste faktisk har oplevet det virke - de har oplevet de her sære hybrid-versioner af Scrum og de konflikter det giver når man på forretningssiden stadig insisterer på at køre vandfaldsforløb.

Faktisk er jeg af den overbevisning at det er en fejl at Scrum kun forsøges indført på IT siden, skal det virke ordentligt skal forretningenssiden med. Vi har gjort forsøg i nogle af de helt store virksomheder hvor også forretningsfolkene og ledelsen blev inddraget i Scrum teams og udførte opgaver fra sprintloggen. Eks. opgaver som udarbejdelse af blue-print dokumenter, budget-planlægning, data behovsanalyse, user journey udarbejdelse og lign. som vi oprettede stories på, refinede og inddrog i vores sprints.

I starten var der en del skepsis - det er svært at ændre på folks vaner, men da vi afsluttede projektforløbet efter 6 måneder var begejstringen stor for denne måde at arbejde på og hvad vigtigere var at både vi IT folk og forretningensfolkene havde fået en meget større forståelse og respekt for hinandens arbejde - både det at være med til at refine sådanne opgaver, men især også review af resultatet er noget der er sundt for begge sider. Et andet interessant fænomen var at IT udviklingen til sidst i projektet var mindre kritisk end forretningsopgaverne og at vi nu var istand til at allokere IT udviklere til at arbejde på forretningsopgaverne istedet - faktisk med ganske stor success selvom det måske ikke lige er den type opgaver de normalt sidder med i det daglige.

Desværre kom der ny CEO til i virksomheden derefter og de agile eksperimenter døde der pga. reorganiseringer. Sådan er livet i Enterprise :-)

15. februar 2017 kl. 15:34
Agilefall og watergile: Virksomheder går i stå i vadestedet på vej mod agil

There are lots of good arguments for CI/CD, unit testing, integration testing etc. It is however an evolving area seeing changes to best practices almost yearly, which is probably the reason Scrum is not too keen to go into these implementation details.

Scrum is a framework based on universal best practices and allowing quite a lot of freedom for the implementation placeholders. These placeholders exists because what is the best implementation may vary due to many factors, such as organisation size, the product being developed, team composition etc.

I am not objecting against the general trend we see at the moment that goes towards automating things to the point where we can release 1000 times a week - there are many project types where this is great.

All I am saying is that this is an extreme agile process and I would be more than happy if we can start by at least getting Enterprises to work in a standard agile process. And for Enterprises it is not always so easy to be this agile - there are things such as government regulations, quality assurance and data-integration from teams spread out across the world that you have to factor in. These things will slow you down, sometimes to the point where delivering on a 2 week sprint is quite an achievement! Let's start by celebrating that.

15. februar 2017 kl. 13:53
Agilefall og watergile: Virksomheder går i stå i vadestedet på vej mod agil

Hvorom jeg er helt enig i at virksomhederne er fanget midt i vadestedet og at agil transformation i Enterprise er op ad bakke, er jeg også bekymret for den definition af Scrum der gives udtryk for i denne artikel.

Scrum siger ikke noget om at det handler om at kunne deploye 1000 gange om ugen. Efter bogen siger scrum at hvert sprint leverer en potentiel releaseable ny version af produktet - en såkaldt incremental. Dvs. er dit sprint på 2 uger, så er forventningen at der kan releases en ny version hvis man måtte ønske det hver 2. uge. Det er stadig vanvittig meget oftere end et typisk vandfaldsforløb hvor en ny version kan tage halve eller hele år, men det er altså også meget mere opnåeligt for Enterprise virksomheder end scenariet om at skulle kunne release adskillige gange dagligt - vi skal også passe på ikke at skræmme folk ved at få det hele til at fremstå uopnåeligt og urealistisk.

Scrum efter bogen er et framework - der er mange ting som man kan implementere indenfor dette framework, som komplimenterer Scrum godt - herunder automatisk test, CI/CD, TDD osv, - men rent faktisk siger Scrum intet om dette. Det er værktøjer du kan bruge der understøtter en agil process , men du kan også lade være hvis et andet setup passer jeres organisation bedre. Det synes jeg er en vigtig pointe.

15. februar 2017 kl. 07:53
Telmore-autentifikation: Send de første tre tegn af dit kodeord i klartekst

Apropos når man nu ved hvordan hr og fru Jensen og kundeservice fungerer så sker det nok også ganske ofte at folk bare oplyser deres fulde passwords.

Enten fordi de ikke hørte spørgsmålet ordentligt, vil være lidt ekstra flinke ved den søde supporter, er ekstra ivrige for at bevise de er hvem de er og nåh ja hvis ham supporten kan se de første 3 tegn så er det jo en rimelig antagelse hvis man ikke er techie at han nok alligevel også kan se resten på skærmen

14. februar 2017 kl. 18:10
Telmore-autentifikation: Send de første tre tegn af dit kodeord i klartekst

Ebbe: Det er vel altid forudsætningen når vi taler om hash-sikkerhed at scenariet er at dataene er blevet kompromitteret og at dette tillader en angriber at udføre offline brute-forcing på dataene.

Men du har da ret i at der ikke er noget problem hvis Telmore's systemer er så sikre at de ikke kan hackes - men hvis ikke engang NSA kan holde deres data fortrolige så er der ikke meget håb imo.

Den største trussel kommer som regel indefra - som f.eks. når en sysadmin synes det lige er lidt lettere at smide database backuppen op så den kan hentes over http host newz.dk host.

14. februar 2017 kl. 17:54
Telmore-autentifikation: Send de første tre tegn af dit kodeord i klartekst

Det gør absolut ingen forskel om de første 3 tegn er gemt som klar-tekst eller er hashet. Det er også ligegyldigt om der er benyttet individuelle salts eller ej da 3 tegn ganske enkelt er for lidt og da vi på forhånd ved at der altid er tale om præcis 3 tegn.

Det vil tage 10 minutter at skrive algoritmen og formentlig under 1 sekund processeringstid før det hele er forvandlet til klar-tekst.

Ergo Telmore har effektivt skåret 3 tegn fra længden af alle brugeres passwords, hvilket formentlig bringer mere end 90% af brugerdatabasen ned i et område der selv med korrekt og sikker hashing kan knækkes inden for rimelig tid hvis vi antager gennemsnitskodeord omkring de her 8 tegn folk typisk anvender.

14. februar 2017 kl. 17:36
Nyt udspil til offentlig it-arkitektur: Vi gider ikke flere spaghetti-integrationer

Grundlæggende enig, at forsøge at standardisere på arkitekturniveau er håbløst og en forældet tankegang der har vist sig meget dyr i praksis.

Standardiser på snitflader og dataformater og slip ellers arkitekturbeslutningerne fri. For mange tværgående krav forsinker og fordyrere projekterne.

9. februar 2017 kl. 15:00
Philips satsede på serverless: Udviklingstid gik fra tyve mandeår til tyve måneder

Jeg synes det er problematisk at man binder sig så tæt op på en given cloud-udbyders arkitektur. Det har vi før brændt nallerne på med Azure der ikke kunne leve op til forventningerne og så er det altså problematisk at skulle migrere tilbage til en mere klassisk platform.

Hvad gør man hvis det viser sig at man af den ene eller anden årsag er nød til at køre det her som en on-premise løsning?

18. januar 2017 kl. 07:57
Har du talt forretning i dag?

Efter at have brugt det sidste halve år på at udvikle et projekt forretningen havde lavet 2000 siders kravsspecification til inden vi gik igang, må jeg erkende at der rundt omkring altså også er et rimelig stort behov for at forretningen tør at snakke med IT-folk...

Hvis vi som IT-folk bliver bedt om at bygge Titanic, så gør vi det - men hvis vi undervejs i processen finder ud af at det forretningen i virkeligheden havde brug for var en robåd, så er det temmelig spildt indsats.

For at få success så skal grænserne mellem IT og forretningen udviskes - så længe man sidder i hver sin afdeling og kommunikerer via mellemmænd, så skal det gå galt.

7. december 2016 kl. 19:29
De stærke argumenter for agile metoder i enhver organisation

Det var bestemt heller ikke ment som at tidl. projektledere og lign. ikke kan blive super gode scrum mastere eller product owners, men som du selv nævner så kræver det vilje, passion og ikke mindst oplæring.

Hvis vedkommende tilgengæld ikke er parat til en sådan omstilling og egentlig interesserer sig mere for mere traditionel top-down styring, så bliver det næppe en success - og det ses desværre ganske ofte, fordi der ikke er blevet investeret nok i at sikre at medarbejderne har forstået værdien i scrum.

Så ender man nemt med at tingene i praksis kører videre som hidtil, blot under et nyt navn og med en lidt anden mødestruktur - vaner og virksomhedskultur er svære at ændre og kræver en yderst aktiv indsats.

5. december 2016 kl. 21:34
De stærke argumenter for agile metoder i enhver organisation

Scrum er for mange desværre ikke meget andet end endnu et buzzword der lover at løse alle problemer. Det skyldes først og fremmest at det generelt implementeres forkert.

Et par eksempler på hvordan det ofte sker:

  1. Den tidligere projektleder gøres til enten Scrum Master eller Product Owner (eller begge dele) og derefter arbejder vedkommende videre efter samme mindset som tidligere.
  2. Management er blevet enige om at Scrum er smart, men de ansatte har begrænset forståelse for scrum og forventer at blive fortalt hvad de nu skal gøre - man undlader at sende folk på kursus og dermed ender det med folk arbejder videre efter samme mindset som før.
  3. Man laver stadig en kæmpe kravsspecifikation og dokumenterer systemet på 2000 sider, men vælger så at implementere dette med sprints og scrum møder etc., hvorefter man nu betragter dette som agil udvikling.
  4. Man glemmer at give udviklerne ansvar for opgaverne, hvilket både inkluderer at udviklerne selv vælger hvor meget de kan gennemføre i et sprint og gives lov til at organisere sig bedst muligt i forhold til hvem der laver hvad i sprintet.
  5. Man glemmer at lave veldefinerede opgaver, hvor alle spørgsmål er afklaret inden udviklingen går igang - dermed mistes en stor del af effektiviteten ved scrum.
  6. Man glemmer at den enkelte udvikler også skal afsætte tid i løbet af sprintet til at refine opgaver til næste sprint, så man ikke skal sidde og glo 10 mand på hinanden i et mødelokale imens der nu laves ad-hoc refinement istedetfor sprint planning - dermed ryger hele effektiviteten ved sprint møderne.

og jeg er sikker på der er mange mange flere...

Men jeg har også oplevet på egen krop hvad effektiv scrum vil sige og hvilket boost det kan være både i effektivitet og bedre arbejdsmiljø (Skal man kun indføre ét tiltag fra Scrum, så må det være retrospektion - det er guld værd for at få klarlagt og lavet actions for alle de små ting der går folk på i hverdagen).

5. december 2016 kl. 17:54
Skal en arkitekt kode? (Skal en murer male?)

Nu er det jo rigtig meget vandfald det der beskrives her og bevares, jeg arbejder selv som konsulent i enterprise virksomheder og ved hvor svært det er at ændre på kulturen.

Men der er en grund til at Scrum ikke anerkender Arkitektrollen, men betragter arkitektur som en naturlig del af udviklernes ansvarsområde og som grundlæggende set bør udvikles lige så agilt som produktet selv. Dermed ikke sagt at det ikke er tilladt at tænke lidt længere ud i fremtiden når man sidder med noget, men det handler ikke om at lave en 6 måneder forundersøgelse hvor man får det hele på plads inden der skrives en linie kode.

I de store virksomheder vil der stadig være et behov for Enterprise Arkitekter, som nok oftest vil stå udenfor Scrum teamet, men assistere med viden om generelle retningslinjer for forretningens systemer og måder at flytte data rundt på, krav til dataene, sikkerhed osv. - de er reelt repræsentanter for forretningen.

Men Application Architecture rollen er reelt døende efterhånden som vi overgår mere og mere til agil udvikling, det er færdigheder som alle udviklere bør forsøge at tilegne sig og det er svært at være på toppen af Application Architecture hvis det er 10 år siden man sidst har skrevet en stump kode, dertil går udviklingen alt for hurtigt og derfor er det nød til at være en kernekompetence blandt udviklerne selv.

12. november 2016 kl. 21:01
Windows 10 taber markedsandele

Hvorledes har man mistet markedsandele hvis man er gået fra 22,53 procent til 22,59?

Det er ikke så overraskende at væksten er lavere nu hvor det ikke længere er gratis at opgradere, men det ville være overraskende hvis Windows 10 decideret var gået tilbage i markedsandele.

3. november 2016 kl. 08:17
Kør C++ og C i browseren: WebAssembly er klar til test hos webudviklere

Kan godt være det ikke er populært at melde ud at målet er at erstatte javascript og der vil selvfølgelig også blive skrevet massere af javascript i mange år endnu.

MEN det bliver altså svært at se hvad vi skal med javascript når først WebAssembly har vundet nok indpas og flere sprog kommer til end blot C og C++.

imo kan det kun gå for langsomt.

1. november 2016 kl. 14:03
Sådan får du et arbejde - og beholder det!

Arbejdsgivere ønsker aldrig at der bliver talt om løn mellem de ansatte, men det er altså uhyre sjældent til de ansattes fordel. Alt for mange bliver undskyld udtrykket, taget i røven, fordi de ikke er klar over deres markedsværdi.

Det er derfor generelt vigtigt at finde ud af hvad lønniveauet reelt er i den virksomhed man er i - det skal aldrig bruges direkte i en forhandlingssituation, men det kan bruges strategisk til at finde et godt udgangspunkt i en forhandling.

En sådan samtale bør altid foregå diskret under 4 øjne og uden for arbejdspladsens område - eksempelvis over en fredagsøl på den lokale og tages med den eller de af kollegaerne man har det bedste forhold til (og generelt bør man undgå at tage den samtale før man har været en 3+ måneder på stedet).

Jeg har aldrig oplevet at det har skabt den omtalte dårlige stemning, hvis det gøres på en diskret måde og man forstår at bruge det strategisk istedetfor konfrontatorisk. Man skal også forberede sig på at blive "skuffet", der er ofte folk på stedet der af forskellige årsager tjener mere (eller meget mere) end en selv - løn handler ikke blot om færdigheder og derfor skal man også passe på med at sammenligne sig selv på den måde (eksempler på andre ting kunne også være anciennitet, udvist loyalitet, personligt forhold til chefen og lign.)

Brug istedet din viden om lønniveauet til at vurdere om du skal gå efter eksempelvis en 5k lønstigning ved næste samtale eller 2-3k måske er mere realistisk i forhold til hvor du ligger. Vel og mærke som et forhandlingsudgangspunkt hvor man realistisk forventer at ende lavere.

31. oktober 2016 kl. 04:08