MVKJG 5: Håll vad du lovar

Att lova något är otäckt. Det kan visa sig att man inte kan stå vid sitt löfte. Det händer ju även den bäste, och kan leda till en obekväm situation. För mig kan rädslan för detta obekväma ibland leda till att jag anammar följande strategi: den som aldrig lovar något behöver heller aldrig bryta ett löfte.

Dessvärre spelar löften en avgörande roll i alla typer av samarbeten. Om du ska kunna basera dina planer på det arbete jag gör, måste du veta vad du kan förvänta dig från mig, och när. Löften spelar dessutom en annan viktig roll – den som skapare eller förstörare av tillit. När någon lovar mig något, och håller löftet, ökar min tillit till den personens förmåga. När någon inte levererar enligt sitt löfte, eller aldrig kan lova något till att börja med, sjunker min tillit till den personens förmåga.

Det första steget till att kunna hålla vad man lovar är därför att (trumvirvel) faktiskt våga lova något.

Så vad innebär det att lova något, och att få ett löfte? Ingen kan förutsäga framtiden, så ett löfte kan aldrig innebära en hundraprocentig garanti att något kommer att hända. En definition som leder till färre besvikelser är kanske att se på ett löfte som att den som lovar åtar sig att göra allt som står i dennes makt för att löftet ska uppfyllas.

Som löftesgivare måste jag alltså förstå vad som står i min makt. Utan insikt, mindre sannolikt att jag kommer att kunna hålla vad jag lovar. Vad som står i min makt är en funktion av mina egna förmågor och det sammanhang jag måste använda dem i.

Det andra steget till hålla vad man lovar är därför en personlig insikt i vad man har makt att lova.
Att inte kunna hålla ett löfte behöver inte alltid leda till minskad tillit. Om du upptäcker att ett löfte du gett inte längre kan hållas ska du inte suga på den sura karamellen. Analysera orsaken, berätta om vad som hänt, och gör – om det utlovade fortfarande är värt att satsa på – ett nytt löfte som har större sannolikhet att fungera. När du gör det bygger du ofta tillit minst lika effektivt som när du faktiskt lyckas leverera på ditt ursprungslöfte.

Popular Interview with Jerry Weinberg

As founder and editor of PNEHM!, Citerus’ newsletter on successful software development, I get to publish loads of great articles written by my smart colleagues at Citerus. The most recent is my friend Magnus Ljadas’ interview with consulting icon Jerry Weinberg. On his blog, this is what Jerry himself says about Magnus as an interviewer:

“I’ve been interviewed many times over the years, but Magnus is the best interviewer I can remember.”

Don’t miss out on this great interview with a great person.

Amplifying Your Effectiveness

Last friday, I found myself sitting alone on the patio of the Embassy Suites hotel in northern Phoenix, looking out over an expansive pool area filling up with families most likely in town for the upcoming Nascar races.

I, on the other hand, was just about to fly back home to Sweden, had no interest in race cars, and was feeling lonely for the first time in several days. No wonder, after having attended a five day conference that was actually mostly about me.

Since it’s start in 2000, the Amplifying Your Effectiveness conference has attracted people interested in working with themselves to become more effective in and out of the workplace. Most participants seem to hail from the software industry, which is also the industry in which the conference’s ur-host, Jerry Weinberg, is known, frankly, as an icon. With more than thirty books (among the bestsellers: “Secrets of Consulting”), hundreds of articles published, and numerous well-known immersive workshops conducted, his reputation is well deserved.

Not all participants work with testing, coding or managing software however. One runs a plumbing business, another is a painter. As for geographical origin, people have come from all over the U.S. There’s also a fair number of Canadians and a few Europeans, like yours truly.

The varied backgrounds are important, because AYE is all about the people. Highly intelligent and very humble people, willing to meet, share, learn and have fun doing it, or letting it be emotionally challenging when that’s what’s needed.

Driving home the point that the people should be in the center, the AYE is run as a guaranteed Powerpoint(TM)-free event. Guaranteed. You won’t see a single presentation slide for the duration of the conference. Given the prevalence of presentation slides in every other setting, one of AYE’s claims to fame could be that it may be the only way to avoid Powerpoint(TM) for almost a week.

Instead of talking heads and bullet points, AYE has stories that stick and dialogue that engages. Instead of rows of chairs, AYE has circles. This lays the ground for something else that the conference has: the ability to forge new friendships. I arrived at the conference knowing not a single person. I left only after having hugged and shaken hands with a whole bunch of new acquaintances from all over the world.

Making friends is also made easier by the fact that many participants go out dining together in the evenings. Phoenix is huge, so finding a place that serves food you like is not hard. If by finding you mean locating on Google Maps, that is. Driving to the actual place can be a different story altogether. We temporarily lost a whole car one night, but it contained a complete group, so no one should have had to eat alone.

While very outspoken and easy going, most of the participants seemed to identify themselves as introverts on the Myers-Briggs scale. This is in accordance with what I learned in one of the sessions however – our preferences say little about how we will actually behave. On a related note, I can imagine that if you took almost anyone from this conference and put them in a Swedish setting, that person would surely stand out as the most outspoken in the group. It might be a cultural thing, but it’s probably a safety issue as well. Most participants seemed to consider it safe to speak their minds at AYE.

I also managed to find the time to sit down and talk one on one with Jerry Weinberg for a while, which was rewarding. The only thing more extensive than his experience is his repository of stories, from which he frequently pulls one (often funny!) out to teach an important lesson.

Content-wise, this years’ conference had three parallel tracks, and selecting a session was not always easy, since interesting topics often collided. A pleasant problem for me of course, but possibly frustrating for the hosts.

Given that all hosts of the conference are students of Jerry Weinberg, who is himself a student of family therapist Virginia Satir and the topic of general systems thinking, it isn’t strange that a few core concepts pop up again and again throughout the conference.

To give new participants an opportunity to catch up, a full day pre-conference tutorial run by hosts Don Gray and Steve Smith works through the basics of Satir’s teachings and also lets participants try on a kind of Myers-Briggs-based preference test. I came up as an ENTP, which surprised me, since I certainly don’t think of myself as extraverted. Whichever it is, it was certainly food for thought for me, and the source of an aha-feeling when I thought back on recent conflicts at work.

In summary, the AYE conference was a fabulously useful experience for me, but make no mistake: it might not be for you. Because the conference is highly experiential, some exercises may touch on things you did not expect. At more than one occasion, emotions ran high. Thankfully, the hosts have a very responsible philosophy (“leave no bodies behind”). Things that bubble up in exercises are taken care of in an appropriate manner. Also, one of the first tips given during Sunday’s tutorial was to take care of yourself, which could mean to opt out from exercises or just get up and get some water when needed. All in all very comforting things to know about a conference that managed to aim my searchlights back onto how I myself can be the best tool for improving my own effectiveness.

Om det är så här man vinner …

Computer Sweden, 29 oktober 2007. Stockholms läns landsting bränner högar med skattepengar, men har ännu inget system att visa upp. Men, men – den enes död …

“Vinnarna på fiaskoprojektet är leverantörerna: WM-data, HP, Tietorenator (sic), Teleca och Telia, som alla tecknat avtal för att leverera tekniska tjänster till projektet.”

Om det är så här vi definierar “vinna” kanske det vore bra om fler konsultföretag “förlorade”?

Code as Design

When I first read it a number of years ago, I immediately found Jack Reeves’ article “What Is Software Design?” useful, intelligent and correct.

In the article, Reeves presents his arguments for why the source code is the artefact that constitutes the ultimate design of software. Apparently, this article resurfaced with the publishing of Robert C Martin’s book on Agile Software Development, after having led a quiet life in hibernation since its first publication in 1992. It is now often referenced in the agile community.

Why is this important? It is because our perception of what source code is influences our perception of what programming is. If the source code is the design, then programming is designing. If programming is designing, it becomes natural not to accept the opinion that programming should be like factory work. Of course, people who insist that other people’s work should be more factory-like will continue to insist on this until the end of time, but at least knowing there’s a solid argument saying that they’re wrong makes you feel good.

Sadly, outside the circle of agile aficionados, few attitudes seems to have changed. When I talk to people from mainstream organizations that live far from the current agile trends, the word “design” is still associated with the creation of UML diagrams, and the task of “design” is sometimes thought best performed by seasoned specialists. This of course, will be followed by mechanical implementation of said design by monkeys with keyboards.

This is truly a sad example of how easily we settle into inefficient and creativity-strangling stovepipes. A programmer without the mandate to design will either have to fail or break the rules. Luckily, many choose to break the rules, but this has the side effect of creating completely unneeded psychological stress. We all deserve to be able to do our best without having to bend stupid rules. Wouldn’t that be a great world to live in?

If you have not already read the article, do so now.

CIO Sweden manglar beskrivningen av Scrum, men vinner en gratis kursplats

Intresset för lättrörlig utveckling i allmänhet och Scrum i synnerhet är enormt just nu. Många av de företag vi jobbar med börjar uppnå avsevärd förståelse för och framgång med arbetssättet. I denna situation är det lätt att få för sig att även resten av världen förstått vad det handlar om. Men, vi är inte riktigt där än.

I artikeln “Projektledarskolan: ABC för ledning av IT-projekt” presenterar IDG-publikationen CIO Sweden en illa tilltygad beskrivning av Scrum.

Så här beskrivs Scrum, vilket gav upphov till en hel del munter/arrogant mailcirkulation på Citerus:

“Den tredje metoden för IT-projektledning kallas Scrum. Den har fått sitt namn från ett rugbylag och använder också olika steg som planering, kodning, genomförande och test av programvara. Scrum har en egen terminologi och fasta regler kring möten, delmål och hur länge olika planeringsfaser ska vara.”

När jag först läste artikeln reagerade jag inte bara på påståenden likt detta, utan också på det märkliga språket.

Författaren har ett anglosaxiskt namn – Joseph Philips – vilket gav ledtråden att artikeln är en översättning. Lite sökning på den engelska upplagans sajt visade att så är fallet. Här upptäcker man också att inte all skuld ska läggas på artikelförfattaren. När det gäller Scrumcitatet ovan är det istället den svenska översättaren som är ute och cyklar. Så här lyder nämligen originaltexten:

“Scrum is the final leader in IT project management. This approach, named after a rugby term, also uses iterations of planning, coding, executing and testing software. Scrum employs its own vernacular and has some rigid rules about meetings, hitting milestones and the duration of planning activities.”

I den svenska översättningen händer alltså ett antal intressanta saker:

  • Scrum slutar vara en av de ledande metoderna
  • En “rugbyterm” blir ett “rugbylag”
  • Omnämnandet av iterationer försvinner helt, vilket väl får ses som olyckligt när man pratar om en metod som helt bygger på att använda anpassning och granskning för att undkomma de problem traditionell projektstyrning visat sig inkapabel att hantera
  • “Duration of planning activities” blir “hur länge olika planeringsfaser ska vara”, vilket slutligen bevisar att översättaren vet väldigt lite om Scrum och lättrörliga metoder. Planeringsarbete i Scrum görs ju kontinuerligt, i början av varje 30-dagarsiteration (eller sprint som vi scrumnördar säger), och är begränsat till max 4 timmars övergripande urval av produktkrav som ska implementeras, plus max 4 timmars detaljplanering av hur arbetet i sprinten ska gå till). Så långt ifrån en traditionell “planeringsfas” man kan komma alltså.

Jag brinner för att sprida en bättre förståelse för den typ av radikalt nytänkade inom projektvärlden som Scrum representerar, och utsträcker därför ett erbjudande till tidningen CIO: i Citerus namn tar jag mig friheten att bjuda på en gratis kursplats för en av era medarbetare – men ligg på – våra kurser blir snabbt fullbokade!