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?

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

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

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.

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

Why AWS?

Amazon is a leading provider of “infrastructure as a service” and is constantly adding new services to its offerings. AWS allow you to create virtual machines on demand, load balance them, connect them to a “database as a service” (with several advantages over a manually managed database) and various other services such as notifications, e-mail, and a queuing service. You get access to built-in monitoring and you can deploy applications to their “platform as a service” built on top of that while retaining control over those lower-level resources.

Follow the official AWS Blog to be informed of new services, features etc.

Getting started with AWS

To create an AWS account you’ll need a phone and a credit card (which will be charged if you use any of the paid services or exceed any of the free usage limits). Be careful during the sign-up process as the UI isn’t exactly error-proof. It might take up to two hours before your account becomes fully functional.

The next thing to do is to browse through the AWS Management Console, which let you create and configure various services and resources, the most interesting being the Elastic Compute Cloud (EC2), where you can start new virtual machines. The management console is quite self-explanatory though not as user-friendly as I might wish. You might want to check these screenshots showing how to create an EC2 instance in the Management Console.

Brief Overview

The core rule of AWS is that you only pay for what you use, i.e. runtime hours of your instances and the traffic – see the AWS Simple Monthly Calculator.

The most important resource is EC2 as it allows you to create virtual machines, called “instances.” There are different types of instances regarding their memory and computational power. By default they are transient and discarded (terminated) once you stop using them. You may also have an instance backed by the Elastic Block Storage (EBS) which enables you to stop and start the instance again with any state and changes preserved, Amazon charges $0.10/GB/month for that. You can also mount EBS storage as a volume to your instance if you need to persist only some data. There is no quick way to re-create a terminated instance, you have to go through the wizard again – that’s where the command-line tools and automation become handy.

When setting up your EC2 instances, you’ll likely also need to assign them into the same security group and configure what ports are open to whom in the security group (by default you cannot even SSH in).

If you want to learn all about EC2, go to the Amazon EC2 User Guide.

Aside of EC2 there are also many other interesting services such as the Elastic Beanstalk (PaaS, currently for Java webapps, using Tomcat), the distributed storage S3 etc. There are also some additional services such as the Amazon CloudWatch, which is a (performance) monitoring tool for your AWS infrastructure. (Which can be complemented by New Relic monitoring for even more insight into the application.)

Leveraging the Amazon Free Tier

Amazon provides new customers with a certain amount of resources for free for one year, you only need to pay if you consume more than that. It includes for example a non-stop running micro EC2 instance backed by EBS (i.e. it is persistent, you can stop and start it again), 15 GB traffic, 10 GB of EBS storage, 5 GB of S3 storage, 10 CloudWatch metrics etc. It unfortunately doesn’t include the Amazon-managed MySQL/Oracle database (RDS) though they provided 1GB of space in the Amazon SimpleDB (a NoSQL key-value store).

This means that you can have a constantly running EC2 Micro instance (613 MB memory) for free. You can use it as your base in the cloud, for example because the traffic between two EC2 instances is faster/cheaper and because it has full access to machines within the same security group.

The best choice is likely to base your instance on the Amazon Linux AMI, which is a variation of RedHat Linux optimized for AWS, equipped with most of the AWS API command-line tools and CloudInit for automated system setup (described later). I’d recommend you to browse through the user guide that describes what tools are available and how to use CloudInit.

What about Automation?

The AWS Management Console is great if you do something for the first time but the wizards are too time-consuming for repeated tasks. Especially if you need to set up more than a single instance – let’s say a RDS database instance, an EC2 machine instance and the corresponding security groups or a number of identical instances. We will look into ways how to automate this.

Aside of setting up the infrastructure, you usually also need to customize the EC2 instances (at least by installing and starting the software you need them for). You can log into them via SSH but wouldn’t it be great to be able to automate that, especially if you need multiple similar instances?

Notice that I’m now concerned only with automating the work of the AWS user. It is also possible to configure AWS to automatically start new EC2 instances when needed (e.g. when the load exceeds a limit) but that is a different story.

Overview:

• Infrastructure provisioning automation:
• AWS API command-line tools (or AWS Java API or third-party tools/libraries)
• AWS CloudFormation
• Instance OS & SW setup automation:
• Canonical CloudInit (Ubuntu and Amazon Linux AMIs) – perhaps leveraging Puppet or Chef
• Creating a customized AMI

Automating Infrastructure Provisioning

There are two prominent options for creating your EC2 instances and other resources without the AWS Management Console: AWS API command-line tools and AWS CloudFormation.

AWS API command-line tools

Amazon offers command-line tools for most of its services such as EC2 and RDS.

EC2: Robert Sosinovski published very good instructions for starting with Amazon EC2 command-line tools (which isn’t specific to Mac OS X despite its title) back in 2008 but they are still valid so just follow them, there is no point in repeating them here (basically download, unpack, set environment variables, provide credentials). Alternatively, you can go to the download page and follow the official instructions. I’d recommend you to create a folder to include all the tools => $AWS_FOLDER/ec2/ etc. instead of ~/.ec2/.

If you want to use another AWS region than the default us-east-1 then you need to set also the environmental variable EC2_URL, see the list of regional endpoints or the command ec2-describe-regions. Ex. (my URL has ec2 in the middle contrary to the list of endpoints but evidently it works too):

export EC2_URL=https://eu-west-1.ec2.amazonaws.com

Authentication setup for the other tools: While the documentation for the EC2 tools describes only authentication via the X.509 certificate (environmental variables EC2_PRIVATE_KEY, EC2_CERT), the other tools (at least RDS, CloudFormation) support uniform authentication via the environmental variable AWS_CREDENTIAL_FILE pointing to a file containing your AWS Access Key Id and Secret Key (which you can find in your AWS account under Security Credentials – Access Keys), the configuration is described in the tools’ readme files.

RDS: Setup of the RDS command-line tools is quite similar to EC2, just download them and add environmental variables as described in the included readme.txt.

As with EC2, you may want to change your default RDS region:

export RDS_URL=https://eu-west-1.rds.amazonaws.com

Examples from the Vaadin Test Setup

My original plan was to try the performance testing described in Vaadin Scalability Testing with Amazon Web Services, which unfortunately proved to be impossible because the test application failed to run. During the process I’ve automated the individual setup steps, shown below. You may want to check the blog post to understand the context.

I didn’t need to create a security group and allow access to it via the command-line as I’ve done it via the Management Console. You could open the SSH port as follows:

ec2-authorize  -p 22

Create two EC2 instances:

ec2-run-instances ami-1a0f3d6e -t m1.large -k VaadinAS --instance-count 2 -z eu-west-1c -g quick-start-1

• -k specifies the name of an existing key-pair (the Management Console offers you to create it the first time you create an instance) that will be associated with the instance to make ssh login without a password possible
• -z specifies the availability zone (AZ) within the region (you can see the available ones when creating an instance in the Mgmt Console), it’s likely better to have all resources in the same AZ
• -g specifies an existing security group (again created in the Console); default is “default”, I believe

The ec2-run-instances command also supports the –user-data or –user-data-file attribute to pass setup instructions to CloudInit, as described later on.

To log into instances you will need their public domain name/IP (printed when the command finishes) and user name, which depends on the AMI used (easiest: right-click on the instance in the Mgmt Console and select “Connect” to get a complete SSH connect command), and the key file (./VaadinAS.pem in my case). Thus I would log into my first instance as follows (provided that I’ve already opened port 22 in the security group):

ssh -i VaadinAS.pem ubuntu@ec2-46-137-136-253.eu-west-1.compute.amazonaws.com

Create a RDS instance using MySQL (it may take few minutes before its startup finishes):

rds-create-db-instance quicktickets --allocated-storage 5 -c db.m1.large  -e MySQL5.1 -u quicktickets -p V3ryS3cr3t  -z eu-west-1c --backup-retention-period 0 --db-name quicktests

• quicktickets will be the name of the instance
• the max. size will be 5 GB (can be changed later)
• -c – it will be based on the db.m1.large instance
• -e – the DB type is MySQL, -u username quicktickets, -p password V3ryS3cr3t
• -z eu-west-1c puts it into the same AZ as the EC2 instances
• –backup-retention-period 0 – don’t keep backups (default: 1 day)
• –db-name quicktests – needed for connecting to it

Next I need to make the DB accessible from my EC2 instances (that are in the security group quick-start-1 ):

rds-authorize-db-security-group-ingress default --ec2-security-group-name quick-start-1 --ec2-security-group-owner-id 

• You can find your AWS Account ID in your AWS account under the Security Credentials

To find out the hostname of the instance execute rds-describe-db-instance, which will also tell you whether it is still launching or already running.

Now you can connect to the DB from an EC2 instance in the security group:

mysql -h quicktickets.cpokd2djuazy.eu-west-1.rds.amazonaws.com -u quicktickets --password=V3ryS3cr3t quicktickets

AWS CloudFormation

CloudFormation is a new (2/2011) free service from Amazon that enables you to describe the resources you want and their dependencies in a text format and to use this “template” to instantiate them (“to create a stack”) either via the AWS Management Console or via the CloudFormation Command Line Tools. You can also share you template and use and combine templates created by others. The templates also support the UserData attribute that you can use to pass setup instructions to CloudInit, as described later on. Check out this screenshot-based post about setting up a CF stack via the Management Console.

An example template file:

{  "AWSTemplateFormatVersion": "2010-09-09",
  "Description" : "One EC2 instance with a security group open for SSH",

  "Parameters": {
    "KeyName": {
      "Description" : "Name of an existing EC2 KeyPair to enable SSH access",
      "Type": "String"
    },
    "InstanceType": {
      "Default": "m1.large",  "Type": "String"
    }
  },

  "Resources": {

    "EC2SecurityGroup": {
      "Properties": {
        "SecurityGroupIngress": [
          {
            "FromPort": "22",
            "CidrIp": "0.0.0.0/0",
            "ToPort": "22",
            "IpProtocol": "tcp"
          }
        ],
        "GroupDescription": "SSH access"
      },
      "Type": "AWS::EC2::SecurityGroup"
    },

    "Ec2Instance": {
      "Properties": {
        "SecurityGroups": [{"Ref": "EC2SecurityGroup"}],
        "ImageId": { "Fn::FindInMap": ["AWSRegionArch2AMI",
            {"Ref": "AWS::Region"}, "64"
          ]
        },
        "UserData": {
          "Fn::Base64": { "Fn::Join": ["", [
              "#!/bin/bash -v\n",
              "# you init bash script here...\n"
        ]]} },
        "KeyName": { "Ref": "KeyName" },
        "InstanceType": { "Ref": "InstanceType" }
      },
      "Type": "AWS::EC2::Instance"
    }
  },

  "Mappings": {
    "AWSInstanceType2Arch" : {
      "m1.large"    : { "Arch" : "64" }, "m1.xlarge"   : { "Arch" : "64" }, ...
    }
  },

  "Outputs" : {
    "InstanceId" : {
      "Description" : "InstanceId of the newly created EC2 instance",
      "Value" : { "Ref" : "Ec2Instance" }
    },
    "AZ" : {
      "Description" : "Availability Zone of the newly created EC2 instance",
      "Value" : { "Fn::GetAtt" : [ "Ec2Instance", "AvailabilityZone" ] }
    },
    "PublicIP" : {
      "Description" : "Public IP address of the newly created EC2 instance",
      "Value" : { "Fn::GetAtt" : [ "Ec2Instance", "PublicIp" ] }
    }
  }
}

• 4: As you can see, you can define properties (with defaults) for which values may be supplied when a new stack is being created from the template
• 16, 31: Next it defines two resources: a security group and an EC2 instance (which uses some mappings because the names of AMIs differ based in region)
• 38: Setup instructions can be supplied to CloudInit via base64-encoded UserData
• 56: You can also define what information should be available via the DescribeStacks function (command line: cfn-describe-stacks)

CloudFormation let you define any resource (EC2 instances, RDS instances, load balancers, security groups, …), their dependencies, and, via CloudInit, various boot-time actions such as SW installation. The templates are valid JSON documents.

Example: Using CloudFormation and Cloud-Init to install and start a RoR application (featuring the WaitCondition) – it is not too long and describes the individual sections of the template file. You can also browse through the public template files, for example this: Single EC2 Instance web server with Amazon RDS database instance.

In June 2011 Amazon launched also CloudFormer, a prototype tool that enables you to create CloudFormation templates from the existing AWS resources in your account.

If you still desire more information, read the CloudFormation User Guide.

Customizing an Instance with CloudFormation Metadata and Helper Scripts

From Bootstrapping Applications via AWS CloudFormation:

AWS CloudFormation allows you to define the set of packages, files and operating system services through metadata in a template. In addition, it provides helper functions to
interpret the metadata and act on it, installing packages, creating files and starting or restarting services on the instance.  The AWS CloudFormation scripts build on the basic CloudInit functionality and enable you to create a common, simple CloudInit startup script that is data-driven through metadata. You describe what needs to be installed on the host in metadata and AWS CloudFormation takes care of the how.

See the document for instructions on how to use the metadata and helper scripts such as cfn-init, which installs packages, downloads and unpacks archives, starts services, and creates files based on data in the metadata section. It also mentiones the integration of CloudFormation and Chef or Puppet, which is described in more detail in the whitepapers Integrating AWS CloudFormation with Opscode Chef and Integrating AWS CloudFormation with Puppet. If you intended to use CloudFormation then you should absolutely read this 22 pages guide.

(Note: cfn-init supports downloading and unpacking packages, which can be used e.g. to fetch the latest source code of you application provided on-demand by GitHub.)

You can see an example of usage in this template leveraging metadata & helper scripts.

Other Alternatives

• AWS Java API (the command-line tools use it, it’s based on web service calls)
• Third-party tools/libraries, e.g. the Ruby gem Fog.
• Chef + Knife, Puppet (I believe they provide their own wrappers for the AWS WS calls and leverage CloudInit)

Automating EC2 Instance OS/SW Setup

To customize the software inside EC2 instances and its configuration you can either create a customized AMI or use Canonical’s CloudInit with AMIs that support it (Amazon Linux and Ubuntu and maybe others). If you use CloudFormation, you have also another possibility based on CloudInit, described in the C.F. section above.

Canonical CloudInit and Instance User Data

You can pass whatever text data to a new instance via the User Data attribute (up to 16KB), the data is then available from within the instance at http://169.254.169.254/latest/user-data (you can also access various metadata in a similar way). CloudInit is a Linux utility developed by Canonical, the company behind Ubuntu, that reads these data and processes any instructions embedded in them at boot time (approximately when rc.local runs). For example if it starts with #! then it is run as a shell script under root.

CloudInit accepts different types of instructions in user data, distinguished by the first line: a script (#!…), cloud config data i.e. packages to install etc. (#cloud-config), URLs of files to process (#include …), #upstart-job to add something to /etc/init (run on each boot) and more. It can even handle gzip-compressed user data and multi-part data, combining several of the instruction types (see cloud-utils and the command write-mime-multipart).

The type #cloud-config is quite useful as it is a simpler way to install packages and execute commands than a bash script. It contains YAML-formatted instructions, f.ex. “runcmd” to run a command-line tool, “packages” to install packages via the OS’ package manager. Example: Installing Jenkins CI with #cloud-config.

CloudInit isn’t very well documented yet, you may ocassionaly need to read the Python source codes. If something goes wrong, you can check the logs in the instance’s /var/log/cloud-init.log.

Aside of the official documentation you might want to see Xebia’s CloudInit introduction presentation and read the section on CloudInit in the Amazon Linux AMI user guide.

Creating a Customized Amazon Machine Image

CloudInit installs and configures software at launch time and thus the instance takes longer to become fully available. If that is a problem then you may prefer to create your own customized Amazon Machine Image (AMI) with all the software already installed and configured. It’s described e.g. in this brief how to create a new AMI from an existing one (2007) or in the official AMI customization docs and you may also want to have a look at the EC2 AMI command line tools. You’d then create new EC2 instances based on the customized AMI.

Some Related Stuff

If your EC2 instances need to communicate and use a technology that requires them to be on the same subnet then you can use Amazon Virtual Private Cloud (VPC; free) and even connect it to your data center via VPN ($0.05/h). This may be necessary for example for running multiple JMeter instances.

Regarding JMeter, Jörg Kalsbach has created an AMI that simplifies the creation of JMeter master-slaves farms (3/2010): JMeter In The Cloud – A cloud based load testing environment (read the doc). (The trick is that the master instance starts the slave instances and thus knows their IPs. I guess that something similar could be done with CloudFormation, Auto Scale and user data/CloudInit.)

Summary

AWS is a dynamically developing platform with continually improving tooling and a growing offer of services. It’s very easy to get started with using the web-based Management Console but it becomes soon more convenient to move to a more automated interface, such as the command-line tools or even CloudFormation for whole infrastructure stack setup. The support for customizing instances either by creating custom images or at launch time via CloudInit and/or CloudFormation’s metadata and scripts is very good and people have already been combining it with their favorite DevOps tools Chef and Puppet.

I’d recommend you to start with AWS using the Management Console and then to switch to the command-line tools and CloudInit when you become comfortable with the concepts and usage. If you need to provision multiple resources repeatedly, you should use CloudFormation with its metadata and helper scripts (perhaps leveraging also Puppet/Chef).

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

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.

Second, I’ve learned that the most important thing to succeed is to know (and communicate) why – not just “what” we do or want to achieve, but “why,” what’s our purpose, our goal. Because “what” talks just to our thin, rational neocortex – but that “why” strikes deep into the center that drives our motivation and behavior. Great leaders don’t present plans, they inspire people with their cause – as did Martin Luther King with his “I have a dream” talk, brothers Wrights who were able to inspire themselves and their coworkers to achieve something a much better equipped team didn’t, and Apple with its vision of great and friendly world that makes people stand in a queue for six hours to be the first to purchase their new product. You may not want to aspire to the same world-changing goals as they do but still, whatever you do, you should know that to attract people you have to know and communicate “why.” I’d certainly much rather work – likely even with sweat and blood – for a company that has a cause that resonates with me other than “to make money”. (That may be also the reason why I don’t like certain dominant company for I feel that their goal is to rule the world [of technology], to get it into and keep it in its iron embrace.)

Last, I’ve learned that what motivates us isn’t money, but purpose, mastery, autonomy (not such a big surprise anyway, but it’s nice to have it backed by actual research results). For a simple, physical task a financial reward increases performance – but for even a mildly cognitive task it decreases it. Thus to motivate employees, once the question of money is “out of the table,” i.e. once they’ve enough for what they need, you need something else. And it turns our that we are motivated by three desires -the desire for autonomy, for deciding ourselves our course of action, the desire to be better in what we do, to feel more competent, and – as mentioned already in the previous talk – by a purpose. (Frankly, who would be surprised that people prefer to do something meaningful, to participate on something bigger, on creating a better world of tomorrow?) This is a good guide both for attracting employees and choosing and employer – but it certainly applies in other dimensions of life too.

Conclusion

We are human. We are not just rational machines, as the majority of the western science claimed in the last centuries. And that’s a good thing. To be successful and happy we need to understand little more about ourselves and others to be able both to drive ourselves better and to communicate with others better. We should be more aware about how we think and decide and choose the right decision strategy without blindly preferring one (such as the rational one). When we want to appeal to other people to help us with our goal, we have to formulate and communicate our purpose, so that they can identify themselves with the purpose and help us with all their power. Finally, we should be aware of what motivates us and seek and foster such an environment where it flourishes. (One of the reasons why I prefer Scrum/lean that empowers the autonomy and responsibility of individuals over a tight, top-down controlled process.)

PS: The rules of the Semco group, which a very non-standard company – open, cooperative, encouraging autonomy – is very inspiring.

Cross-posted from The Holy Java.

(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"]

What is Groovy?

Groovy 1.8 is a mature scripting language for the JVM written as an extension of Java with optional dynamic typing, closures, and more. It’s now developed by SpringSource, the company behind the Spring framework.

As mentioned, nearly all Java code is a valid Groovy code with basically one exception: To initialize an array you can’t use { … } (for that would be a closure), you must use [...] instead (notice that by default it actually creates a List, only when assigned to an array variable or casted to array will it produce an array). Make sure to check the few common gotchas before you dive into using Groovy.

You can experiment with Groovy online in the GAE Groovy console.

Groovy features especially beneficial for testing

General

• Dynamic typing at request => conscise, avoids code cluttered with casts

Collections: Closure-based methods like every, each, find

Files: Read all the text with one call, withReader { .. } etc.

Testing/advanced:

• assert- you can use the Java keyword assert instead of JUnit methods, upon failure Groovy will provide you with pretty good info of what went wrong:

  Assertion failed:
  
  assert config.getResolvers()) == ["h:dataTable" : resolver, "my:dt2" : null]
         |      |                |                  |
         |      |              false                |
         |      |                                   MyResolver@731d2572
         |      [h:dataTable:MyResolver@731d2572, my:dt2:MyResolver@731d2572]
         LocalVariableConfiguration@7e859a68

• Here-docs: embed multi-line strings easily in a test (also supports replacing references like $variable with values)
• Implementing interfaces with a map (map coercion)
• Use expandos to define dynamic beans (similarly to JavaScript, you instantiate an Expando and just add properties and closures as methods) – as described on the linked page, expandos and maps are usually enough to replace a mocking library
• Build-in mocking
• With Groovy you can of course also use Spock, the excellent specification & testing framework

Complications

• Neither JUnitMax nor Infinitest (in IntelliJ) seem to support Groovy test cases
• You need a decent IDE such as IntelliJ IDEA
• If using Maven, you have to explicitely configure the GMaven plugin (esp. with a newer Groovy version)
• IntelliJ 10.5: Click & alt+enter on a non-existing method to create it only works if the target type is a nested class within the test, not if it is a standalone Java class (so I just create my class there and when done TDDing I extract it into a top-level Java class)

Conclusion

Groovy makes test writing much more productive and thus developers happy. I intend to use on all my open source projects and to try push it into our commercial projects too. You should give it a try too!

Additional Links

• DefaultGroovyMethods.java (src): defines the methods added to all objects
• DefaultTypeTransformation.java: methods used internally to convert between types and when using “as aType” – useful to know what as can convert

Cross-posted from The Holy Java

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.