Innovasjon i større organisasjoner
Mange større bedrifter har innovasjon høyt på agendaen og streber etter å øke sin innovasjonsstyrke. Det viser seg imidlertid vanskelig, hvor utfordringen hos mange ligger i selve bedriftskulturen. Innovasjon handler om evnen til å fornye og tilpasse produkter, tjenester, prosesser etc for å være konkurransedyktige i sitt marked. De fleste er enige om at det finnes bedre og mer helhetlige måter å drive innovasjon og verdiskapning, men har vanskeligheter for å finne de rette virkemidlene for å få det til å skje i praksis. Så hva skyldes dette?
Det viser seg at problemet delvis ligger fundert i frykten for å miste kontrollen (eller følelsen av å ha kontroll). De selskapene som har lykkes med innovasjon har bygget hele sin bedriftskultur hvor det å lære, samt validere læringen, er den viktigste styringsparameteren. De har bygget en lærende organisasjon. Hva skal til for å bygge en lærende organisasjon?
Den nakne sannheten om IT-prosjekter (Del II)
Som jeg lovet i DEL I, så skulle jeg dele mine erfaringer om hvorfor det er viktig å gjøre kunden god i egen organisasjon. Jeg skal også røpe noen ukonvensjonelle triks som viser hvordan du gjør dette mest effektivt.
Det vil hjelpe om vi ser dette i kontekst av tradisjonelle IT-prosjekter. Eksempelvis betyr dette at kundens prosjektleder eller produkteier, som har fått et leveranseansvar internt, vet at det egentlig kun er TO ting som betyr noe; at det leveres “noe” til avtalt tid og budsjett. Resten er i praksis underordnet.
Jeg kunne godt skrevet et helt blogginnlegg om hvor UENIG jeg er i den tradisjonelle prosjektmodellen, hvor leverandør setter nytt system i produksjon og overleverer til linjen i mottagende organisasjon. Faktum er at en denne modellen virker mot sin hensikt som er å oppnå en definert forretningsmessig verdiøkning. Men, det får vi diskutere en annen gang. Tilbake til dagens tema…
DEL II
Som konsulent har du et ansvar for å gjøre kunden god i egen organisasjon
Husker du historien om da jeg skulle kjøpe meg nye ski fra del 1 av denne bloggserien? (hvis ikke kan det være greit å friske opp minnet før du leser videre). Hva nå om jeg skulle kjøpe ski til kona. Med bestilling fra kona.
Hva ville en dårlig selger gjort? For det første så ville han ikke brydd seg om å finne ut hva dine reelle behov er (og i de fleste tilfeller så vet vi jo knappt det selv). Deretter ville han spurt deg hvilke type ski og merke du har tenkt deg. Hvis du i beste fall er så ærlig at du innrømmer å ikke helt vite det selv, så har man fortsatt en liten sjanse for at vedkommende innser at han må tilkalle forsterkninger. I realiteten ender man som regel med at selgeren finner frem 2-3 vilkårlige alternativer som du presenteres. Dette hjelper ikke særlig.
Hva gjør en god selger? Han får tankene dine bort fra pris og fokuserer på at utstyret skal passe med ditt behov og ønskede kjøreopplevelse. Det er tross alt det du vil huske resten av sesongen (prisen husker du i verste fall frem til neste lønning eller skitur).
Denne historien handler ikke om hvorvidt selgeren er sleip og har et underliggende ønske om å prakke på deg mest mulig. Den handler om konsekvensene av å føye seg etter kunden for å fremstå “hyggelig” i stedet for å gjøre kunden en ordentlig tjeneste og lære han mer om sine egne behov og presentere noen relevante løsningsalternativer. Hvis noen kommer og spør om råd, så er det som oftest fordi man trenger rådgivning. Anta da ikke at vedkommende kjenner alle sine behov. POENGET her er om man klarer å finne en løsning som vil fungere – for kona – på sikt. Det er stor fallhøyde for meg som “kundens prosjektleder” om man ikke lykkes.
Dersom kjøreopplevelsen for kona ikke er god i det lange løp pga skivalget, så hjelper det ikke lenger om skiene hadde riktig farge eller var billige nok i utgangspunktet. Opplevelsen går fra god til dårlig. Vi klarer ikke å gjøre kunden god i egen organisasjon hvis de alltid må gå fra gode til dårlige nyheter.
Bygg så store buffere du kan, men ikke si noe til kunden
De færreste produkteiere eller andre kunderepresentanter har noen formening om hvor lang tid det tar å implementere funksjon x og funksjon y. Hva det koster. En målsetning er da at man unngår å gå fra et estimat til et høyere tall i faktisk forbrukt tid. Det beste du kan gjøre – for begge parter – er å legge til grunn et best mulig rasjonale for ditt høyeste estimat.
Selv om kunden er aldri så misfornøyd med tallet du presenterer (fordi de hadde håpet at det skulle være lavere) så vil man med større trygghet kunne forklare i sin egen rapport til intern ledelse hvorfor dette er slik (intern ledelse har heller ingen forutsetning for å vite hva funksjonen koster, men forholder seg naturlig nok til budsjettet eller tidligere estimater).
Skulle du være så “snill” å gi kunden det laveste estimatet, så er risikoen langt større for at det kommer ubehagelige overraskselser senere. Ingen liker å gå fra gode nyheter til dårligere nyheter. Alle liker å gå fra dårlige nyheter (høyt estimat) til bedre nyheter (levert under estimat). Skulle det vise seg at de dårlige nyhetene (høyt estimat) forblir dårlige nyheter (leveres på tid), så har man med tiden vent seg til tanken. Det gjør ikke så vondt lenger.
Bare tenk dere forskjellen på om man i første scenario kommuniserer et “snilt” estimat på 50 timer, hvorpå sluttresultatet blir 75 timer. I scenario to argumenterer du først for et estimat nærmere 100 timer, hvorpå endelig forbrukt tid ender på 75 timer. Hva er å foretrekke?
Det er konsulentens ansvar å lære opp kunden
Man kan ikke forvente at kunden som til vanlig jobber med et helt annet domene, skal vite hvordan et komplekst system som IT-utvikling må håndteres. Som proffesjonelle utøvere innenfor utvikling av IT-løsninger, må vi bistå en kunde og deres organisasjon konsekvensene av sine valg (både fordeler og ulemper).
Hvorfor skal vi alltid starte med å sende ut minst fem endringsmeldinger i løpet av de to første ukene i et fastprisprosjekt? Det er for å lære kundene effekten og resultatet av å “sikre seg” gjennom fastpris-avtaler. Gjør man ikke dette, så vil man for det første ende opp med at kunden ikke forstår at det koster å omprioritere ofte (det er krevende å endre kontekst ofte).I tillegg er det viktig at alle parter forstår hvordan den underliggende konsekvensen av å kjøre fastpris-prosjekter er at a) kunden ikke blir så opptatt av hva som er innenfor eller utenfor omfanget og b) leverandøren blir veldig opptatt av å ikke inkludere mer enn nødvendig i kravene. Og tilslutt endre man opp med å bruke altfor mye tid på å diskutere hva som er utenfor og innenfor oppdraget…
I smidige prosjekter sier man at man omfavner endringer. Det betyr ikke at det er uten kostnad å omprioritere og bytte kontekst ofte. Grunntanken her er at man ikke skal låse seg til en detaljert krav-/løsningsspesifikasjon gjennom et prosjekt.
Vi har alle behov for å føle oss trygge
Uansett hvilken stilling og rolle vi har fått i samfunnet, så har vi alle de samme grunnleggende behovene. Det må vi aldri glemme.Helt avslutningsvis har jeg valgt å sitere et utdrag fra en av mine tidligere bloggartikler (og starten på noe som kan bli en bok en dag), “People. Culture. Fire. A gut feeling.“:
“As a human being I am filled with emotions. Sometimes I laugh. Sometimes I cry. Sometimes I get upset, even though I´m not sure why. Sometimes I can´t control my emotions. Sometimes my pride gets in my way – in everyone’s way. Please don´t fight me. Try to see my perspective. Help me, and I will want to help you. I´m only human.”
I DEL III vil jeg dele mine erfaringer fra hvordan vår streben etter å føle kontroll og måten vi organiserer oss i realiteten undergraver vår evne til å optimalisere helheten og nå våre mål.
Bang
Den nakne sannhet om IT-prosjekter (del 1)
Om PROSJEKTSTYRING som du ikke lærer på kurs eller leser om i bøker
Hvorfor skriver jeg denne serien med blogginnlegg om prosjektstyring?
Fordi jeg ønsker å dele egne erfaringer og høre andres synspunkter om den underliggende psykologien i IT-prosjekter, og årsakssammenhenger som man ikke lærer om på kurs eller i bøker, men som er realiteten. IT-prosjekter er som egne økosystemer hvor vi må evne å gjøre bærekraftig for å lykkes. Vi må forstå hvordan enkeltelementene i dette systemet gjensidig påvirker hverandre og hva som optimaliserer helheten (understøtter primærmålet).
Skjønner vi dette så vil vi også i større grad evne å skape bærekraftige endringer i organisasjoner, men vi må gjøre det i små steg – hver dag (Kaizen).
Det er noe av det samme som Jurgen Appelo tar opp i sin nye bok Management 3.0, når han snakker om “Complexity theory” som bl.a handler om å forstå kompleksiteten i å lede endring i en organisasjon eller blant en gruppe mennesker.
Husk å dele dine erfaringer og synspunkter som kommentar til denne artikkelen når du er ferdig!
Skikjørere på vei opp mot en av toppene i Lyngsalpene
DEL I
“Vi styrer våre egne valg” – en sannhet med modifikasjoner
Jeg går inn i en sportsbutikk og skal kjøpe nye ski til skisesongen. På vei inn minner jeg meg selv på mitt “budsjett”.
Selgeren sier: – Hei, hva kan jeg hjelpe deg med?
Jeg sier: – Jeg skal ha nytt alpinutstyr. Sånne carvingski. De gamle fungerer ikke så bra lenger (Jeg tenker: “De er ikke ødelagt eller noe, men jeg føler ikke akkurat at jeg følger med i utviklingen”)
Selgeren sier: – Det finnes ulike alternativer, som varierer litt i pris ift behov og ønsket kjøreopplevelse. Fra kr 4000 til kr 10 000. Hvor mye kjører du? Mest off piste eller i preparert løype?
Jeg sier: – Ja, skjønner. (Jeg tenker: “Det eneste jeg skjønner er at jeg må revurdere budsjettet mitt.”). Jeg kjører mest i bakke, men også en del off piste (Jeg tenker: “I realiteten har jeg hatt 3-4 turer i sesongen de siste 5-6 årene, hvor jeg kun ved to tilfeller har kjørt i løssnø, som skyldtes at preppemaskinen ikke hadde kjørt bakken ennå. “)
Selgeren sier: – Hvis skal kjøre mest i preparert løype, så vil jeg anbefalle disse skiene. Bestselger, som også fungerer fint om det er litt løsnø i bakken. Ikke fullt så bra om du skal gå mye toppturer med pudderkjøring. Skiene koster kr 4999, men vi har de også i et pakketilbud med støvler, bindinger og staver til kr 8 900. Vi har solgt masse av disse. Jeg kjører selv på fjorårsmodellen og hadde en sinnsyk god opplevelse i de franske alpene. Da har du utstyr i mange år fremover. Aksel Lund Svindal kjører med samme merket.
Jeg sier: (Jeg tenker: “Aksel Lund Svindal – kult!. Det må jeg bare fortelle gutta! Han sa jo også at det var en bestselger. Nå må jeg bare ikke virke for ivrig. Prute litt”). Det var litt stiv pris, synes jeg.
Selgeren sier: – Vi har også andre ski som er på tilbud. Bl.a et par fra en modell som utgikk i fjor.
Jeg sier: – Men, som du sier så vil jeg ha utstyret i mange år fremover. (Din rasjonelle hjernehalvdel rettferdiggjør valget og valget ditt bør fremstå veloverveid.). Det er greit. Jeg tar dem. Ha´kke tid til å stå her. Må komme meg ut i pudderet, vet du! (Jeg tenker: “Pudder? Takket jeg ikke nettopp ja til ski som var best egnet i preparert løype?…”). Takk for hjelpen!
Denne historien illustrerer i hvor stor grad den emosjonelle delen av hjernen vår påvirker våre valg. Det meste handler om det vi opplever som “magefølelsen” (som egentlig er Det Limbiske System i hjernen som driver følelser og oppførsel hos mennesker) og gir oss en sterk indikasjon på hva vi virkelig ønsker, mens vårt rasjonelle “jeg” febrilsk jobber med å rettferdiggjøre valget. Dette betyr i praksis at vi er mer opptatt av hva andre mener om oss, enn resultatene vi skaper. Det er et helt grunnleggende og naturlig instinkt for de fleste av oss.
Hva gjør en god konsulent her?
Det er ikke selgeren som tar valget, han bare legger frem alternativene så jeg skal kunne gjøre det beste valget utifra mine behov. Problemet oppstår så snart jeg ikke helt vet hva mine behov er. Kanskje burde jeg lånt med meg to par ski og kjørt dem en uke, for så å kjøpe paret som fungerte best i “produksjon”?
En virkelig god selger ville foreslått nettopp utlån av ski, for å sikre at jeg gjorde et godt valg.
Denne problemstillingen er velkjent når man jobber med produktutvikling og er nærmere utredet i artikkelen om “The User Feedback Problem“
Hovedpoenget mitt her er at vi må bedre forstå det underliggende behovet hos våre kunder. Vi må både forstå hva bedriften trenger, samtidig som vi forstår hva kundens produkteier eller prosjektleder trenger for å gjøre gode valg. Forstå hvilket enormt press det innbærer å stå mellom leverandøren og sin egen ledelse. Det holder ikke å bare avfeie folk med “Å, de skjønner jo ingenting!”.
Hvis kunden forstår hvorfor og selv kan ta nødvendige valg fordi vi er flinke til å presentere valgalternativene med fordeler og ulemper, så blir det enklere å forsvare det mot egen styringsgruppe eller ledelse. Da er også sannsynligheten større for at man vil se på arbeidet som vellykket fordi man tok det beste valget i rådende situasjon (man hadde tross alt ikke noen bedre alternativer).
Som konsulent så forplikter du å gjøre mer enn “jobben din”, om det være seg programmere, designe eller å teste. Du forplikter å gjøre kundens jobb så enkel som mulig. Husk at det er ikke engang sikkert vedkommende har bedt om å bli prosjektleder eller produkteier for et IT-prosjekt (i tillegg til jobben i linja). Ta ansvar og bry dere om hverandre. Vi er ikke roboter, men mennesker med kjøtt, blod og følelser – masse følelser.
Hvilke tanker vekker dette hos deg?
Neste gang skal jeg ta utdype dette som er din viktigste oppgave som konsulent, rådgiver eller leverandør; nemlig å gjøre kunden god i egen organisasjon.
Bang
The splendid long iterations
Some times, we want longer iterations.
We waste to much time in meetings and other activities associated with iteration turnovers, so we decide to extend the duration of the iteration. Let’s make those planning meetings, estimation workshops, retrospectives and what-have-you happen less frequently. We might even get some work done, right?
Sadly, longer iterations don’t change how customers interact with us. We continue to get expedite requests, like having to fix a bug (which obviously shouldn’t have been there in the first place). Now that iterations are longer, we appear less responsive to our customers, which of course wasn’t the idea at all. To compensate, we could introduce mid-iteration releases?
Moreover, with longer iterations management feels less in control, because feedback is less frequent, and problems seem to pile up more now than before. That wasn’t the idea in the first place, so they feel compelled to introduce stricter reporting. How about a mid-iteration report?
Finally we get to the iteration turnover. We have experienced flow and feel great, except lack of coordination within and between teams makes our stuff not work that well together when we integrate. We decide to talk more. So we introduce a regular integration planning meeting with the other development teams. Would twice each iteration do?
Making iterations longer can be comfortable for a while. It feels better to work longer periods at a time undisturbed, and it feels better to spend our working time developing as opposed to attending meetings.
What's the scent of your learning cycle?
Longer iterations are however nothing more than a dangerous painkiller, which conceals the real problems we have. Double the iteration length, and iteration turnover gets four times as painful and half as useful. The reasons we have iterations in the first place is to create learning opportunities. Why would we want less of them when we could have more?
Longer iterations create room for more waste, forcing us into compensations that drive more compensations. We get iterations within iterations. We get wasteful reporting. We get less coordinated and produce more bugs. We stop doing retrospectives because we don’t have time to follow up on the resulting action points anyway. The resulting problems call for more meetings, and we get tempted to extend the iterations even further, which makes iteration turnovers even more painful. In the end we’re so sick of iterations that we start longing for waterfall.
Taiichi Ohno, the great engineer and systems thinker at Toyota had a helpful analogy about rocks and water. Imagine your process being a river with rocks on the bottom. The water is our level of comfort, and the rocks are everything which we shouldn’t be doing. Ohno calls them waste, which he defines as everything we do that doesn’t bring value to the customer. When the water level is high, we hardly see any rocks, hence the only way to find waste is to lower the water level. In other words, make ourselves less comfortable.
How does this translate to the pain of iteration turnovers? We do more of it. We have those turnovers so frequently that we have no other choice but to get good at it. In other words: When iteration turnovers are painful, we make the iteration duration shorter.
Here’s a question to ask our team: What would it take to go to half the iteration length, while keeping our current velocity?
We would have to make meetings shorter and more efficient. We would have to reduce the defect rate. We would have to make deployments faster. We would have to stay coordinated at all times, both within and between teams. We would have to follow up rigorously on action points from retrospectives.
That’s when we stop curing symptoms and start acting on root causes of problems. That’s when we start doing continuous process improvement.
That’s when we want even shorter iterations.
The user feedback problem
If you’re into agile, you’ve probably encountered this question: If iterating over user feedback is so fundamentally important, how come Apple has repeated success with their apparent one-off, non-iterative, grandiose launches of new products?
Is this the place for user feedback? (I told you once)
Agile skeptics love this argument. To them it’s a once for all win over advocates of frequent releases. They probably feel like Michael Palin in his surreal Monthy Python sketch with John Cleese, where they enthusiastically have an argument about whether they have an argument. Desperately fighting and imminent defeat after failing to stop arguing when “time’s up”, Cleese responds “I might be arguing on my spare time”, to Palin’s pointing-in-your-face-gotcha-finger.
“No you’re not”. “Yes I am”. “No you’re not”. “Yes I am” …
Similar surreal arguments happen in software companies. There are always someone who doesn’t want to go into production in short, regular intervals, and there are always someone who wants it.
So what’s Apple doing? Iterating on their spare time? Maybe the rest of us should look to Apple and grant the skeptics right. Stop nagging ourselves with those tedious deployments, not to mention the even more tedious user feedback. We’re talented developers, trained professionals, experienced craftsmen – let’s go with our vision and gut feelings just like Jobs did!
Both within the agile community and other places I encounter this misunderstanding disturbingly frequently. Moving on from the triumphant Apple argument, the skeptics continue: Users lack fantasy. They don’t know what they want, and will ask for solutions within a narrow mindset framed by whatever it is they use today. Henry Ford nailed it forever with his famous quote: “If I had asked people what they wanted, they would have said faster horses.”
This is where I think things get tricky: In a sense the skeptics are both right and wrong. It’s true that users lack imagination and even lie some times. Hence, they are right that we shouldn’t ask users what they want. They are however wrong about not frequently releasing to production.
The fact that users don’t know what they want is no excuse not to iterate.
We should still interact with our users – and we should use our software as medium. First and foremost we must have empathy with our users. We need to fundamentally understand them, better than they understand themselves. If we do ask users questions, we don’t ask about features. We ask how they feel when logging into their computer. We ask what’s their favorite software, and why. We ask why they are using our product.
When iterating cleverly we're somewhere in the middle. (Comic: Calvin & Hobbes)
From this insight we might get tons of ideas for features. We verify them one at a time, quickly. We refine them and verify the refinements in a tight build-measure-learn loop: Cut a feature into the thinnest slice possible, and deploy it. Monitor what happens. Deploy two different versions of the same feature and monitor what happens. Pull a feature which is hardly used and see what happens.
What’s interesting about this approach, is that neither the overacting agile crowd, nor the agile skeptics will agree with you. To them you’re either not listening to your users, or you’re letting them dictate a product without direction. (Thanks to Kent Beck for this perspective).
From Eric Ries book The Lean Startup: We really did have customers in those early days – true visionary early adopters – and we often talked to them and asked for their feedback. But we emphatically did not do what they said. We viewed their input as only one source of information about our product and overall vision. In fact, we were much more likely to run experiments on our customers than we were to cater to their whims.
In the Scrum world there is a lot of discussion about a Definition of Done. Jeff Sutherland has a long list of steps that need to be carried out before a task is done. To me he’s missing the most important part: That you’re not done with a feature until you’ve analyzed the behavior of paying customers using it.
Focus groups, user dialog, staged usability tests in artificial environments and situations can all be sources of insight, but they can also be deceiving. The Proof of the Pudding is in the production usage data. Hence we should develop a way to quickly try out features, gather usage statistics, opinions and other knowledge. It might also be a good idea to recap statistics classes from the university days, make A/B-testing easy, and if your product is in the public, use sites like usertesting.com.
I don’t believe Apple isn’t iterating. Having hardware products they cannot iterate like a software company. Having a marketing strategy which builds up hype around spectacular launches calls for subtlety. But you don’t really think they came up with all those products without seeking insight into their users?
Arguments shouldn’t be about whether we release frequently or not. It should be about how we do it. So if you haven’t already, I encourage you to start a discussion with your team about sources of insight into users, tools for gathering such insight and what iterative strategy would support this.
You will be innovating before you know it.
@hauge2
Getting Started with Amazon Web Services and Fully Automated Resource Provisioning in 15 Minutes
While waiting for a new project, I wanted to learn something useful. And because on many projects we need to assess and test the performance of the application being developed while only rarely there is enough hardware for generating a realistic load, I decided to learn more about provisioning virtual machines on demand in the Cloud, namely Amazon Web Services (AWS). I’ve learned a lot about the tools available to work with AWS and the automation of the setup of resources (machine instances, security groups, databases etc.) and automatic customization of virtual machine instances in the AWS cloud. I’d like to present a brief introduction into AWS and a succinct overview of the tools and automation options. If you are familiar with AWS/EC2 then you might want to jump over the introduction directly to the automation section.
Ungdommen nå til dags
Ivar og jeg har holdt workshop for IT-elevene på Sandvika videregående skole. TV8-innslag fra workshoppen her. Temaet var smidig utvikling.
Jeg er alltid spent på utfallet av en workshop. Ved siden av mange tilfeldigheter spiller også bedriftskultur, motivasjon og trygghet inn på deltagernes evne til å løse oppgavene. (Litt på samme måte som med systemutvikling forøvrig). Denne gangen var det imidlertid ikke ansatte hos Aker Solutions, Widerøe, Statistisk Sentralbyrå eller andre profesjonelle systemutviklere som skulle i ilden. Hvordan ville de unge og uerfarne elevene prestere? Kom det til å bli for vanskelig for dem?
De fikk to oppgaver. Den første utfordret lagarbeid og prosessforbedring. Den andre utfordret planlegging og innovasjonsevne. Det var voksne oppgaver for et ungt publikum.
De klarte seg imidlertid svært godt, faktisk bedre enn de fleste. Spesielt flinke var de på å utfordre rammene for oppgavene.
Noe av poenget med oppgavene er nettopp å gjøre deltagerne mer bevisste på selvpålagte begrensninger, og det hadde disse ungdommene lite av. Dermed kom de også frem til løsninger tidligere enn normalt, i en inspirerende blanding av ungdommelig overmot, tett samhandling og evne til å jobbe målrettet uten sløsing.
Dette minner meg om en reklamefilm som gikk for noen år siden. Det kryssklippes mellom to grupper, den ene på kurs i å uttrykke følelser, den andre på fotballkamp. De stakkars kursdeltagerne er så stivbente i sine forsøk på å gi hverandre en klem at man blir – nettopp – helt beklemt av å se på. Lettelsen er tilsvarende når man ser gjengen på fotballkamp brøle og kaste seg rundt halsen på hverandre i vill begeistring når laget deres scorer.
Å uttrykke begeistring på en fotballkamp er en evne som må falle seg naturlig – den kan ikke instrueres på detaljnivå. Det samme gjelder team-arbeid og innovasjon.
Elevene angrep problemstillingene uten hensyn til egne begrensninger, verken som personer eller som team. Som en gjeng som trikser med en fotball, ble idéer fortløpende kastet ut, og sparket opp, ned eller ut. Like lett gikk de inn i de påfølgende diskusjonene om realisering. Deres manglende innsikt i teknologiske begrensninger var like mye en fordel for deres evne til kreativ problemløsning.
Min erfaring er at vi som profesjonelle fagfolk jobber motsatt. Vi tenker begrensninger og analyse først, og løsning etterpå. Klok av skade, vil kanskje noen si. Iallefall de som kjørte på som ungdom, og opplevde konsekvensene av å være ugjennomtenkt. Jeg tror imidlertid at vi overkompenserer på dette området.
Elevene hjalp oss iallefall innse at oppgavene de fikk er mer tiltrengt når man har mistet det ungdommelige overmotet. Jeg håper derfor de klarer å bevare energien sin gjennom studier og inngangen til arbeidslivet. Ikke bare er det bra for hver enkelt av dem, det smitter også over på omgivelsene.
Slik det gjorde på Ivar og meg 
The 3 Most Important Things I’ve Learned This Year
In Iterate we are mostly dealing with technology but why do we actually use technology? We use it because we want to help people achieve something – and in the process of doing that we have to cooperate and communicate with many humans. The human factor is far more determining for our success than any kind of technology could ever be. Why do most project fail? Because of a bad technology? No – usually it’s a failure of communication, leadership, process change. And this week I’ve learnt some very important things about this crucial human factor – and thus this post may well be the most valuable piece published here til now – or ever.
First, I’ve learned how we decide (and a project – IT or other – is nothing but a bunch of hundreds, millions of decisions, both small and big). To deal with the incredibly complex world around us, human brain has many decision strategies ranging from a very rational decision making to “gut feeling” decisions based on our emotions and subconsciousness. Every of these strategies is perfectly suitable for some situations (for example relying on emotions and intuition is often the best thing, conversely to what we’ve been thought) – and leads to suboptimal results (read: terrible failures) in others. Thus the single most important factor that determines how successful we are is our ability of metacognition, i.e. being aware of how we think, and thus being able to select the most appropriate strategy for the situation at hand. (Which might not be as easy as it sounds and may require that we “trick” our mind somehow, i.e. by distracting it or forcing it into a certain decision mode.) Jonah Lehrer documents that on the “Marshmallow experiment” – the children who knew that they got to distract themselves somehow not to eat the marshmallow, which they’ve been given, not only managed to wait those 15 minutes for another one but were also much more successful in their later lives – presumably because their ability of metacognition helped them to make better decisions more often.
I like writing unit tests but Java doesn’t make it particularly easy. Especially if you need to create objects and object trees, transform objects for checking them etc. I miss a lot a conscise, powerful syntax, literals for regular expressions and collections, conscise, clojure-based methods for filtering and transforming collections, asserts providing more visibility into why they failed. But hey, who said I have to write tests in the same language as the production code?! I can use Groovy – with its syntax being ~ 100% Java + like thousand % more, optional usage of static/dynamic typing, closures, hundreds of utility methods added to the standard JDK classes and so on. Groovy support for example in IntelliJ IDEA (autocompletion, refactoring …) is very good so by using it you loose nothing and gain incredibly much. So I’ve decided that from now on I’ll only use Groovy for unit tests. And so far my experience with it was overwhelmingly positive (though few things are little more complicated by the positives more than compensate for them). Read on to find out why you should try it too.
(The arguments here focus on Groovy but I guess similar things could be said about JRuby, Scala etc. – with the exception of Java code compatibility, which you only get in Groovy.)
Few examples
Some of the example below use some Groovy magic but don’t be scared. You can write Groovy just as if it was Java and only learn and introduce its magic step by step as you need it.
Bean construction:
def testBean = new Customer(fname: "Bob", sname: "Newt", age: 42)
// Java: c = new Customer(); c.setFname("Bob"); c.setSname("Newt"); c.setAge(42);
(Of course this starts to pay of if either you don’t want to create a constructor or if there are “many” properties and you need to set different subsets of them (constructor with 4+ arguments is hard to read).)
Reading a file:
assert test.method() == new File("expected.txt").getText()
// Java: buffered reader line by line ...; Note: == actually uses equals()
Checking the content of a collection/map:
assert customerFinder.findAll().collect {it.sname}.sort() == ["Lizard","Newt"]
// Java: too long to show here (extract only surnames, sort them, compare ...)
assert getCapitalsMap() == ["UK" : "London", "CR" : "Prague"]
Regular expressions:
assert ("dog1-and-dog2" =~ /dog\d/).getAt([0,1]) == ["dog1", "dog2"]
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.
