Ikke så smidig likevel

I TU nr 38 17/11 2011 fremmes det en advarsel om at smidige metoder går utover det grunnleggende ingeniørhåndverket.

IT-arkitekten Simon Brown mener at arkitekturen kan lide dersom man har en rendyrket smidig tilnærming til IT-utvikling. Han tillegger bransjen et ønske om å være kjappe og effektive, og mener dette er årsaken til problematikken. Et eksempel han trekker frem er et system som gikk i produksjon med passordet “password”, og således stilte seg lagelig til for hack.

Løsningen på dette skal ifølge Brown og Bouvet være å kombinere smidige metoder med tradisjonell tankegang. Dette for å redde software engineering.

Fra Teknisk Ukeblad nr 38, 17. november 2011

Vi mener ingen metoder kan forhindre oss i å jobbe feil. Metoden er teori, produktet du utvikler er praksis. Teorien til smidig tankegang er like enkel som den er krevende å gjennomføre: Jo tidligere og hyppigere vi kan få tilbakemeldinger, desto kortere tid bruker vi på å realisere gevinster.

Tilbakemeldinger kommer fra en rekke kilder, og dyktige utviklere vet hvilke kilder de skal oppsøke. Brukere er en åpenbar kilde, som de fleste oppsøker. Forretningsutviklere, driftere, brukeropplevelse-eksperter og arkitekter er andre eksempler. Jeg kjenner ikke det omtalte “password-prosjektet” fra innsiden, men jeg tillater meg å spekulere i om utviklerne oppsøkte tilstrekkelige tilbakemeldingskilder før de gikk kjapt – men ikke effektivt – i produksjon.

Vi ser tradisjonelle selskaper der den minste arkitekturendring krever store seremonier, politisk spill og tautrekking for å bli implementert, som regel kvartaler etter at behovet oppsto. Implementasjonen blir gjerne også ugunstig, fordi den i slike prosesser alltid blir påvirket av agendaer, som ikke er relevante. Konsekvensen er en metode som hverken er kjapp eller effektiv. Det eneste en slik tankegang fremmer er svært effektive blaim games. Det blir som tittelen til artikkelen ganske riktig påpeker: Ikke så smidig likevel.

Det er mange utfordringer knyttet til innføring av nye tankesett. En av dem er at gamle roller blir utfordret. Med smidig utvikling ønsker vi ikke den klassiske arkitekten lenger, fordi arkitektur skal være utviklerteamet sitt ansvar. De må imidlertid gjerne benytte arkitekter som kilde til kunnskap. Det kan vi anbefale, iallefall i en overgangsperiode.

Smidig tankegang gir oss et konkurransefortrinn gjennom å skape selvstendige enheter som har tilstrekkelig kompetanse til å finne de beste løsningene, gjennom små iterasjoner som i seg selv skaper mye lærdom. Tar enheten avgjørelser uten å oppsøke tilstrekkelige tilbakemeldinger – ja, da gjør de rett og slett ikke jobben sin. Og når noe går galt har de heller ikke muligheten til å skylde på en storebror, det være seg en arkitekt eller andre skrivebordsgeneraler.

Det er når teamet eier løsningen, at de også finner løsningene.

Dersom du står ansvarlig for et smidig utviklingsløp, vil vi heller anbefale deg å forbedre den iterative prosessen, enn å skape rom for utdaterte roller og seremonier. Spør heller teamet ditt jevnlig: Hvilke kilder til tilbakemelding benytter dere nå? Hvilken ny innsikt fikk dere fra forrige produksjonsetting? Hvilke kriterier legger dere til grunn for deres arkitekturvalg?

Endringer kan være smertefulle, men de er betraktelig hyggeligere enn å bli akterutseilt av en konkurrent – som ikke fokuserer på å jobbe kjapt – men derimot klarer å jobbe effektivt. Skal IT-bransjen lykkes med gevinstrealisering må vi slutte å kurere symptomer hver gang vi får problemer med å endre oss.

1 Comment

  1. Right! It’s certain that many “agile” projects are not executed well and we shouldn’t judge the method from its incorrect application.

    The point of agile isn’t to deliver fast (i.e. concentration on new functionality while ignoring everything else). The point is quality: that is delivering what is actually needed (as opposed to what people may think they need) w.r.t. business needs and technical constraints. The main idea is that the development is empirical, driven by experience and feedback – instead of being speculative (“we know what the reality is and this can design perfectly what is to be done”) as the “traditional” methods. Thus non-functional requirements and architecture have equal place as functionality – based on what the constraints and requirements are. (Though some teams may easily forget that.) But the architecture must be agile, empirical – starting with a “simple” architecture to satisfy the top-priority requirements (based on risk and business priority) and evolving based on feedback. The failure of the “traditional architecture” that tries to design everything up-front and success of an agile one is well presented in the Smidig 2011 talk Skalere til Petabytes (http://vimeo.com/32086819).

    Regarding the role of architecture in an agile team, this talk is of interest: Arkitektrollen er nødvendig i (smidige) prosjekter! (http://vimeo.com/32086722)

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s