Category: English

  • Feeling Welcome at the AYE Conference

    Out of all the conferences out there, the Amplifying Your Effectiveness conference is surely one of the most curious. Started in 2000 as a challenge (so he told me) from Jerry Weinberg (“so do you think you can do better”) to his protégés who were complaining about talking-heads conferences (“of course we can”), the AYE conference has been going strong for almost 10 years, and has garnered a loyal circle of attendees.

    What stood out for me when I visited AYE for the first time in 2007, was how welcome I felt from day one. It was a stark contrast with a completely different gathering that I visited in Stockholm the year after. At the Stockholm gathering, I remember walking up to one of the hosts, and introducing myself. I explained that I worked for one of the companies sponsoring the conference. His reply was short: “Ok. Nice to meet you”. Then he turned around and walked away. I did not feel welcome.

    Contrast this with the AYE approach. Before the conference begins proper, a pre-conference tutorial is arranged. Intended for first time visitors, this full day session not only works through the core topics of the conference, but also gives ample time for letting people get to know one another. The exercises used aren’t rocket science, which is probably why so many other conferences shun them – they seem almost silly. Participants show and tell their stories, and listen carefully to each other. It works wonders for relationships.

    When the desert sun (AYE is held in Phoenix, Arizona) finally sets on the tutorial day, the conference is kicked off with a big outdoors welcoming dinner. A simple thing too, but very effective. People are seated around round tables of course, so you can really see each other.

    Another seemingly minor detail stands out for me. AYE participants all create their own name tags, and carry them around their neck using a green strap. This means that, as you walk around the large hotel, which is flat rather than high, you constantly say hello to other participants (even those you don’t yet know very well) wearing the signature AYE neck strap.

    If you haven’t tried it already, and you’re interested in the topics covered (teamwork, communication skills, leadership, change) give the AYE conference a chance next year. I’m sure I’ll be there again. And if you think this reads like a commercial, then so be it. Some things are just so good I feel I absolutely have to help sell them.

  • Thank you, Jerry Weinberg

    Jerry, we’ve only known each other for a couple of years, but look at all the things you’ve managed to help me with already. You’ve helped me:

    • See that consulting fits for me, because trying to understand the world and improve it is what makes me tick
    • Become a better consultant, by using more of myself every day
    • Start to understand coaching technique, by watching (very closely) when you do it
    • Become better at helping other people learn, through your wonderfully designed experiential workshops
    • Feel welcome even when I was the only swede at AYE
    • Believe in myself and have the courage to ask for what I want and say what I think
    • Communicate more congruently, so that I more often get the results I desire
    • Not feel threatened by resistance, but really be able to see it as a source of power
    • Understand change better
    • Not blame others all the time
    • Not blame myself all the time
    • Meet loads of intelligent & friendly people at PSL and AYE
    • Make better business
    • Understand how to write more and better

    I’m not sure you knew, but as far as I can see, we’ve had quite a partnership going. Thank you, friend. I want it to go on longer.

  • Roll Around in a Cyber Cart

    I just came across a completely wonderful comment by Lisa Crispin, on Johanna Rothman’s blog. I’ve just read it, and already I love it. I can’t put my finger on why, but for some reason it makes me happy. It probably has to do with my fascination for the concept we used to call cyberspace (ever since I read MIT architecture professor Michael Benedikt’s “Cyberspace – First Steps” in 1994). The discussion on Johanna’s is regarding telecommuting, and Lisa shares a story of how she achieves virtual presence:

    My team set up a rolling cart for each remote team member, with a laptop, webcam, Skype and mic. My webcam displays on the laptop, and my team members roll ‘me’ around to whoever I’m pairing with, or to meetings (rolling through the halls saying hi to people is fun!) I can control the webcam to look for people.

  • 8 Steps to Getting Feedback

    Forget everything you know about agile, about any methods, about any kind of tool you’ve mastered. If there’s only one thing you should do, it has to be this: ask for feedback.

    It doesn’t matter what you do or how you do it. If you don’t stop and ask the people you work with for feedback, you’ll never know exactly how bad you did until its too late.

    It’s not complicated to get feedback, but it can be hard on you. Here is one way to do it.

    First of all, you find a person who can provide you with some feedback. It helps if this is a person you trust. To this person, you present your desire for learning about how you’re doing, and ask if that person is willing to give you some feedback. If the answer is yes, you make sure you sit down in a comfortable environment where you both feel safe and relaxed. Then you ask for feedback on how you’re doing with something.

    You could word it like this: “How do you think I’m doing when it comes to the TPS reports?” Then you sit silent and wait. And wait. You will always get feedback, even if the person you’re asking says nothing at all.

    When you get the feedback, you might be tempted to think that you’re both done. You’re not. You might be tempted to blurt out a defense, because what you’ve just been told seems so offensive. Don’t. Instead, when you’ve heard what the other person thinks, stay silent. Think. Think about what that feedback might mean. Quietly formulate your interpretation of what that feedback really means, then tell it to the other person and ask if your interpretation is correct. Then go quiet again.

    Either the person will say that your interpretation is correct, in which case you can say you’ve received the feedback. Or the other person will correct your interpretation. If this happens, you listen and think some more. Then you present your interpretation of the feedback again, this time incorporating the corrections you just received. Then you listen again, and repeat the process until your feedback giver tells you that you’ve understood things correctly.

    Note that even complete silence can be treated this way. Silence as a response to a direct question is a kind of feedback, which you can try to interpret. If you do, it becomes doubly important to check your interpretation with the other person, because it now comes solely from within your own head.

    If this procedure seems cumbersome, that’s only because it is. It’s not as slow as it seems when its broken down like this, however. Communicating clearly is hard work. We almost always go wrong in some way when we try to communicate with someone else, and it’s often due to the fact that we think we’ve understood the other person, when in reality we haven’t.

    Do I always do it like this? No, and neither will you. In fact, if you’re like me, you’ll do like this far too seldom. Sometimes, we simply lack the energy to go through all the work that’s needed to communicate well. For me, that means I’m least likely to get good feedback when I most need it. It’s at times like those that I get into trouble, and that’s why I have to keep reminding myself that feedback can be scary, but that’s just because I don’t ask for it often enough.

    To summarize:

    1. Find a potential feedback giver
    2. Ask for help
    3. Find a suitable environment
    4. Ask: How am I doing [with regard to something specific]?
    5. Listen.
    6. Think.
    7. Present your interpretation of the feedback.
    8. Repeat 5-7 until you get to hear you’ve understood correctly.
    Will you give me some feedback? Was this post helpful to you?
  • A Visible Pile of Favorite Fieldstones

    I’m a programmer at heart, even though I no longer program professionally. Why? Because I love to program. It gives me satisfaction. So, from time to time, I have to think up little hobby projects that are simple enough for me to handle, but engaging enough to still my lust for coding for a few hours. Here’s my latest one.

    As a writer, my intuitive style of writing has always been to just sit down and start writing. From time to time, I suddenly boot up my Mac, fire up a plain text editor and start writing. Shortly thereafter, I have an article ready.

    Sounds great, right? The problem is that it happens very infrequently. In fact, it happens so seldom that I’m still a pretty inefficient writer. If I was efficient, I would have published my first book by now, for example.

    So, to increase my efficiency, I try to use Jerry Weinberg’s fieldstone method. In its essence, it is very simple. You make sure you always have pen and paper nearby to capture thoughts, ideas, quoutes, facts and other pieces of data and information that come your way. You work regularly to structure these “fieldstones”, and in the end use them to build your final text.

    The method gets its name because, apparently, this is pretty much like building a fieldstone wall. When you build such a wall, you don’t go around looking for the next perfect stone that will fit right into the wall. Instead, you gather all stones that might be useful. Then, once you have a reasonable pile to work from, you build the wall using the stones. Without this method, you would probably be looking for the next perfect stone forever. Or at least for too long, like I do with my writing-only-when-inspired style of writing.

    To be clear, using the fieldstone method does not mean writing about things I don’t feel inspired by. In fact, this is probably Jerry’s main lesson in his book about the method – Weinberg on Writing: The Fieldstone Method. Write only about things you want to write about is a piece of advice that makes perfect sense to me. For me, the fieldstone method is a way of making sure I have the stuff I need right by my side whenever I feel the inspiration coming on, like it just did when I decided to write this blog post.

    Here’s my current inspiration. For handling my fieldstones, I use a tool called Dropbox for backup and synchronization. Dropbox makes sure I have my fieldstones handy on any computer I log on to. I write in a plain text editor, TextMate. However, today I realized that my collection of text snippets could use a bit more transparency. They lie there in their folder, all silent and waiting, and I sometimes forget that I need to wake them up from time to time and shuffle them around and improve them a bit. So I decided to pretend to be a programmer again for a short time.

    I recently installed GeekTool, which I use to show Twitter postings from people that I follow right on my desktop. It occured to me that I would like my fieldstones to communicate with me in the same way. I want them to show up on my desktop, so that I am reminded of and inspired by them. My idea was to write a little script that could process my fieldstone collection, find the most recently changed files, then find the most recently added headlines in those files, and post them on my desktop. I mark up my texts with Textile, a very simple markup system. Headlines for example, always start with the h1, h2, h3 or h4 tag, followed by a dot and a space. I typically add a timestamp as the last part of the headline. So, it shouldn’t be too hard to filter out the most recent headlines and show them in a neat little desktop feed.

    While programming this script, I started looking at my fieldstones with more awareness of how I structure them. I discovered that I use headlines without timestamps quite often. Because of this, I changed my mind and decided that simply listing the ten most recently edited fieldstone files was quite enough. While doing this, I also learned that something in my solution doesn’t handle Swedish characters well. For now though, my on-screen list is good enough, even though å, ä, ö, and some other esoteric characters are garbled. It reminds me of which files I’ve been working on most recently. A small thing, but I think it will help me find more fieldstones that fit well with the writing I’m most focused on right now.

    
    #!/usr/bin/env ruby -wKU
    
    require 'find'
    
    fieldstone_folder = "PATH_TO_MY_FOLDER_ON_DROPBOX"
    files_to_show = 10
    
    fieldstone_files = []
    recent_files = []
    
    Find.find(fieldstone_folder) do |path|
      if FileTest.file?(path)
        fieldstone_files << [path, File.ctime(path)] unless /Fieldstones.tmproj/.match(path)
      end
    end
    
    by_change_date = Proc.new {|x, y| y[1] <=> x[1]}
    paths_only = Proc.new {|i| i[0]}
    
    recent_files = fieldstone_files.sort(&by_change_date).first(files_to_show).collect(&paths_only)
    
    recent_files.each do |path|
      match_file_name = /#{fieldstone_folder}(.*)(?=\.txt)/
      file_name = match_file_name.match(path)[1]
      puts file_name
    end
    
  • Learning Together @ Öresund Agile 2009

    I’ll be speaking at this year’s Öresund Agile conference. As at last year’s conference, I’m intimidated by being on the same program as veterans like Jeff Sutherland and Jim Coplien, but hey, I think I have something interesting to say. Plus, in a very un-Swedish way, I choose to focus on the two guys who came up to me at last year’s conference and said (guy number one), “your talk was the **curse word** best today”, and (guy number two) “your presentation skills are absolutely amazing”. Haha, of course, since I am a Swede, I cannot really believe either of them, but I’m working on that.

    Here’s the elevator statement for my talk this year:

    All organizations can use their potential better. Agile is one way to begin to do so. However, while agile has spread rapidly and resulted in many improvements, many still see it as just a new methodology. At the core of agile lies the belief in the value of being able to move with elegance and ease, even when circumstances change. This means that we can never stop learning about better ways to do things.
    We can never stop and say that we found the one true way of doing things. Organizations that realize this use learning and teamwork to fuel improvments that go beyond what textbooks, industry gurus and competitors say and do. This is the true power of learning together.

    Come to this Copehagen conference if you are in the Öresund area on May 13. You’ll also get to listen to experts like Mary Poppendieck and Henrik Kniberg!

  • Theory of Software Development

    In today’s Computer Sweden, Ivar Jacobsson plugs his company’s latest offerings and requests a theory of software development. I haven’t tried his latest products, so I won’t comment on them. They might be great. However, one thing that puzzles me about the article is the absence of anything concerning useful theories applicable for software development.

    Ivar Jacobsson rails at the prevalance of practices but, at least in this article, doesn’t even come close to touching on any relevant theories. Instead, it seems to me that he promotes even more practices. I’m sure things will clear up for me once I get my hands on his latest toolbox. Unless, of course, I have to pay a lot of cash to get it, in which case I probably won’t get my hands on it.

    In that case, I might just spend my time by learning a bit more from those who seem to come closer to a set of working theories useful for understanding software development work. Like Gregory Howell and Lauri Koskela, in their provocatively titled paper “The Theory of Project Management is Obsolete”. Or like Don Reinertsen, who uses queueing theory to understand certain aspects of getting stuff out the door. Or like Mary Poppendieck, who also likes lean thinking and has made her own attempt at translating those thoughts to our world. I’m not sure these three would necessarily agree with each other if they met, but they are trying to find new ways of understanding the theoretical underpinnings of development work.

  • Learn about congruence and blaming

    Tomorrow is the last day of the Problem-Solving Leadership that is being held this week outside of Uppsala. Participants in the workshop will learn many things through their interactions with each other, themselves and the hosts – Jerry Weinberg, Esther Derby, and Johanna Rothman. It’s a fabulous five and a half day workshop which I myself participated in last March, in Albuquerque.

    One of the key concepts in Jerry Weinberg’s teachings is that of congruence, a concept from the family therapy theories of Virigina Satir. Here is an article by Jerry and Jean McLendon on the topic of congruence and the blaming style of communication. I highly recommend it.

  • 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.

  • gotAPI.com

    UPDATE: Bad link snuck through. Sorry.

    I found a link to gotapi.com on Jon Tirséns blog. Check it out if you dabble in Rails as I do from time to time. Sweet!