Tobias Fors

Category: Agile

  • Check-in in a Circle

    When I kick off a class or workshop, I want participants to engage as soon as possible after entering the room. I do work through some practical bits first, but after that I quickly hand things over to participants.

    For a long time, I’ve been using an opening exercise I learned from Ken Schwaber. In it, I ask participants to sort themselves along a line in the room, according to different criteria.

    First, I ask the group to sort itself according to how effective and efficient their current project is (in Swedish, a single word has the connotation of both “effective” and “efficient”). Once sorted, people take turns sharing their situation. Doing this, participants come to see what a wide range of different experiences are present in the room.

    After this, participants get to sort themselves again, this time according to the level of energy they perceive in that same project. Really low energy in one end, and high in the other. We talk about it again.

    Finally, we do the same thing, this time based on how much experience and knowledge of Scrum the participants feel they have.

    Earlier this summer, I participated in a terrific one-week workshop with organizational development pioneers Charles and Edie Seashore. The name of the workshop was “Intentional Use of Self”.

    In one part of the workshop, we talked about how check-ins are an important part of helping a workshop group come together. We also did check-ins every morning. One format we used was based on a fishbowl. Charles and Edie would ask one small part of the group to step into the middle, and tell each other about some thing.

    Today, I decided to try this format out. I asked people in the class to step into the fishbowl based on how long they had been using Scrum.

    First, I asked those with no experience to step in and talk to each other about their current situation and their expectations for the course. After that, those with a few months of experience got to share. Then those with up to a couple of years experience.

    Finally, those of us with longer experience (I joined the fishbowl myself here) stepped into the inner circle a told each other about our experiences and expectations.

    Here’s what I like about Charles’ and Edie’s check-in:

    • Participants face each other, not just me
    • In a circle, it’s easier to speak up
    • When you do speak, you speak with a smaller group
    • Everyone else can still hear you
    • The fishbowl circle puts more emphasis on the likenesses we share, whereas the line creates an exposed situation for those on the ends of a line.
    • We still get to see the different experiences available in the group

    It’s a simple but powerful check-in format. I’m fascinated by the fact that I had to travel half-way around the world to pick it up. I’m glad I did.

    Do you facilitate workshops or teach classes? Do you use check-ins? What kinds of check-ins have you tried so far?

  • Late Again, Thinking About the Cost of Delays

    It’s Wednesday morning, and I’m on the train heading to Stockholm. The train is late, and it’s not the first time.

    One reason delays annoy me so much is that they break my expectations. I’ve made my plans to fit with the train company’s timetable, and now they are not upholding their part of the commitment.

    Then again, when it comes to riding the train from my hometown Uppsala to Sweden’s capital – Stockholm – delays are such an integral part of the experience that I’m no longer surprised when they happen. Curiously, they still annoy me. Maybe it’s because the company running the trains couldn’t seem to care less about the problems the delays are causing me. Somehow, they still manage to act like every single delay is a big surprise to them. I take comfort in the fact that I get some extra time to read and write, as long as I’ve found a place to sit on the train – but that’s another story.

    Anyway, while a train delay may not seem a huge thing to fret about, consider its less obvious effects. When I don’t make it on time to my networking meeting, I miss out on information and networking that would be valuable to me.

    Intuitively, we know that being late costs us, but we easily focus on only one narrow part of that cost: the increased cost of working on something for a longer time. We forget that we also push the rewards into the future, and that might be costing us even more.

    In general, I find that a concrete cost today is easier to grasp than a probable loss in the future. Maybe it’s because we find it hard to think about loosing something we never really had in the first place. I guess this is one of the reasons we make short-sighted decisions.

    If you want to learn more about understanding your cost of delay, Donald Reinertsen’s books are a good investment: Developing Products in Half the Time, Managing the Design Factory and The Principles of Product Development Flow.

  • Johanna Rothman to Stockholm, May 30, 2012

    Author, consultant and teacher Johanna Rothman is coming to Stockholm on May 30, this year. She will be leading a one-day workshop about the agile project portfolio. The course will be in English, and I highly recommend you check it out if you need some inspiration on how to manage in a situation where you have multiple projects going on.

    Here is the course page (in Swedish, but remember, the course itself is in English): http://www.citerus.se/curriculum/724094-agile-project-portfolio-management

    If you haven’t heard Johanna talk before, there’s an interview with her on InfoQ. Watching it is time well spent.

  • Release More Often Without Risking Anything

    Joakim Holm has written an awesome post about breaking through the wall of conventional thinking, smashing a dilemma into pieces, and finding a third option along the way.

    One day soon they realize that “Hey, we’re pretty good. We can take advantage of that and release more often without risking anything.”

    via Breaking through the Wall of Release Mediocrity « The Blogging Terrier | Den bloggande terriern.

  • Pit of Specialization

    In an effort to prove I’m not a perfectionist, I’m publishing this work of art I just created, while sketching out some ideas for an upcoming talk. Being a specialist can be a double-edged sword.

    Have you experienced this pit? Did you like it there, or did you find a way to get out of it?

  • Common Pitfall: Planning Alone

    Many organizations forget that planning is all about the planning. You’ve probably heard the saying: “The plan is nothing, the planning is everything”. For me, that means that the process of planning itself is, to a large degree, what creates belief in and understanding of the plans. The plans will break anyhow (we’ll still do our best to create them), but the more we participate in creating them, the more we believe in them, the more we take ownership for them, and the greater is the chance that we will reach our goals.

    It’s both easy and hard to do this. The easy part is what typically needs to happen. The hard part is gaining acceptance for it, and facilitating the process effectively.

    Gather all the people in a room. Let someone who understands the business side of things start out by explaining what needs to be achieved. Invite everyone else to ask questions. Make it safe to do so. Use your tricks of the trade to make the interactivity happen. Silent brainstorming is one powerful technique; ask participants to silently write down their questions and comments on cards, then work through these together. If you’ve ever presented something to a large group and then asked “any questions”, only to be met by compact silence, you know why a technique like this can be very useful.

    With the high-level goal presented and discussed, and with questions clearly captured on flip charts on the wall where everyone can see that their concerns have been captured, go ahead and work together on the plan.

    By now, there are many techniques in the agile community to make this easier. Collaborative story writing, planning poker, silent sorting, and story mapping are all popular. I’ve just started to learn about system anatomies, which seem to be a powerful way of working together on other views of the work to be done. Whichever techniques you choose, make sure to use them in a collaborative way. Therein lies the key to success.

  • Some Help Examining Your Engineering Practices

    At Citerus, I worked with my colleagues to create a basic form we can use to take a quick inventory of the current engineering practices in the teams we work with. It was originally in Swedish, but I just translated it into English for use at a client.

    We’re not dogmatic, so neither is the form. Nor do we think that anything goes, so there are lots of opinions built into the form. Use it at your own risk. The least it could do for you is to act as a conversation starter.

    So, the form can get your team talking about engineering practices. There are many ways to use the form, and we don’t prescribe a specific way to use it. Among the ways I’ve heard it’s been used are these:

    • Someone used it as a thinking tool for himself
    • The members of two teams filled out the form individually, then got together to compare and discuss their answers
    • One team answered the questions together, and discussed as they went along
    • A manager used the example questions in each section to create a detailed questionnaire, and published it on a web based tool

    The document is available as a share on Google Docs, from where we might update it from time to time. Google Docs isn’t very capable when it comes to formatting, so the lines and page breaks I’ve tried to put in might or might not work for you.

    We’re publishing the document under this Creative Commons license:

    Creative Commons License
    Examine Your Engineering Practices by Tobias Fors is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.

    Here’s the form: Examine Your Engineering Practices

  • Sketchnoting the Concept of Flow

    I like to take stuff and try to express it in as simple language as possible. That’s my way of checking my own understanding of a concept. One concept that comes up often when we talk about lean software development, kanban and agile is that of “flow”. A couple of days ago, I decided to process that a bit.

    One technique I use to process stuff is to sketchnote in Brushes on the iPad. Here’s the video output from my sketchnoting a basic explanation of the concept of flow in development.

    What techniques do you employ to process stuff you want to learn well?

  • Thinking Tools for Conference Reviewers

    Recently, I’ve been reviewing session proposals for Agile 2011. It’s a rewarding job, even though I’m not getting paid for it. I was asked to help out, and said yes because I knew I would learn a lot from it. Since this is the first time I’m reviewing sessions like this, I started out by doing some research into what to look for.

    As a reviewer, my job is not to accept or reject proposals. So what is it? Well, my assumptions while reviewing sessions have been that the purpose of my review is to:

    • increase the chances of the proposal becoming accepted
    • help the session be useful for its participants
    • make the session easy to understand and select for participants

    I already have way too much information inside my head. Reviewing conference proposals from a bunch of very smart people seemed like something that would fill my brain right up and jam it. Therefore, I realized I needed to use some kind of tool to manage the review process. It’s really not different from the monkey that decides to use a stick to get to the banana. I just needed to find the proper stick.

    Right now, my favorite thinking tool is the framework. For example, I just love Esther Derby’s and Diana Larsen’s retrospective framework. It’s versatile and powerful, and I can plug all sorts of fun work right into it. I realized what I needed was a framework for my work on reviewing sessions. However, I also needed to get started on the reviews. For that reason, I pulled out what might be the most basic framework of all. After all, thinking up frameworks can be the ultimate yak-shaving activity, I didn’t want to go there. I’m busy enough as it is.

    I don’t know if it already has a name, but I’m naming this basic framework anyway. I’m going to call it the Common Questions framework. You already know the Common Questions, so this won’t be news to you. Here they are:

    • Why?
    • Who?
    • What?
    • How?
    • When?
    • Where?

    For the review work, I settled for the first four questions: why, who, what, and how. As I researched and reflected on what to look for (Mark Levison sent me some tips, and a link to a great post my Mitch Lacey) I sorted the things I found into the above four categories. I also added one final thing: my bottom line, a super brief summary of my full review. If I can express something very briefly, that probably means my thoughts are clear to me. If I can’t, that’s my signal to think some more.

    Here’s how I use these questions. Having read a proposal, I scan through the questions and write things down as they pop up in my head. Having done a first pass, I work through the questions one by one again, this time going back to the proposal and looking for answers to each question, which – of course – I write down. The set of text snippets I get from this isn’t necessarily very easy to read, so I end the process by working them all into a text that flows reasonably well from start to end. Finally, I try to summarize my thoughts in a single sentence.

    I posted these questions to my fellow stage reviewers in case they could be useful to someone else but me, and to get feedback on them. A couple of the other reviewers suggested that I publish this as a blog post as soon as possible, as a resource to would-be submitters to Agile 2011. I would have done it sooner, but this week has been crazy.

    In case someone still finds use for it, here’s my set of questions.

    – – –

    Why

    The title and introduction will be used to “sell” the session to participants, so they need to not only clearly explain the session, but also read smoothly. The title and the intro will be used in the public conference schedule.

    • Does the title help me see if this session is for me?
    • What about the intro – can I make a first judgement if this fits for me, based on it?
    • Are there intended learning outcomes? … and does it seem like the session design will lead to those?
    • Does anything more need to be said about the session’s clarity of purpose?

    Who

    Quality is value to some person, therefore, we need to know who the session is intended for to be able to judge quality.

    • Do I understand what the intended audience is, and how they would benefit from this session?
    • Are specific roles mentioned? If not, how is the audience explained?
    • What is said about the number of participants?
    • Does the stated level (beginner, expert, etc) seem right? In other words: is this session really for beginners/experts/etc?

    What

    What are the contents of this session?

    • Are the contents specific? … or is it hard for me to understand what will really happen in the session?
    • Is the topic about agile?
    • Is the topic timely, fresh, and unique? … or is it old, stale and has been done too many times before?

    How

    What can be said about the process to be used in this session? (Also referred to as “mechanics”)

    • Does the description match the stated format? Formats can be, for example: workshop, tutorial, talk, etc.
    • Is the text well written and well organized?
    • Does the size of the proposal match the size of the session? In other words: if it’s a longer/larger session, is the amount of detail greater?
    • How will the host be able to scale the session up and down as needed? The number of participants can turn out to be smaller or larger than expected.
    • If the session is big and long: is there more than one host to help make it work?
    • Does the session format model what is taught? For example: Talking about coaching is less helpful than practicing it.
    • How is interactivity handled?
    • Previous experiences with this? Has the session been run before by this host? What is the speaker’s experience level? Any references available?
    • Is there a brief but clear speaker bio, that helps me judge if this session host fits me?
    • In general, does the design seem feasible?

    My Bottom Line?

    – – –

    Do you have experience of reviewing conference sessions? What are your best tips? What do you think about the questions above?

  • Tankar om rollerna i Scrum

    Jag skriver på en bok med arbetsnamnet “Nyckeln till Scrum”. Min erfarenhet säger mig att de som lyckas bäst med Scrum är de som inte bara kan metodens praktiska steg, utan som också förstår varför den är utformad som den är. Beväpnad med den förståelsen öppnar sig också vägen framåt, möjligheten att gå bortom Scrum. Det här är ett avsnitt som handlar om roller, som kanske kommer med i boken.

    Enligt ordboken på min Mac härstammar ordet ”roll” från det inte längre använda franska ordet ’roule’, som syftade på den rulle med papper som skådespelarens roll stod skriven på.

    Till skillnad från andra modeller beskriver Scrum bara några få roller. Tre stycken, närmare bestämt: produktägaren, scrum mastern och utvecklingsteamet. Vi har inga speciella roller för de som deltar i utvecklingsteamet, utan nöjer oss så.

    Varför behöver vi roller överhuvudtaget?

    Det handlar om förenkling. Över tiden kan vi lära oss att närmast intuitivt agera inom ramen för en viss roll, eller bete oss på ett visst sätt i vårt samarbete med en person som verkar i en viss roll. Vi behöver inte hänvisa till en lång lista som beskriver ansvar och befogenheter. Vi vet vad som gäller, helt enkelt.

    Roller som verktyg är ett dubbeleggat svärd. De förenklar, men kan också förenkla för mycket. När du hör att jag arbetat som projektledare associerar du vissa beteenden och mandat med det. Du kanske kan tänka dig ungefär vad jag jobbade med, vilka typer av utmaningar jag brottades med och vilken sorts beslut jag fick ta. Tyvärr har du förmodligen fel. Inga två projektledarjobb är lika varandra.

    En fara med namngivna roller är att vi tror att vi vet vad som gäller när vi egentligen inte vet. Eftersom vi tror att vi vet ställer vi inte frågor om rollerna. Vi beter oss som om vi vore överens och blir förvånade när problem uppstår, eftersom vi var så säkra på att vi förstått varandra.

    Samma utmaning finns när det gäller rollerna i Scrum. På pappret ser de tydligt definierade ut, men i praktiken är det inte är fullt så enkelt.

    När jag undervisar i Scrum brukar jag dela ut varsin specialgjord kortlek till grupperna på kursen. På varje kort står ett ansvarsområde eller en fråga. Jag ber grupperna dela upp korten i tre högar, en för varje roll i Scrum, så att rätt kort ligger på rätt roll. Jag förklarar att de är klara när de är helt överens om sorteringen. Det blir de aldrig.

    På ett av korten står ”Kan du förklara den övergripande arkitekturen?”. Gruppen vrider och vänder på argumenten för att lista ut vem som egentligen borde besvara denna fråga. Det brukar bli jämnt skägg mellan produktägaren och utvecklingsteamet. Några hävdar bestämt att det är utvecklingsteamet som borde ta denna fråga. Andra är lika säkra på att det är produktägaren. Det brukar sluta med att man får lägga kortet åt sidan.

    När vi efteråt går igenom övningen frågar jag deltagarna om de kan definiera ordet arkitektur. Utan undantag visar det sig att de som tycker att produktägaren borde fått frågan anser att arkitektur handlar om produkterbjudandets olika delar, som produktägaren självklart måste behärska för att kunna förklara produkten. De som röstar på utvecklingsteamet tycker istället att arkitektur handlar om den rent tekniska lösningen, som teamet ansvarar för. Olika definitioner leder till olika syn på ansvarsområdena.

    Flera frågekort är svåra att placera eftersom de beror på vilken kompetens som finns var. En fråga lyder: ”Exakt hur är det tänkt att den här dialogrutan är tänkt att fungera?” Somliga svarar snabbt utvecklingsteamet. Produktägaren ska ju inte vara inne och pilla i detaljer, och naturligtvis har vi antingen en separat gränssnittsexpert med i teamet, eller minst en utvecklare som behärskar området bra. Andra protesterar. Deras utvecklingsteam består av programmerare som inte behärskar gränssnittsutveckling, och ser det därför som självklart att produktägaren är den man går till för denna typ av frågor. Ytterligare andra menar att frågan handlar om situationen när teamet inte kan komma överens, och arbetet blir lidande för att ett beslut inte tas. De menar att det är produktägarens jobb att kliva in och ta beslutet. Vid ett tillfälle påpekade någon att det kanske handlar om utveckling av ett gränssnitt för en operatörspanel i ett kärnkraftsverk, och att produktägaren därför är med och bestämmer även om de minsta detaljerna, eftersom de är en sådan avgörande framgångsfaktor för produkten.

    Det är sällsynt att någon helt missförstått någon av Scrums roller – ändå blir tolkningarna helt annorlunda. Sammanhanget avgör tolkningen. Vi är inte ute efter den enda sanna tolkningen, vi är ute efter den tolkning som passar bäst, utan att göra våld på rollens grundläggande skrivelse.

    En fördel med att inte skriva rollbeskrivningar med extrem detaljskärpa är att de blir brett användbara. Nackdelen, om man får säga så, är att vi måste tänka efter mer själva. Vi måste sätta in rollen i sitt sammanhang, och se vad som händer då. Vi måste applicera metoden i vår kontext, lite på samma sätt som skådespelaren måste tolka sin roll utifrån den scen han står på och den pjäs han spelar. Det finns inte en sann Hamlet, lika lite som det finns en färdig definition av vad det innebär att vara produktägare, scrum master eller medlem i ett utvecklingsteam. Allt vi får är papperet med rollen på, sen är det upp till oss att på darriga ben stappla ut på scenen och agera.

    Vilka är dina erfarenheter av namngivna roller på jobbet?