Tobias Fors

Category: English

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

  • Writing: It’s Not Just About Writing

    I try to write regularly. I write a lot more than I publish, and that’s OK for now. I’d like to publish more in the future however, so I keep trying to improve my productivity. One thing I’ve found that helps, is to do something that moves a writing project forward, even if it’s not really writing per se.

    What I do is I work on structuring things I’ve previously written. I’ll typically look through my project in my writing tool of choice, and look for areas that need some cleaning up. Then I’ll go ahead and move stuff around, clean out stuff that no longer feels relevant, or even do a little bit of editing.

    Every now and then, this not-quite-writing activity triggers something inside of me, and I get an idea. Once that precious idea pops up, I can easily write for some time. Conclusion: not all about writing is writing, but in the end, writing is what it’s all about.

  • Too Much Talk About Methods

    I believe there’s too much talk about methods, and too little about how they are introduced. Methods can be very helpful, especially when used mindfully. What does that mean? To me, using a method mindfully implies, among other things, introducing it in the right way. The right way for me is with minimal hype and maximum participation of all involved. We believe in what we co-create and co-discover.

    Have you been force-fed a way of working? What was that like for you?

  • Sketchnoting a Russell Ackoff talk

    Listening to Russell Ackoff speaking, I “sketchnoted” this in Brushes on my iPad. I’m a very visual thinker, so this is a way for me to make things stick a little better in my brain, plus it’s very fun and relaxing to do.

    I don’t worry to much about my handwriting and general drawing skills. I just draw. It will be interesting for me to see how my drawings change over time, because my guess is I’ll be doing a lot of this, just for the fun of it.

    If you’re interested in the topic of systems thinking, go ahead a watch Ackoff’s talk. I’m afraid my sketchnotes may not be very intelligible for anyone else but me, but I highly recommend the method as a way of taking notes and processing new information.

    Big thanks to Esther Derby for telling me about sketchnoting!

  • New Russell Ackoff Videos

    Here’s a set of Rusell Ackoff videos I just discovered. I might go ahead and collect all my Ackoff resources on one page some day, but for now I’ll just serve these new ones up like this. Enjoy.







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

  • Ackoff’s 95% (Cannot manage them the same way)

    I’m currently cleaning up my trusty old Mac Mini G4. I’ve been cleaning out old stuff I don’t need to save, and a few days ago I installed a cheap 1 gig of memory. That upgrade did not make the machine notably faster. Today, however, I ran a bunch of maintenance tools, which seemed to do the trick. There’s a noticeable improvement in the speed of the little things, like how long it takes to fold out a menu. There was a delay before, and now it seems to be gone. Hope it lasts.

    Energized by my success in speeding up the old can, I started another round of file cleaning. I found an old NeoOffice file called “Russ Ackoff – 95 Percent”. Because NeoOffice has always been extremely slow on this old machine, I wanted to see how fast I could open it. That, and the fact that I’m always interested in Ackoff’s teachings.

    NeoOffice turned out to be as slow as before, but the file contained pure gold. Not new gold, but pure gold. In it was a little piece of knowledge that I’ve been using in my scrum master classes for a few years, ever since I came across it on the web.

    Here are the contents of the file, which I remember transcribing from a sound file as I listened to it:

    “http://www.open2.net/systems/practice/rus12.html

    1900 – 95% of the people in the US could not do the job as well as their bosses could.

    If the foreman retires from a group, you pick the best man to become the new foreman.

    He can thus do the job better than any of his subordinates.

    He will continue to rise as long as he is the best in the group.

    All managers thus rise to the level of their own incompetence.

    Today, 95% of the people can do their job better than their bosses.

    You cannot manage them the same way.

    Don’t manage what they do – manage the way they interact.

    Requires different organization, and a different type of management.”