Tobias Fors

Category: Agile

  • An Exercise for Defining Done for Scrum Teams

    In this post, I’m going to share an exercise you could try for helping a team start their journey towards a clear and shared definition of what it means to done with a feature in a software product. I’m looking at this from the perspective of agile development with Scrum, but my guess is you can use this even if you’re not using Scrum. I’ve taken a core exercise I’ve used many times to help teams form a first definition of done, and combined it with some debriefing practices I’ve learned over the years. If you want to use this exercise, go ahead. If you run it a couple of times, you’ll be able to improve on it: then I’d love to learn about how you improved it.

    Scrum has taken some flak because many perceive the model as lacking a clear focus on solid development practices such as automated unit testing, refactoring and code or design quality in general.

    It’s true that Scrum does not supply us with a detailed definition of exactly how software should be developed. What we get instead are some general admonitions. From these, we need to create our own set of practices that are suitable in our specific context. Here are the general rules that Scrum gives us:

    • Every sprint should end with a done product increment
    • Done means having something potentially deployable, something of business value
    • Potentially deployable implies a well designed and well tested solution, documented with user manuals if those are needed for the product to be usable

    As a quick sidenote, let’s explore why we like to say “potentially deployable”, rather than “deployable”. Adding that extra word – potentially – gives us a useful, albeit sometimes risky, window of flexibility. What it means in practice is that, if by the end of the sprint we realize that we could gain from deploying, we should be able to do that deployment with just a little extra work. In an ideal world, we would be able to deploy directly – and some companies can do this. However, a company just starting out with Scrum probably cannot do this. They need to improve the way they develop software until they can be “more done” every Sprint, thus acquiring the ability to capture potential business opportunities by deploying early and frequently. The risky part: some will be satisfied with building “good enough” product increments, forgetting that in the long run, insufficient quality very easily turns into terrible quality.

    How does a team move from Scrum’s general definition of done to a detailed description of what done means for them? The team can get there over time, by inspecting and adapting every sprint. If for example, we notice that planning meetings take too long and are fraught with hostile discussions, we might want to explore if we really agree on what it means to be done with something.  If you and I are in the same team, and your definition of done is “if it compiles, ship it” and my definition happens to be “refactored, well designed and thoroughly tested”, we’re bound to have frustration and misunderstandings. If this is the case, a clear and shared definition of done will be very helpful.

    Let me describe an exercise I often use in my classes and workshops. It builds on several ideas to help a team get going with their work on defining what done means to them. The ideas I’ve built the exercise upon include these:

    • When asked if we agree on something, we sometimes say yes just to avoid exposing a conflict, so we need to find a way to safely expose disagreements that prevent us from working well together
    • Agreeing on a definition of something is often hard work, so we could use some help to get going and to avoid some common pitfalls
    • Simply stating that you agree is not as powerful as when you actively participate in the discussion, so we can use a setup that entices as many as possible to step in and actively participate

    Over the years, I’ve tried some different approaches to this. Let me give you a step by step description of the exercise the way I myself will do it the next time I use it. I think it will work well, because the core of it is about really activating participants and in getting the discussion going in an effective and safe way.

    Preparation

    1. On a set of regular size pages, type out a list of items that might be included in a team’s definition of done, such as: “Code is refactored”, “Automated unit tests written”, and so on. Take care to express things clearly. I have a set of four or five pages with things. Some of them are quite uncontroversial (“Code written”), some are things that typically need to be discussed and refined (“Full performance test run”).
    2. Format the pages so that each thing stands on its own line, a couple of centimeters (an inch) high, with large type. Add horizontal separators between each line, so that the sheets can easily be cut into slips.
    3. Add an extra page with blank lines that the team can fill in themselves
    4. Print these pages and bring them – and a couple of scissors – to the workshop.

    The Exercise

    1. Invite the team and set the room up so that everyone can work together comfortably around a large table.
    2. Explain that you are about to engage in an interactive exercise together, and that the purpose of it is to see if we can find a shared definition of what being done with a product increment means to this specific team in this specific project. If the team is new to Scrum, a mini-lecture about how defining done fits into Scrum’s iterative and incremental way of working will also help here.
    3. Hand out the sheets you prepared, and ask the team to cut them up into strips with the scissors you supplied. I prefer letting the team do this work, because doing something physical is an nice way for the them to slowly “warm up” for the hard parts of the
    4. Explain that the blank slips can be used to add missing items, if needed.
    5. While the team is doing the cutting, prepare a flip chart on the wall. On this flip chart, draw a vertical line down the middle, so that you get two columns of equal width. Over the left column, write the heading “Every sprint”. Over the right column, write “Before release”.
    6. Wait for the team to end their cutting, then ask for their attention. Explain the flip chart. Tell the team that you want them to take this flip chart and put it on their table. Say that you want them to sort their strips into the two columns. In the “Every sprint” column, they are to put every item that they agree should be performed by the team during each and every sprint. In the other column, “Before release”, they are to put items that they think are important, but that for some reason cannot be done in every sprint, but that definitely must be done before the product can be shipped out. There is typically no need to go into why something might end up in the “Before release” column, but if the question comes up, briefly explain that for technical or economical reasons, it can sometimes be hard to fit some things into the sprint, and that this may or may not be true for the current team.Defining done

    7. Explain that what comes next is very important. Once you have the full attention of the group, reveal that they will do the sorting under complete silence. This is usually quite surprising. Tell the group that they are to work in silence, until it is absolutely impossible to keep working silently. When this happens, but not before, they can start talking to each other.
    8. You also need to explain how the participants should handle differences of opinion during this part of the exercise. Explain that all participants have the right to place any slip in the place they think it should be. If anyone sees a slip that is in the wrong column, they can just move it to the right column. If you see someone moving a slip you just placed, just move it back again. You’ll notice if some slip keeps moving back and forth a number of times. If that happens, just place it on top of the line separating the columns, and keep working on some other slip. Don’t start talking when this happens, just keep going. When everything has settled down and you can no longer work in quiet, that’s when you can start talking about how to handle those hard to place pieces.
    9. Sit back and watch the team get to work. It’s quite fun. Take this time to practice your skills of observation – look at expressions, gestures, movements and think about what they might mean. If someone starts talking too early, gently remind them to work in silence for just a few minutes more, until most pieces have fallen into place.
    10. After some time, the team will notice it can get no further unless they start talking to each other. When this happens, most uncontroversial pieces have typically found their place, even though you can be sure there’s still no agreement. Depending on the team, you might need to facilitate this lightly. One way to do that is to ask some questions, like “I notice you’ve placed this slip here (point to a slip) – how did you decide on that?” Some teams naturally take to discussing, others need more help to get started.
    11. Let the team take its time working on the sorting. Remind them that we’re searching for a shared and usable definition of done, something that they could potentially use in their current project right away.

    The Debrief

    1. With the slips sorted into columns, hand out some tape and ask the team to fasten the slips to the flip chart they’ve been working on, then to post the whole thing on the wall.
    2. Ask the team: “You’ve created your first definition of what it means to be done with a product increment in a sprint. What are your thoughts now?”
    3. Write down the reflections that come up, exactly as they come up, on an empty flip chart.
    4. Next, write the heading “Suggestions” on a blank flip chart, then ask the team: “What are your suggestions on what you as a team should do next?”. Clearly explain that we’re currently only after ideas, that we’re not deciding anything yet.
    5. Help the team do a silent brainstorming to identify as many suggestions as possible . My experience is that a silent brainstorming results in more and more-varied ideas. To do this, just hand out sticky notes and ask participants to write one suggestion per sticky note. Set a time for this, perhaps five minutes, or maybe ten. I usually go with five, then ask if more time is needed when those five minutes are up. When the time is up, let those still writing finish their notes, then ask participants to take turns posting and reading their suggestions.
    6. With all suggestions up on the wall: do a quick dot voting to gauge the group’s thoughts about the suggestions. Ask each participant to place exactly five voting dots on the suggestions he or she thinks has the greatest potential in helping the team perform better. Explain that they can place the dots any way they want, all on one suggestion or distributed over several sticky notes. Explain that this still does not mean we’re deciding anything – we’re just trying to get a feel for the group’s overall interest in the suggestions.
    7. When the suggestions have all been posted, write the heading “Next steps” on a fresh flip chart and tell the group that the time has come to see if they can decide on some next steps to take. Ask the group: “Can you agree on some next step?”. Someone typically shouts out one of the previously posted suggestions, or something that is a synthesis or rewording of one of those suggestions. Help the group formulate the next step as a clearly stated action. Ask the group if they agree that doing this action is desirable. Use thumb voting if needed: thumb sup means agree, down means don’t agree, sideways means “I don’t care, so I’ll go with what the majority decides on”. If someone shows a thumbs down, work with them to modify the suggestion or create a new one, until agreement is reached. If no thumbs are pointing down, the group has decided.
    8. Ask for more next steps, until you have enough to see that the team will take some clear next steps to keep moving with the work they’ve just done on defining done. If everything goes well, the team will suggest activities that relate to incorporating the new definition of done into the daily work. If things go less well, they might not – but this is also information, and you should be glad that it comes up now and not later, when you’ve tried to build a product without first agreeing on how to work together. Don’t be surprised if the team comes up with really inventive and ambitious ideas, and choose to act on them – my experience is that this happens more or less every time I work this way with a team.

    The first definition of done agreed upon by a team in an exercise like this will not be the final one. Whatever you do, don’t print out and laminate this definition. As a team learns more, builds more capacity, and learns to work better together, they might realize that they can improve their definition of done. A team using Scrum then implements these improvements, and it does this in a way that ensures that the whole team is in on the changes.

    A word of caution. You might think this whole exercise seems like a waste of time. After all, how hard is it to create a solid definition of done and just hand it to the team? In fact, if you’ve been in the software business for a few years, that’s not hard at all. However, creating that list does not mean that the team will use it. Defining done is more about finding consensus than it is about listing an optimal set of practices. I’ll take a less impressive but widely shared definition of done over an ideal but ignored list any day. If we know where we stand, we can always improve from there.

  • A Stack Exchange on Scrum

    Intrigued by the possibilites of the Stack Exchange platform, I’ve proposed a site for questions & answers on the topic of Scrum. On the Stack Exchange platform users:

    1. Post questions and answers
    2. Vote answers up or down, depending on how helpful they think the answers are
    3. Grow their ability to moderate the site as they engage more with it

    I like how the creators of the platform aims to put the community in the driver’s seat, and I’m hoping this will take off. We’ll see about that: first, we need a number of early adopters to help define the site. Then we need a whole bunch of people to commit to working with it. If we get that, we’ll have a nice place to go for questions and answers from the Scrum perspective.

    Is this something? If you think it is, you should go and check it out now.

  • Use Improvement Stories to Make Your Retrospectives More Effective

    <plug>I teach a one-day class on retrospectives. It’s in Swedish only for now, but if that’s not an obstacle, you should read about it on the Citerus web site.</plug>

    I love to use the user story format when I help teams plan their work. It can sometimes be hard to break user stories down into useable chunks, but their format is very easy to use: As a <type of user>, I want to <do what with the product>, so that <this value will come about>. There are different ways to format stories, but the essence remains the same. Use a simple format to quickly shake out some key information about a given requirement.

    Maybe you’ve noticed that it’s not just during planning that we have hard time putting our thoughts and desires into words. Teams that do retrospectives frequently find that it can be very hard to get valuable output from these meetings. One cause of this, which is easy to remedy, is the use of inexact language.

    If you’ve brainstormed improvement suggestions with your team, you might have seen a suggestion like this (written on a post-it note): “Better test”. Or maybe even terser: “Cooperation”.

    These notes are a good start, because there’s an interesting story behind them. The problem is that we might have to spend considerable time pulling that story out. There is a simpler way to get there.

    Nowadays, I use the story format not only in planning meetings, but also in retrospectives. Whenever I ask a team to brainstorm improvement suggestions, I ask them to do it using a template I supply. I ask them to write Improvement Stories.

    An improvement story is quite easy to write, and looks like this:

    Because <description of problem or situation>

    we should <description of suggestion>

    so that <description of desired result>.

    I find that asking teams to supply their suggestions in this format results in contributions that are well considered, easy to understand and quick to process.

    Have you tried using improvement stories? Drop me a note in the comments section!

  • Att lära sig tillsammans – Agila Sverige 2009

    På konferensen Agila Sverige 2009 gjorde jag ett blixttal på temat lättrörlighet och lärande, med titeln “Att lära sig tillsammans”. Konferensarrangörerna filmade alla tal, och mitt har nyligen blivit publicerat. Bäddar in det här nedan.

    Lära sig tillsammans – Tobias Fors from agilasverige on Vimeo.

  • Agile Testing

    I spent the better part of last week at the Eurostar 2009 testing conference in Älvsjö, Sweden. I’ve never worked as a professional tester myself, but the topic of testing is gradually becoming more interesting now that more effective and humane approaches to testing are spreading widely.

    My reason to go to the conference was to meet friends from AYE, to network and to scout the world of test. For almost seven years now, I’ve been using, teaching and introducing agile development with Scrum at all kinds of companies in Sweden, and while I’m no testing expert, I often meet testers who struggle with how to be of best value in their new cross-functional teams. I need to understand the realities of testing to be able to help my clients.

    Before I got into consulting to project teams, I was a programmer. I remember one time when I tried to convince a contract tester at a client company to help us test the product we were developing. He was very hesitant, because he was a busy person. His services were in high demand, because he could find bugs everybody else missed. After some cajoling, he at least agreed to consider it, and said he might be able to help us if he found some spare time. He also added: – I will help you under one condition: I will execute no written test cases from you.

    Turns out this sought after tester was actually a student working extra hours doing testing. Because he had no formal training in testing, he would exercise the product in many different ways, and apparently in many more ways than the employed testers would, since he found many more defects than they did. He used his intelligence and skill to test the product.

    In the end, he never found the time to help my project, and we had to manage our own testing using a combination of automated unit tests and manual testing. While doing this, we found a possible bug in the software embedded in the hardware we interfaced with. We presented our theory to the responsible developer, who dismissed us by explaining that a bug in that code was impossible, because it had been tested and used for some time. Besides, wasn’t it quite unlikely that two Visual Basic programmers would find a bug in C++ software?

    As luck would have it, a colleague from a previous project was still on site, and he was a true C++ ace, who I knew had learned how to avoid many of the vicious traps in that language. We asked him if he could help us, which he gladly did. Late one day, he checked out the code on his laptop to have a look at it. The next morning he came back and told us we had indeed found a defect, and he knew where it was. We asked him how he knew, since he couldn’t possibly have run the software from the comfort of his living room couch, where he told us he had found the bug. He told us he had simply read the code line by line until he found the defect.

    With our C++ ally as backup, we went back to the programmer doing the embedded programming. Our ally simply proclaimed: – You have a bug, to which the embedded guy replied. – Oh, do we? Ok. They then worked together to fix it.

    So what does all this have to do with agile? Well, agile is about being able to clearly understand our true progress, so that we can behave more effectively as we learn more about reality. Among many other things, this requires insight into the current status of the product under development. Testing can give us this information.

    I’ve noticed that those who struggle most with testing in agile projects are those who either cannot see the need for testing, or who can’t let go of the traditional scripted way of testing software. They insist on doing no testing at all, or on creating detailed test scripts for manual execution, and this causes problems for them.

    If you want to learn more about alternatives to scripted manual testing, you should check out the videos I’ve inlined below. The first one is an interview with “testing naturalist” (gotta love that) James Bach, the second is (a few years old but still excellent) Google Talk with Elisabeth Hendrickson.

  • Svensk bok om Scrum på gång

    På AYE-konferensen häromveckan nämnde jag i förbifarten för Jerry Weinberg att jag håller på att skriva en bok, och att jag kommit ganska långt med den, även om den är långt ifrån klar. Jag följer Jerrys råd att helt enkelt först skriva den bok jag själv vill skriva, för att sedan se om den är publicerbar. Skulle den aldrig komma ut har jag ändå lärt mig enormt i processen, och i dessa dagar är det ju heller inga problem att publicera den som en PDF på nätet som alternativ lösning.

    Jag vet sedan tidigare att Jerry tycker att det är dags att marknadsföra sin nya bok långt långt innan den är redo för tryckning. Eftersom kongruens är ett nyckelord för honom agerade han i enlighet med vad han lär ut, och passade på att berätta om min kommande bok i en fullsatt workshop på konferensen. Det var lite överraskande förstås, men helt OK. Varför inte berätta om det? Eller vänta, jag har massor med anledningar (“någon knycker idén”, “den kanske aldrig kommer ut, och då får jag skämmas”, “man ska inte räkna pengarna innan smöret är sålt” och “jag som inte ens kan komma ihåg ordspråk rätt, hur ska jag kunna skriva en hel bok”). Men alla de anledningarna känns som svepskäl, så jag struntar i dem och skriver glatt vidare.

    Vad boken ska handla om? Lättrörlig utveckling med Scrum, såklart, eftersom det är det jag ägnat mig åt i snart sju år. Det finns många andra böcker på temat, men jag tycker att det saknas en lättläst bok på svenska, som dessutom hittar rätt balans mellan teori och praktik.

    Min bok ska ge praktisk handledning, men framför allt hjälpa dig som läsare att förstå varför ett visst sätt att bete sig kan vara mer effektivt som ett annat.

    Jag vill hjälpa dig att komma vidare även när grundreglerna i Scrum visar sig svårare att leva upp till än du först trodde. Jag vill dessutom immunisera dig som läser boken mot metodövertro. Inget verktyg går att använda till allt, men det kan ändå vara användbart att lära sig det. Så även med Scrum.

    Boken ska den vara lättläst också, nämnde jag det?

    Vad vill du absolut ha med i en svensk lättläst bok om lättrörlig utveckling med Scrum? Du borde berätta om detta för mig i kommentarsfältet härnedan!

  • Att lära sig tillsammans – Agila Sverige 2009

    Det här är mina presentationsbilder från mitt blixttal på Agila Sverige 2009, som handlade om lärande, och hur vi kan använda förståelse för läroprocessen för att lära oss bättre tillsammans.

    Att Lära Sig Tillsammans – Tobias Fors – Agila Sverige 2009

  • Agila Sverige 2009, (första halvan av) Dag 1

    Idag tog jag tåget till Stockholm för att delta på Agila Sverige 2009 Agila Sverige är en två dagar lång konferens som är billig att delta på, eftersom den sponsras av några företag, däribland Citerus. Arrangemanget sköts av några flitiga eldsjälar inom agilerörelsen i Sverige, som ska ha flera stora tack för detta. Besökarantalet tror jag låg på runt 180 personer.

    Förmiddagen var idag, precis som förra året, vigd åt blixttal. Med det menas 10 minuter korta tal som oftast är lika innehållsrika som ett mycket längre tal, men betydligt mer uthärdliga.

    Här är mina anteckningar från de presentationer jag lyssnade på idag (det var två spår som man kunde jogga fram och tillbaks mellan).

    Maria Thelin

    Först ut var Maria Thelin, som delade med sig av några uppenbarelser hon fått när hon jobbat med att införa Scrum i större organisationer de senaste åren. Hon inledde med att förklara att hon skulle kunnat kalla presentationen “hur man skapar en oagil agil metod”, och nämnde några utmaningar hon stött på: sponsorer som backar ur, att man underskattar förändringen som krävs och en ovilja att förändra sina befintliga arbetssätt.

    Maria frågade sig varför det egentligen är så svårt att uppnå den flexibilitet och leveranshastighet som företag är ute efter. Svaret blev att befintliga beroenden i organisationen förhindrar förändring. Maria menade att om dessa beroenden får kvarstå, så är risken stor att man skapar sig en oagil agil metod, och att agile förutsätter att beroendena inte finns kvar, och även att agile utgår från att vi har en bra objektorienterad arkitektur och använder saker som TDD.

    – – –

    Mina reflektioner: alla organisationer har sina befintliga mönster, som är mer eller mindre svårförändrade. Om vi vill förändra dem måste vi börja med att förstå dem. Visst är det frusterande att det är som det är, men det är som det är för att det var som det var. Det finns en historia bakom dagens situation, och den historien handlar ofta om gårdagens lösningar. Någon har kämpat lika hårt som vi gör nu för att förändra organisationen, och resultatet är det vi ser idag.

    Visst känns det som om man vill göra revolution ibland, men revolutioner tenderar att följas av en kontrarevolution: om några år kommer någon annan att slita sitt hår över de lösningar vi fick till stånd i vår revolution. Hur tråkigt det än kan låta tror jag själv mer på en långsam och målmedveten förändring mot ett attraktivt mål.

    Scrumreflektion: en av anledningarna till att jag gillar Scrum, och kanske ett skäl att andra inte gillar Scrum, är att det är ett ramverk som inte gör några anspråk på att vara en slutlig lösning. Många verkar fortfarande se Scrum som otillräckligt, när själva poängen är att varje process för mjukvaruutveckling är otillräcklig. Vi måste alltid fylla på med lösningar som fungerar i vår kontext, och vi måste alltid arbeta med att hela tiden öka vår förmåga.

    De flesta av oss börjar inte från ett tillstånd där vi har perfekt kunskap om objektorienterad design eller där vi vet hur man löser konflikter mellan människor. Det spelar ingen roll: vi måste ändå planera och följa upp vårt arbete, och där kommer Scrum in. Vill vi sen lyckas på en konkurrensutsatt marknad måste vi dessutom bli bättre väldigt snabbt, och jag tror att det var det Marias presentation tog fasta på: frustrationen över att det nästan alltid känns som om det går för långsamt. Marias råd är väl värda att repetera: förklara vad det innebär att börja jobba lättrörligt, eller sänk förväntningarna på resultatet direkt.

    Ola Ellnestam – Jag vill ha förbättring men ingen förändring

    Ola Ellnestam körde sin presentation utan slides och med hjälp av skrivkort som stöd för minnet. Han förelästa om vårt förhållande till förändring. Vi vill gärna ha förbättringar, men helst utan att behöva genomgå förändringsarbetet. Det underbara exempel på hur det inte går till som fick mig att garva var: “Tjenamors, jag är din nya kondis, får jag klättra in i din kropp”. Underbart! Humor som stöttar budskapet i presentationen är alltid välkommet.

    Efter humorn följde Ola upp med att testa vår förändringsbenägenhet. Han vill veta när vi ändrade vår frukost senast, och lät oss göra en övning som var väldigt lik en jag lärt mig från Jerry Weinberg. Jerry brukar låta folk korsa händerna fel och fråga hur det känns. Ola lät oss korsa armarna fel och utmanade oss att sitta så, så länge vi orkade. Jag gav upp direkt. Faktum är att jag vet inte om jag ens lyckades korsa armarna fel, det var svårt. Bra övning.

    Ola påminde oss om att “ständiga förbättringar” också betyder “ständiga förändringar”, och exemplifierade mycket tydligt med hur drygt det vore om vi till exempel bytte valuta nån gång i veckan. Ganska smärtsamt. Värt att tänka på för den som jobbar med förändring i någon form.

    Måns Sandström – Evolution på jobbet

    Måns Sandström från nystartade Adaptiv drog fram Darwin och påminde oss om att variation och selektion ger evolution. Måns argumenterade för att vi är bra på selektion (som när vi väljer Oracle, SAP eller Scrum), men fruktar variation. Han illustrerade fenomenet med ett citat från verkligheten: “Har vi nu skrivit ned exakt hur vi gjorde, så att vi kan göra det igen på exakt samma sätt?”

    Uppmaningen från Måns var att omfamna variation, till exempel genom att pröva något nytt i varje iteration, ett tips han snappat upp från Mike Cohn (som för övrigt kommer till Sverige i höst för att hålla kurser).

    – – –

    Mina reflektioner: Absolut! Vi behöver bli bättre på att våga pröva nya sätt, och fortsätta så. Risken med att standardisera är att vi driver ut all möjlighet till att göra nya upptäckter. Samtidigt är det viktigt att inte drabbas av standardskräck: standarder har definitivt sin plats. Tricket är att våga kasta ut dem och ersätta dem med nya så fort de inte duger längre, eller så fort det finns ett bättre sätt att göra saker och ting. Förslag: låt team etablera sina egna standarder, och granska sin egen efterlevnad. Hjälp dem att se hur deras egna standarder kan göras mer effektiva.

    Niklas Björnerstedt – Strategier för smidig utrullning (i replacementprojekt)

    Niklas, som efter tolv år i Norge började med att be om ursäkt för sin norska brytning (en sorts Dolpheffekt får man väl säga) berättade om sina tankar kring produktionssättning. För Niklas är smidighet (som man kallar agile i Norge) starkt förknippat med förmågan att sätta i produktion ofta. Scrums mål att vi ska ha potentiellt levererbar produkt i slutet på varje sprint tyckte han var ett dåligt surrogat för riktig produktionssättning. Bara genom sann produktionssättning får vi äkta feedback.

    Konceptet minimal deployable entity är ett begrepp som Niklas myntat, inspirerad av idén om minimal marketable features (Denne, Huang). En MMF handlar om att fråga sig vad som skulle ge kunden mest värde. En MDE handlar om hur man minimerar risk i projektet.

    Efter denna inledning berättade Niklas om sina tankar kring hur man minimerar sina MDE:er. Principer + mönster = strategier, var den formula han presenterade, och följde upp med några exempel.

    Ett exempel på en princip var principen om begränsad produktionssättning. Om man vill ha den riktiga feedback man får från en riktig produktionssättning kan man leverera ut till ett fåtal användare. 6-8 användare kan enligt Niklas räcka för att få bra återkoppling. Det handlar alltså inte om att skicka ut en version till en testgrupp, utan om en faktisk lansering till en begränsad krets.

    Niklas ska berätta om sina principer och mönster på Agile 2009, och hoppas jag, publicera dem på något sätt, men jag minns inte vad han sa om just detta.

    – – –

    Mina reflektioner. När vi i Scrum pratar om att ha potentiellt leverbar produkt i slutet på varje sprint är det just för att vi vill kunna skeppa ut något till produktion tidigt. Visst kan det tänkas vara bättre att ha helt releasebar produkt varje sprint, men ofta är det inte görbart, och kanske inte alltid heller helt önskvärt. Jag kan tänka mig situationer (t.ex. vid nyproduktsutveckling) där det är en bättre strategi att fokusera på andra saker de första sprintarna än förmågan att produktionssätta. Skjuter man på det för länge skjuter man sig såklart lätt i foten, dock.

    När det gäller risk är det viktigt att komma ihåg att det finnas minst två stora riskgrupper när vi bygger nya mjukvarusystem. Dels risken att vi bygger fel produkt, dels risken att vi bygger produkten på fel sätt. En riskhantering som vi gör med Scrum är att snabbt provtrycka processen genom att köra igenom den från ax till limpa (alltså från krav till potentiellt leverbar produkt). En annan är att vi bygger produkten i körbara inkrement, så att vi har möjlighet att inspektera dem och se om vi är på väg att bygga rätt produkt. Rätt produkt handlar om marknadsrisk. Att bygga på rätt sätt handlar om teknisk risk. Niklas metod att produktionssätta tidigt kan angripa båda dessa risker, eftersom vi dels upptäcker om vi utvecklar på ett sätt som leder till en levererbar lösning, och dels ser om lösningen löser problemen (genom den feedback vi får när vi produktionssätter).

    Om man kopplar ihop Olas presentation med Niklas får man en intressant vinkling. Det finns mycket att tjäna på att produktionssätta tidigt, men också många utmaningar. Att ge kunderna en ny version varje vecka kan nog bli tufft – men med Niklas princip att göra begränsade driftssättningar kommer vi ju betydligt närmare en bra lösning. Gäller bara att hitta de där första villiga kaospiloterna.

    Joakim Holm – Samarbete och allt vi gör för att förhindra det

    Joakim tog sin an samarbete som fenomen, och serverade en kavalkad av saker som kan förhindra det. Organisatoriska gränser, rumslig separation, separation i tiden, specialisering och resursutnyttjande avhandlades under presentationen.

    Avslutningen på presentationen innehöll ett exempel på ett fascinerande samarbete. När Apollo 13 fick problem klev astronauterna över i den för gruppen underdimensionerade landningsenheten. Väl där fick man såklart problem med koldioxid. Nere på jorden sattes då ett specialteam ihop med uppdrag att lösa problemet. Det gjorde man, och det resulterade i att astronauterna själva kunde bygga en liten mojäng som filtrerade luften ombord.

    – – –

    Mina reflektioner. Jocke är dead on. Samtliga av de problem han tog upp är oerhört allvarliga för mjukvaruutveckling, och det har att göra med stora kunskapsinnehåll vårt jobb har. Så fort vi börjar separera oss måste vi jobba mer med att överföra externaliserad kunskap mellan individer, vilket är en form av “kall” kunskap. När vi, som klyschan lyder, arbetar på samma sida – nära varandra, med samma mål, på samma plats – kan vi överföra kunskap genom att observera varandra, ha snabba utbyten och helt enkelt lösa problem på mer kreativa och effektiva sätt. Det är anledningen till att iterationer och tvärfunktionella team är en så intressant kombination.

    Anders Ivarsson – Retrospektiv

    Anders öppnade med att beskriva hur många känner inför retrospektiv. Man tycker att det lätt blir en negativ eller anklagande stämning, att det bara blir prat och att man tar upp samma problem om och om igen.

    Anders tipsade om att få in mer variation i retrospektiven, att byta facilitator och att pröva nya tekniker för retrospektiven. Han rekommenderade också att man inte ska försöka söka en lösning under retrospektiven.

    – – –

    Mina reflektioner. Jag känner igen mig i Anders erfarenheter. Däremot är jag inte helt säker på att jag förstått det här med att undvika att söka lösningar. Jag köper att man inte ska vara för het på gröten när det gäller lösningar, men samtidigt ser jag en risk i att skippa lösningsarbete helt och hållet. Visst, allt kan inte lösas på ett retrospektiv, men en del saker kanske går att komma överens om redan där. Behöver fundera mer på detta känner jag.

    (Paus)

    Bollade lite med Esther Derby som kan del om retrospektiv. Hon håller med om att alltför många börjar med lösningar, och skriver att hon vill att hon vill att team ska ha dataunderlag och förståelse för problemen först, och sedan jobba med lösningar i mån av tid. Jag frågade om hon tycker att det finns några skäl att skippa lösningar helt, men hon kom inte på några. Tvärtom kan lösningsarbetet göra att retrospektiven känns mer hjälpsamma. Jag håller med.

    Tobias Fors – Att lära sig tillsammans

    Min egen presentation var en 10-minutersvariant av den presentation jag gjorde på 30 minuter på Softhouse Öresund Agile för några veckor sedan. Det var betydligt roligare att göra den på 10 minuter, inte minst för att jag fick prata snabbt, vilket jag alltid gör ändå, och älskar. Långsamt prat söver mig, om det inte är extremt intressant, i vilket fall jag kan lyssna på hur släpiga talar som helst. Nästan.

    Reflektioner på min egen dragning: borde fokusera på chefens ansvar för lärandeprocessen, och kanske på något ännu tydligare sätt utmana publiken att gå ut och leta rätt på allt kunnande som redan finns i deras organisationer. Det grämer mig att så mycket kapacitet får gå outnyttjad. Om Sverige ska kunna bli ett världsledande mjukvaruland måste vi vara världsledande på att bygga ta till vara lärande i våra organisationer.

    Peter Tallungs – Utmaningar och möjligheter för den agila rörelsen

    (Börjar bli lite trött i ögat, så nu blir jag mer kortfattad)

    Peter Tallungs klev fram som en förebild med en slide stack som bara var två bilder hög: en presentationsbild, och ett framväxande diagram som väl illustrerade hans poänger.

    Peter argumenterade för att vi som jobbar med agile måste våga kliva ut och se bredare på saker och ting, åtminstone sträcka oss ut och innefatta verksamhetsutveckling. Han slog ett slag för att plocka fram det goda ur “lite äldre metoder” och utnyttja det. Enligt Peter har agilerörelsen fastnat i en låda med dimensionerna “programmering”, “endast en applikation”, och “nyutveckling”. I verkligheten har verksamhetsutvecklingen idag, enligt Peter, flyttat in i IT-systemen, vilket gör oss som utvecklar dem till affärsutvecklare.

    – – –

    I viss mån är jag benägen att hålla med Peter – det är lätt att ha en för smal syn på saker och ting. Samtidigt är det kanske det som gjort agile så framgångsrikt. Att försöka täcka alla flanker resulterar ofta i lösningar som blir överkrångliga. Omvänt ger möjligheten att fokusera på en del av problemet en enkelhet och tydlighet som behövs när man ska bygga komplexa produkter. Tanken med Scrum är ju just att försöka skapa en situation där team kan vara produktiva.

    Men visst, självklart måste vi höja blicken och expandera våra visioner för det här med lättrörlighet. Gör vi inte det blir det bara ännu en “programmeringsmetod” med begränsat genomslag.

    Chris Hedgate – Medvetenhet är det första steget till förbättring

    Chris öppnade med en sjukt snygg seriestrip som jag hoppas att han publicerat någonstans på nätet. Han hade tydligen låtit någon rita den baserat på en sann historia Chris hört talas om. Han fortsatte med att berätta om den frustration många känner efter att ha försökt, förgäves, att initiera en förändring. “Jag har köpt alla böcker och gett mitt team att läsa, men ändå händer inget”, som man kan få höra.

    Chris förklarade en fyrastegsmodell över kompetens. Vi kan vara omedvetet inkompetenta, medvetet inkompetenta, medvetet kompetenta, och omedvetet kompetenta. Beroende på var vi befinner oss har vi helt olika behov. Den som vill jobba med förändring behöver känna till detta, så att man kan anpassa sitt stöd för individen, enligt Chris.

    Omedvetet inkompetenta behöver inspiration. Medvetet inkompetenta behöver kunskap. Medvetet kompetenta behöver öva. Omedvetet kompetenta behöver reflektion.

    – – –

    En helt lysande dragning, som passade perfekt för mig. En teoretisk modell kombinerad med praktisk applicering av den. Jag försökte bygga upp mitt tal på samma sätt, men jag tycker att Chris lyckades mycket bättre. Jag frågade Chris på lunchen hur man vet var någon befinner sig, eller om man ens kan veta det. Vi kom inte fram till något just då. Ett läromål för framtiden för mig.

    Lena Norman – En fyrarummare för förändring

    Min Citeruskollega Lena Norman höll en intressant dragning om förändring. Hon ritade upp Claes F Janssens modell som beskriver förändring som en passage genom en lägenhet med fyra rum. Det börjar bli sovdags på allvar för mig nu, så jag återberättar inte modellen här, utan väntar snällt på att Lena ska skriva ihop en sammanfattning själv, hehe. Den finns även beskriven här.

    – – –

    Lenas presentation var givande, eftersom den gav ett nytt perspektiv på en process jag tänker på på ett helt annat sätt. För mig verkade Janssens modell nämligen väldigt lik Satirs förändringsmodell, som jag lärt mig av Steven Smith och Jerry Weinberg. Styrkan med fyrarummaren kanske kan vara den väldigt visuella bilden av att passera genom en lägenhet. Ska läsa mer om den och jämföra med det jag kan om Satirs modell.

    Fredrik Hedman – PEJL + PENG + SCRUM

    Fredrik tog upp att det finns många Scrum Masters, men inte så många produktägare. Som produktägare har han själv känt behovet av att komplettera Scrum med andra modeller. Fredrik tyckte också att produktägaren är den viktigaste rollen i Scrum, vilket motsades av någon i publiken som ropade att alla roller är lika viktiga.

    – – –

    Det är en vanlig uppfattning att Scrum är en komplett modell av hur utveckling går till. Så är det inte. Tvärtom behöver man fylla Scrum med det som behövs i just den egna situationen. Att komplettera Scrum med t.ex. PENG-modellen för nyttokalkylering är alltså ingen dum idé. Själv brukar jag dock bli mer försiktig när man börjar prata om att plocka in projektstyrningsmodeller. De leder ofta tanken tillbaks till ett sekventiellt arbetssätt. Men visst, allt funkar om man gör det med måtta och eftertanke. Även Scrumprojekt har en startfas, även om vi vill att den inte ska vara en sexmånaders förstudie.

    Torbjörn Kallin – Problemfokuserande retrospektiv

    Även Torbjörn tog fasta på att retrospektiv kan bli för lösningsfokuserade. Han föreslog att vi helt enkelt förbjuder lösningsdiskussioner på retrospektiv. Torbjörn visade också ett exempel på en typ av 5-varför-användning, för att illustrera hur man kan gå djupare och hitta ett problems rotorsaker

    – – –

    Åter denna rädsla för lösningar. Problemet är inte att vi pratar lösningar, problemet är att vi pratar om lösningar utan att ha en förståelse för vilket problem de angriper. Förslaget att eliminera lösningsdiskussioner känns för mig som ett exempel på en lösning som angriper ett symptom, snarare än en rotorsak.

    Jag tror att retrospektiv, eller återblickar, som slutar med lösningsarbete känns mer produktiva än de som inte gör det.

    Humanova – Hur man dödar konflikter med verbal judo

    I den här presentationen bjöds vi på lysande presentationsteknik. Fredrik Fleetwood och en kollega vars namn jag inte antecknat och som inte finns med i programmet av någon anledning visade oss ett exempel på en produktiv och en mindre produktiv konversation. Deras modell för at göra detta såg ut så här:

    Kontakt (känslor) -> Dialog (fakta) -> Gemensam lösning (framtid)

    I korthet: särskilt i en stressad situation tjänar vi på att börja med känslorna. Om vi inte hanterar dem i början av den kontakt blir det nästan omöjligt att gå vidare med annat.

    – – –

    Reflektion: en inspirerande presentation. Så tydligt det blev tack vare rollspelet. Mästarklass. Pedagogiskt. Roligt.

    Joakim Sundén – Så använder vi lean i vårt Scrumteam

    Joakim berättade om hur man använt visuell styrning med enkla medel i ett team, och kombinerade detta med att presentera utvada leanprinciper.

    – – –

    Reflektion: bra verktyg, viktiga saker, men för mig inte så mycket nytt.

    Open Space

    Efter lunchen var det open space. Jag deltog bara i en session innan jag åkte tillbaks till Uppsala för att simma med min dotter – det missar jag inte!

    Jag upptäckte att jag blev besviken över att det öppningen av forumet inte skedde i en cirkel. Det borde ha varit görbart trots den stora gruppen. Nu blev det en stor folkmassa som bara riktade sin uppmärksamhet mot de som stod på scenen. På något sätt kändes det inte så open spejsigt att börja med att titta på varandras nackar. Men, men, agendan såg ut att ha blivit knökfull ändå, så kanske ingen skada skedd. Dock intressant att så många som aldrig skulle kompromissa med agile så lätt kompromissar med “givens” i open space.

  • Visuell styrning med kanban (2): Enkla, kraftfulla verktyg

    I det förra inlägget skrev jag om bakgrunden till att jag börjat arbeta med visuell styrning med kanban. Det här inlägget ger en första titt på verktygen vi kan använda.

    Utöver ett uppdrag att slutföra och kunskap om hur kanban fungerar behövs följande för att komma igång med en egen kanbantavla:

    • En rymlig whiteboard med tillhörande pennor
    • Post-its i olika färger
    • Pennor som det går att skriva tydligt på post-its med (vanliga bläck eller blyertspennor ger så tunn skrift att det blir svårt att läsa vad det står när man står en bit från whiteboarden)

    Att jobba med en kanbantavla (för till exempel sitt drifts- eller supportteam) handlar om att synliggöra sitt arbete så att man istället för överbelastning kan ha rätt mängd arbete igång, och därmed få fler saker klara snabbt och med rätt kvalitet.

    Vi använder post-its (eller något annat flyttbart) för att dokumentera vad vi jobbar med – en sak per lapp. Målet är inte att dokumentera varenda liten sak som görs. Tvärtom funkar det hela bäst om man på lapparna skriver ned små nyttiga delresultat, snarare än aktiviteter.

    Arbetets aktuella status visar vi genom att placera våra lappar på rätt ställe på whiteboarden. På den har vi nämligen ritat upp vår grupps arbetsprocess, så att lapparna kan sättas i kolumner som visar de olika steg arbetet går igenom, från ax till limpa.

    Vi vet att kanbantavlan börjar fungera när vi med en snabb blick kan se vilket arbete som väntar, vad som pågår, och vad som gjorts klart. Från dag till dag kan vi lapparna röra sig över tavlan, från en kort prioriterad lista, genom de olika stegen i arbetsprocessen, på väg mot leveransklara resultat.

    En whiteboard och post-its kanske verkar vara primitiva vertyg? Det stämmer, och det är helt avsiktligt. De är nämligen också mycket kraftfulla.

    Genom att använda dessa enkla verktyg gör vi det lätt att anpassa vår process när vi märker att det behövs – det kostar bara lite suddande, omritande och lappflyttande. Med andra ord hindras inte våra förbättringsambitioner av att verktyget inte hänger med i svängarna (något som i min erfarenhet händer oftare än vad som är önskvärt). Med andra ord: Ingen hittar den optimala arbetsprocessen på första försöket. Verktygen finns till för att stötta processen. Därför måste det vara lätt att justera verktygen.

    När synligheten är stor är det också lättare för var och en att veta var man kan hjälpa till. Gruppen får tydliga signaler när den behöver samarbeta för att lösa problem. Hur klyschigt det än kan låta så är ett team mer än summan av sina medlemmar. En grupp som lär sig samarbeta effektivt, till exempel med hjälp av en kanban-tavla, har tagit ett steg på vägen mot att bli ett effektivt team. Ett team låter inte sina medlemmar kämpa ensamma, det kliver in och hjälper individen att komma vidare och växa. Alla verktyg som kan hjälpa oss att komma närmare det idealet är värda en andra titt.

    Använder du visuell styrning med enkla verktyg? Vad är dina bästa tips?

  • Kom på kurs: Certifierad Scrum Master, augusti 2009

    Gör som flera hundra andra redan gjort: kom på CSM-kurs med mig i Stockholm. Det här är kursen för dig som verkligen vill _förstå_ Scrum. Själva Scrumsnurran är ju inte så svår att rita upp, men varför ser modellen ut som den gör, och var sitter hävstängerna som verkligen får Scrum att funka? Kursen för dig som gillar att fatta med andra ord.

    Jag använder inga PowerPoint-slides på min kurs. Pedagogiken bygger på en varvning av kortare föreläsningsmoment och interaktiva (och roliga!) övningar kring olika aspekter av att jobba lättrörligt med Scrum. Hängiga ögonlock är extremt sällsynt. Om du blir trött är det för att vi jobbar hårt tillsammans, inte för att du sövs av en surrande projektor och min svada. Nej tack säger vi till sånt tråk.

    När vi frågar deltagarna hur sannolikt det är att de skulle rekommendera kursen för en vän eller kollega svarar nästan samtliga 7, 8 eller 9, på en skala från 1-9, där 9 betyder mest sannolikt. Snittet från den senaste kursen jag höll (i Malmö för två veckor sedan) var 8.0.

    Hoppas vi ses där!

    http://www.citerus.se/csmaug09