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 interesting part is not what the users say – it’s what they do, on a daily basis: 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.
Kaizen
Noen ganger er det vanskelig å være uenig.
For eksempel når man ser ord, som brukes så mye, overalt, at den egentlige meningen fortrenges til fordel for selvfølgeligheter ingen registrerer. Kvalitet er et slikt ord. Kompetanse er et annet. Kunnskap et tredje. Hva forteller det deg når en virksomhet sier de satser på kunnskap, kvalitet og kompetanse?
Meg forteller det ingen verdens ting. Ganske enkelt fordi nettopp alle i bransjen vår satser på kunnskap, kvalitet og kompetanse. Iallefall tilsynelatende.
Det skulle være moro å se et selskap overføre “rent a wreck”-konseptet til IT-bransjen. “Hos oss får du leie middelmåtelige ingeniører til en rimelig penge! De er rufsete i kantene og velbrukte, men du vet – slike traktorteknologer er kanskje gammeldagse, men desto mer slitesterke!”
Du verden, jeg kunne vært fristet til å kjøpe.
Så hvorfor er kommunikasjonen i vår bransje preget av floskler? Jeg kjørte nettsidene til noen typiske IT-selskaper, inkludert mitt eget, gjennom tagcrowd, og endte opp med følgende liste av ikke-meningsbærende ord:
Brukervennlig, faglig, kundetilfredshet, kunnskap, langsiktig, ledende, medarbeider, muligheter, samarbeid, smart, spennende, troverdig.
Ærlig talt: Er det mulig å ta noe annet standpunkt enn det disse ordene gir uttrykk for? Er det noen som er imot brukervennlighet og kundetilfredshet? Eller hva med medarbeidere? Noen som er imot medarbeidere?
Det neste naturlige steget i tankeprosessen blir å finne et uttrykk for våre faglige ambisjoner, der vi faktisk skiller oss ut. Det er en nyttig øvelse, som jeg kan anbefale alle å gjøre der de jobber. Forsøk å si noe som stemmer om din bedrift, men som du antar noen vil være uenig i. Og si for guds skyld fra til ledelsen om du ikke finner noe.
Kaizen er japansk og refererer til en filosofi om kontinuerlig forbedring. Umiddelbart liker jeg ordet fordi det gir meg en slik mystisk, asiatisk, Uma Thurman-ish følelse av noe sofistikert og tøft. (Jeg liker det også av faglige grunner.)
Om Uma Thurman bruker Kaizen vites ikke. Men ingen tvil om at hun er tøff.
Ordet Kaizen er imidlertid lost in translation. Kontinuerlig forbedring er jo nok et eksempel på en floskel, iallefall hvis man følger min ad hoc-definisjon: Hvem er vel imot å forbedre seg fra tid til annen?
Spør du meg, er en bedrift som faktisk gjør Kaizen et sted der du merker det allerede i resepsjonen. Det er en bedrift der alt du gjør, fra time til time, utledes fra et ønske om å forbedre seg. Forbedringer blir navet i det daglige arbeidet.
Hvordan arter dette seg i programvareutvikling? Det første mange tenker på er kanskje iterativt arbeid med jevnlige evalueringer. Min erfaring med vanlig praksis innen iterative metoder, er å inkludere et relativt kort evalueringsmøte etter hver iterasjon, lage seg en liten handlingsplan med noen tiltak som lever side om side med de andre, planlagte oppgavene. Jeg lar det være opp til deg som leser å vurdere om slik praksis er Kaizen eller jevnlige forbedringsforsøk.
Det nærmeste jeg har kommet Kaizen-liknende tilstander i mitt fag er lean startup-metoden (som du kan bruke selv om du ikke jobber i en startup). Om du har en time å avse, anbefaler jeg denne introduksjonen fra Eric Ries. Han mener programvare bør utvikles gjennom systematisk validering av antagelsene du har i ditt business case. Det betyr at du må ha et business case – og ikke en kravspesifikasjon – som utgangspunkt for arbeidet. Du jobber i svært korte iterasjoner og bruker all din tid på å skaffe tilbakemeldinger på dine antagelser om kundene og markedet. Ingen tilbakemeldinger er bedre enn det du får høre fra betalende kunder, som bruker programvaren din.
Betyr dette at du lar brukerne diktere produktet ditt? Nei. Det er fortsatt ditt ansvar å tolke svarene du får, og omsette de til et helhetlig, sammenhengende produkt. Poenget er at du skaffer deg svar, hele tiden. At du tolker dem, hele tiden. At denne økende innsikten styrer arbeidsinnsatsen din, hele tiden.
Det er Kaizen.
Ingen motsetning mellom prosjekt og produkt?
Jeg mener stadig at IT-utvikling som oftest bør organiseres som produktutviklingsløp og ikke som prosjekter. I Teknisk Ukeblad 13/10 2011 uttaler Tone Bringedal i Difi at det ikke er noen motsetning mellom prosjektorganisering og mine poenger.
La meg først raskt oppsummere hva som er mine poenger: Gode IT-satsinger slutter ikke når verdiskapningen begynner. De lever side om side med brukerne og tilpasser seg kontinuerlig. Offentlige organisasjoner har spesielt behov for dette, på grunn av stadige endringer i politikk, budsjetter og regelverk. Hvordan skal for eksempel Oslo Universitetssykehus klare å modernisere virksomheten og samtidig bruke mindre penger, hvis ikke endringer i IT-systemene er en naturlig, integrert del av prosessen?
Definisjonen av prosjekt på Wikipedia: “Prosjekt betegner innsats som gjøres for å oppnå et definert mål, som oftest innenfor en planlagt tids- og ressursramme (…)”
Flyt av arbeid er viktigere enn kunstige tids- og kostnadsrammer lagt langt frem i tid. Jeg kommer stadig over historier om IT-avdelinger som utvikler ny funksjonalitet til tross for at det brukerne ba om kunne ha blitt løst av funksjoner de ikke visste om. Selv om kunnskapen som slikt dobbeltarbeid – sløsing - finnes i organisasjonen som helhet, kommer den ikke frem.
Jeg finner like mange eksempler på det motsatte – feilaktige antagelser om at eksisterende funksjonalitet kan løse nye behov. Dette skjer hele tiden, i prosjekter både i offentlig og privat sektor. Det skjer hele tiden, også i prosjekter som hevder å bruke Scrum eller annen smidig metodikk. Det skjer fordi de involverte jager et kunstig mål.
Spørsmålet jeg stiller er derfor som følger: Hvordan kan vi organisere oss på en måte der samhandling mellom utviklere og brukere blir navet i utviklingsarbeidet? Der arbeidskulturen ikke tolererer misforståelser som følge av manglende samhandling?
Jeg mener løsningen må være å fjerne organisasjonsbarrierer. Ledelsen bør fokusere på flyt av arbeid: Hvor mye ny funksjonalitet leverer vi hver uke? Hvor lang tid tar det fra vi identifiserer et behov til vi leverer en løsning? I offentlige virksomheter med saksbehandlere: Hva er utviklingen i saksbehandlingstid?
Man kan selvfølgelig argumentere for at slik tankegang er mulig innenfor et prosjekt. Det finnes flere eksempler på prosjekter der man har levert underveis, og kanskje også realisert gevinster underveis. Men er dette på grunn av prosjekttankegangen eller er det på tross av den? Kan Difi eller andre som forfekter prosjekttankegang gi eksempler på IT-løsninger som ble en suksess fordi utviklingen ble organisert som et prosjekt istedenfor et produktutviklingsløp?
Jeg tror Difi har den riktige pulsen på offentlige IKT-satsinger, noe deres arbeid med kontraktsstandarder bærer preg av. Selv om de forstår mine poenger er imidlertid prosjektbegrepet innarbeidet hos oss alle, også fra politisk hold. Alt for mange offentlige IKT-satsinger har gått galt på grunn av utilstrekkelig styring. Fra politisk hold er det press på kostnadskontroll og risikohåndtering, og der gir prosjekter oss etablerte rammer.
Slike rammer står imidlertid i veien for gevinstrealisering, som seiler opp som det neste store temaet. Min advarsel går først og fremst til de som stiller forventingene til Difi og andre aktører som er toneangivende for hvordan gevinster skal realiseres for det offentlige Norge. Prosjektorganisering er en etablert sannhet. Det er også en selvpålagt begrensning.
Vi må ikke undervurdere de kulturelle konsekvensene av de føringer vi blir pålagt. Det er ikke de som lager prosjektmodellen som gjennomfører satsingene. Det er den enkelte virksomhet, ofte i samarbeid med konsulentselskaper. Det offentlige må sende et tydelig signal om hvordan slikt arbeid skal foregå. Ved å begrense fokuset til en felles prosjektmodell risikerer vi å misforstå poenget, gang på gang.
People. Culture. Fire. A gut feeling.
In order to utilize our full potential we need to start with understanding ourselves. Usually what you find to be true about yourself, will be much the same for other people you meet. With this I mean our fundamental needs and emotions. Living by the “Golden rule”, treating others the same you want them to treat you, helps me a long way. This includes respect. I want people to respect me and listen – not necessarily agree with me.
I am only human.
The biggest challenges in software development are seldom related to technology – it usually comes down to the people involved. I am affected by many things like my background, my personality, a fight with my wife or the working culture in my company.
As a human 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 remember one morning I was going to the gym with my wife. I had planned to eat breakfast at the gym, which they serve every day from 07.00-09.30. I came in 09.32. No breakfast. I was hungry. My lovely wife tried everything to get me back into a good mood. My gut feeling was out of balance. Nothing worked. We ended up leaving the gym after 30min of not-training. Only when I eventually was able to please my stomach with food, I was able to find back to my normal happy self. What an idiot, I thought about myself.
I am never irrational – you just don´t understand!
I don´t believe any humans are pure evil. I know I´m not evil. I have my convictions though. Sometimes you find me acting strange. Am I a strange person? For you, maybe. For me – in the moment – no. I often act on instinct. I act based on my best jugdement. Sometimes I make mistakes. Sometimes I misjudge. But you can never claim that I am irrational. From your perspective it might seem that way, but from my perspective it is the natural thing to do – at the moment. Tomorrow I might agree that I made a bad choice, but in this moment I have acted on my belief. If you understood my perspective, you would not judge me and you would understand how to handle me.
I don´t want to be alone, I want to belong. But don´t force me!
We all have a basic instinct of belonging to a group. And it´s not about meeting the same kind as your self, it´s about having a common belief. In the event company Arrcom I meet all kinds of professions (i.e teachers, chefs, fire fighters, leaders in IT-companies like my self). We have the same passion about creating unforgettable moments with people – our clients. The mix is a enriching. Arrcom is a family and amongst the family members not reckoned as a job. It has become a life style, where many of the instructors probably would do the job for free. When I informed Arrcom that I wanted to return to IT and had to leave Arrcom, their response was: “You don´t have to leave Arrcom to follow your dreams, Tom. Once Arrcom, forever Arrcom!”. Do you want to stay home when your wife/husband gives you a cold remark (read: “So you are going out to have a good time again?”) and try to put on a pair of psychological hand cuffs?
In my company our mission is to give all employees the education and development during the time they work here. We have acknowledged that our people won´t work here for ever, but by helping them to follow their dreams we are creating the greatest place to work!
The concept of “family” is often challenged by friends and colleagues or different subgroups of these (- Did any one say soccer on TV?). Sometimes it gets out of balance. This will eventually have negative consequences on the family relationship. Not good. I think companies in a greater degree should open up for and include family. Well facilitated I also believe your company could gain from inviting in experience, thoughts and perspectives from family members. Don´t make your employees choose sides.
Do I feel I can trust you?
Why shouldn´t I? What is my gut feeling? Would it help to walk around mistrusting everyone? When ever I meet someone that seems suspicious of me, I will naturally strengthen my defense mechanisms? Yes, I know you agree with me on this. And you know you would dig your own trench until you sensed a white flag blowing in the wind. It´s natural, but we need to be aware of it.
So what have we learned so far? I am only human and humans sometimes make mistakes. Even if I make “a bad call”, I probably didn´t do it on purpose. If I act like an idiot, it´s probably because I´m uncomfortable about the situation. Even though you don´t understand, you now know better than to attack me when I´m down and instead try to understand me. Belonging to a group of people who trust each other and respect each other we can get past the psychological barriers and focus on what we came to achieve. And it´s going to be a lot of fun!
Now that you have gotten to know me better and my thoughts on people, I would like to share some fundamental thoughts and experience on how we can establish a foundation for creating a learning, humane culture where everyone knows when and how to contribute as a self organizing team.
We´re all the same so let´s treat each other with equal respect.
I hate the concept of worshiping – some thing or some one – but I do sometimes find myself shrinking in size and confidence meeting someone “important” (read: seen them on television or a newspaper). Recently, to help me from shrinking (since I´m already short enough) I image them being just as ugly in the morning, crying in their mothers lap or pooping in their pampers. Next time you see someone that makes you shrink in confidence think of this. It helps.
We´re all in the same boat.
When I sign a working contract I also agree to follow the rules and regulations within the company. Even though it doesn´t say explicitly in the contract, it also includes adapting and contributing to a healthy working culture. Working in a company we are all in the same boat, with the same vision and goals leading us. We all win if we really care and try to help each other. This is NOT limited to colleagues on the same level or in the same department.
Tell me while I still have a chance to help you.
We have a tendency to complain after something has occurred instead of discuss it while there still is time to make corrections. Sometimes we put restrictions on ourselves. Like telling ourselves things like “My boss won´t listen to me”. In addition we try to avoid making choices if we can. So instead of choosing to front an issue, we tend to to nothing and then later complain about it. In my organization we have put our names to the paper and sworn that we will always let the person concerning know if there is an issue (face to face or by phone. Never email) – and tell everyone if someone has done something good.
As leaders I can´t let a complaining sub culture grow. I have to set the expectations early on. A healthy culture is depending on everyone giving unconditional feedback and seeing it as a great help to improve.
I have a dream! The Flowing Organization.
There are many types of organization models and philosophies about how to create the perfect company. I have a dream of creating a humane, learning and flowing organization where our mission is to fulfill dreams – both for our clients and our employees. In order to achieve this we need to all agree that (and mean it) we have one common goal. We need to care about each other. We also need to be prepared to work with our selves in many areas to optimize the whole.
I want to break down all the traditional barriers we see every day in the classic hierarchical organization charts (getting sick just thinking of them). Like a soccer team we should be able to understand when and where to contribute, by knowing our own role and the rest of the team. As a leader I don´t want to run around telling people or trying to motivate people to take initiative. My dream (and near future) is to see the company become as self organized as our projects, where the value stream is as clear as your way back home from the office.
You´re probably already smiling and thinking of me as a the romantic type. How can I expect employees to start thinking for them selves and actually contributing because they WANT to? I call it “my dream”, that´s true. But then again, as I told you previously, that´s our business: making dreams come true.
It doesn´t really matter if you believe me. The important thing is that we believe. Follow me on this expedition and you can see for your self.
(From Chapter Zero – Cross-posted from my blog)
******
The author @ BangSkogen
As part of a process of continuously improving my knowledge I am structuring my thoughts and experiences on subjects related to people, leadership and developing working cultures. Eventually I hope this will become an entire book, but in the mean time I will blog it out to the world so we can have a nice chat a long the way.
I have written a first iteration of two chapters. An introduction explaining why and what, and then a soft chapter about my fundamental thoughts about people and working together. All feedback on the first release of my book is welcome as comments in my blog or by posting me an email (bang AT iterate no).
The full version and my background for writing this book you will find here in My Book
Bang
