OOP Conference is the longest running conferences I’ve ever presented at. This year was it’s 21st year of running, and although coming from Object-Oriented programming roots, the contents of OOPConference have evolved with the times to represent so much more – just like JAOO has over the years.

This is the second conference I’ve presented at where the talks were in a mix of languages – obviously German, since the conference is based in Munich, and the other language being English. As a result, the number of sessions I attended was much lower than I normally would and I was able to catch up with a number of other speakers such as Johanna Rothman, Michael Nygard (author of Release it!), Kevlin Henney (97 Things curator) as well as meeting many new speakers.

I was also surprised at how many German speakers I’d met previously and got to practice a little bit of German. I did try sitting in on one session with a former colleague, Gregor Hohpe where he talked about (auf Deutsch) the Near-Field Communication technology the Japanese have. He talks pretty fast in English, let alone in German. I thought I was doing pretty well understanding the gist, but at probably half an hour into the talk, I think my brain seemed to explode and couldn’t take any more. A good way to test your limits Fortunately he also used lots of photos in the slides so I could follow along.

I attended a number of other talks in English, one on the latest going on in the NoSQL space (reminding me of a news commentary on what was going on) as well as one of the keynotes by David Parnas. I’ll admit that none of the keynotes blew me away. They all had good solid points they wanted to get across but the message not really new to me. I appreciated listening to Parnas’ talk because of his significant impact to the way OO-Programming is done, although his focus on documenting and enforcing contracts meticulously (whilst having its place) isn’t necessarily as relevant in the internet applications of today (but highly relevant in embedded systems that last for 25 years!).

Something I learned from his keynote was a new tool for better thinking about object oriented design, providing a table to help people classify what sort of information they want to hide and some recommendations to do so. Although probably not a very new tool, I think it has been forgotten through the passage of time and I know plenty of developers who could learn more about real encapsulation who’d benefit from it.

I had two sessions presented at OOP Conference. The first, “Learning to see, A Systems Thinking Primer” gave people a focused introduction to systems thinking concepts, the ideas of archetypes and applying it to situations in software. I’m really glad that a German audience proved much more interactive than I’d hope and I think it proved some interesting insights into topics such as Mental Models and such.

The other sesison was working with my Hamburg-based colleague, Ken Fassone on a “Night School” lecture/workshop Pair Programming: Good, Bad and Ugly (which I have to give credit to another colleague, Rachel Laycock for). I’m not sure some some people anticipated a workshop, but I’m pleased at how some people enjoyed it. We swapped exercises after a mishap with some supplies and shipment, but afterwards, realised how difficult it was for some attendees to do some sentence writing, with a new group, in a language that is not their mother tongue. They did way better than I ever could, and from the enthusiastic thanks from some of the participants at the end of the workshop, proved to be an enjoyable exercise as well.

Anyone who knows me will know I enjoy my food. Maybe a bit too much, but that’s besides the point. I’ve seen my fair share of food-related TV shows and love to see the insides of how successful restaurants work. Ramsey’s Kitchen Nightmares showcase great examples of how not to run restaurants and their episodes are just as relevant to software as they are to the food industry. One practice that is common in exemplary restaurants is a daily standup between the entire restaurant staff, usually combining the kitchen staff and front of staff as well. I remember seeing one of these at one of my favourite restaurants in Berlin, Dos Palillos. It was hugely visible because they have an open kitchen on a ground floor with almost floor to ceiling glass windows.

Knowing what they discuss is easy, having insights from these TV shows. Often the group will synchronise on daily specials, on things to be wary of and maybe any special events or offers for the evening. It’s a chance for everyone to bring things up. Without this, you can only imagine some of the problems that ensue.

I was reminded of this yesterday, walking past the newly Michelin-starred restaurant near my place, North Road and seeing their staff having the very same huddle.

Software teams are very similar to restaurants. It’s useless to have a wonderful kitchen staff churning out amazing food if it fails to be delivered hot, or in the appropriate way, just as much as it is having amazing software teams only to fail getting software out to users. Both group’s success relies on a collaborative effort, not just on one person’s skills alone. Maybe you’ll notice this the next time you walk past a well run restaurant.

I just came off my last holiday where I got through reading two books that I wanted to. One of these was the heavy but insightful tome, that I dragged in my suitcase, Continuous Delivery. Before I begin, I should warn you that I work for ThoughtWorks, and that both Jez and Dave (the authors) are and were my colleagues so take this into account with my review.

What I enjoyed

Continuous Delivery is a very practical book that covers a huge range of topics from cover to cover. I feel that they found a good balance between giving just enough advice (and more importantly why) with plenty more references for those who want to find a topic to delve deeply. I felt it really lays down the ground work for many projects (but not all) that need to see the light of day.

I think it’s also great that they not only outlined the practices and tips, but also outlined the principles. It gives the book much more merit and will make sure it stays relevant as tooling and new techniques are invented. On the flip side, they do give enough advice on tooling, and, at least, current up to date advice on how one might achieve things.

I like that the authors expressed their opinons strongly on some of their tooling such as, if you’re going to use a commercial source control system, how it should be used and why, or what the problems with the build process in maven or the limitations of various toolings are.

The book is peppered with war stories. I think I know some of the examples they cite, or at least, heard about it from other people and I think some of them are really strong stories about some of the ways people approach deployment.

What would make it perfect (for me)

I’m not sure if they framed the context of Continuous Delivery enough in terms of the types of applications it’s appropriate for. I know that there’s a current (constant) movement in the startup community of “just putting out there.” I think that is an alternative approach that works for some amount of time (or at least changes some of the testing/feedback process). I think for throw away apps (this one is always hard to judge), it may not be worth investing in the same degree of how much effort you put into the process. I think probably the closest advice but should have been expanded upon was, “be pragmatic about how much you automate.”

One particular headline (out of the very many) grabbed my attention, “Test targets should not fail the build.” After reading that section I think I understood what they meant, but it should have been relabelled, “Failing test targets should not immediately *halt* the build” -> it should still fail the build at the end.

Finally almost all of the chapters, for me, had lots of great advice and in working reaffirmed many of the conversations and thoughts I’ve had over my career. I did find the final chapter about “Risk Management” a bit thin, feeling like it was added at the end and either deserved much more attention or should have been dropped. It felt like it had a different tone, or was written at a different time and couldn’t quite see how it would fit in.

Having said that, these last bits are only minor points in a huge volume of rich information and is essential reading for anyone who cares about their profession.

Putting this into practice

For most of the clients I work on, the clearest and most difficult part of the organisation will be the (im)maturity of the operations side of the organisations. Most are already not set up for success with completely different parallel hierarchies from development and competing goals that go against constant change. I still see this, “last mile” problem being the hardest (at least for me to solve). I am hopeful about the DevOps movement and hope that the IT parts of an organisation can only take it much more seriously. I’m hoping this book shows how more companies can achieve this.

In my last post, I wrote about ensuring international codes work when streaming content using winstone. I found that that didn’t work so well with JSON. Not only did you need to specify the character encoding, but you needed to make sure the content type was correct.

In this case, make sure the contentType is set to application/json; charset=UTF-8

I’m writing a little web application to help me learn some German (yeah, a bit of yak-shaving) and I wanted to deploy it locally using an executable jar. I wrote about how to do this previously using winstone and that worked pretty well. Unlike dealing with a normal English character set, dealing with letters like ß, Ä, Ü and Ö are pretty important.

It looks like, by default, serving static HTML from winstone doesn’t seem to work unless you explicitly specify the character encoding as UTF-8. A simple web-filter applied to all URLs helps us here. Here’s an example in scala:

import javax.servlet._

class ForceUtf8EncodingFilter extends Filter {
  def doFilter(request:ServletRequest, response : ServletResponse, chain: FilterChain) {
    response.setCharacterEncoding("UTF-8")
    chain.doFilter(request, response)
  }

  def init(config: FilterConfig) { }

  def destroy() { }
}

Keynote 1: Alexis Ohanian

The first keynote titled, “Only your mom wants to use your website” came from Alexis Ohanian, a geek who helped create Reddit, Hipmunk and a few other sites. He’s passionate about users and you can really see how that manifests itself and very appropriate for a conference with a theme of Userverse. He told the audience, “As geeks, we’re at an advantage. There are so many bad websites out there so if you focus on creating an awesome experience, it’s very easy to compete.” It just came back to treating your customers and really delighting your customers.

He uses some really great examples about how he engaged users with a couple of his websites. For example, with Reddit, there’s the mascot in the top hand corner of the page and talks about doing a 30-day animation series that really connected with dedicated reddit users who were so concerned when, during one the days, the mascot went missing and they emailed in constantly to find out where he went.

With hipmunk, he recounts the story of personally stuffing envelopes with handmand hipmunk travel stuff to send off to some of his users. For no good reason other than to surprise them. In return, people sent photos of the hipmunk in all sorts of places and travelling around. It’s the little things that really delight.

Keynote 2: Neal Ford

Neal’s a really awesome speaker and would highly recommend any technical person to watch his very strong presentations. Fortunately it looks like JFokus just published the same speech Neal gave at Øredev so you can see. The focus of his topic was really about Abstraction Distractions and is a really important key message for us technical folks. It also really relates well to this XKCD comic.

The whole premise about his talk is that users don’t really want to hear the techncial reasons why something does or doesn’t work. You have to make them undersatnd the impact of what it has. He seeds the presentations with lots of pro-tips including things like, “Don’t confuse the abstraction with the real thing” giving the example of wanting to store a recipe and concerned about how to store a recipe that will last many technologies, that even its representation isn’t quite the same thing as the recipe itself.

The ImageThink graphic facilitators had trouble keeping up with the pace that Neal speaks at. He’s definitely the sort of high energy, many idea kind of guys.

Keynote 3: Dan North

Dan is a great an entertaining speaker than everyone really enjoys. He spoke on “Embracing Uncertainty – the Hardest Pattern of All.” I guess a lot of his entertaining anecdotes and stories were really focused around our human bias for closure.

Keynote 4: Jeff Atwood

I’m glad to hear Jeff present this keynote, “Social Software for the Anti-Social Part II: Electric Boogaloo” as he handed over one of his speaking slots to an employee of his in a talk on a previous day that turned out to be a bit of a disappointment for many people. His keynote carried on from a previous talk, carrying on with lots of lessons learned, particularly about how they built Stackoverflow with game mechanics in mind.

It’ll probably be online soon, but it’s one definitely worth watching as it’s an interesting balance between democracy, openness yet some directing behaviour thrown in.

About the conference

I’m constantly impressed by the organisation and the the quality of the conference. I’m really surprised it doesn’t attract more people from Europe and what I call, a little bit of a hidden gem. It has some really wonderful speakers, great topics and the venue itself is pretty good (although there’s poor noise isolation between the different rooms). There’s plenty of interesting events in the evenings and a great place to chat to people both during and after the conference, although I think the “unofficial” Øredev pub needs to grow a bit to accomodate so many geeks.

Other talks of significance

I went to quite a number of talks but will write up some of the more interesting ones (for me).

• Copenhagen Suborbitals – This was a bit of a surprise talk. It was very late in the day, ending almost at about 9pm or 10pm and was a guy based in Copenhagen who’s attempting to build his own spaceship to launch him into suborbital. It’s a really amazing tale and one I can appreciate for a guy who’s serious about following his passion. The talk started off quite entertainingly about how building a spaceship was a bit ambitious, so he started off by building a submarine! He’s a really engaging speaker and I don’t want to ruin too many of his good stories. I suggest going over to his blog (he’s still building his spaceship) and seeing where he is. He relies on donations to keep this project running and I love the fact it’s such an open-source project as well with people offering their advice and expertise in many different areas. He’s got lots of great lessons to share that are completely relevant to everyone.
• Aaron Parecki on his startup story for Geoloqi – I listened to this guy talk about his startup, and similarly along the same lines at the Orbitals, he told the tale of what started off as a hobby eventually turned into a real startup opportunity and shared a lot of his lessons along the way. It’s an interesting start up that you can read more about on gizmodo here
• Jeff Patton – Jeff had a great session introducing people to the UX stage and trying to set the stage for lots of the other speakers. Jeff has a wealth of wisdom and experience to share and what was really powerful was him sharing images and stories about the different roles and techniques people use to build useful software and integrating it into agile processes. Really powerful stuff that I think every developer should really go through.

Reflections on my talk
Titled, “Collaboration by better understanding yourself”, I presented on the idea that we have lots of in built reactions as developers that really hold us back from collaborating more effectively. My goal was for people to go away, thinking more about the things that effect them and why they don’t collaborate as much as they should. I got some great feedback and was particularly nervous because not only did I have a good number of people but I had many other presenters I really respected in attendance including Portia Tung, Doc List, Johanna Rothman, Jean Tabaka, Jim Benson and more.

Although I’d practiced, there’s a few more tweaks I would make to this, but was very happy with some of the people who came up to me throughout the conference who felt that they really connected to the topic and felt really enthused to do something about it. Exactly what I wanted.

“An expert is [someone] who has made all the mistakes which can be made, in a narrow field” – Niels Bohr

This is a useful site for finding flags for countries that I used for my last presentation

We recently wanted to do some transformation on our small XML document in order to present some information on it. In this example, our example looks like this:

<basket>
  <item cost=".99" discountCode="A5">Last year's red Christmas baubles</item>
  <item cost=".10" discountCode="A5">Halloween lamps</item>
  <item cost="101.99" >Pine Tree</item>
  <item cost="20" discountCode="B2">Gold star</item>
</basket>

It’s a pretty simple structure with some simple rules. A basket can contain one or more items. Each item has:

• A simple description
• A cost in dollars
• An optional discount code

The task we had was to display a list of human-readable discounts that had been applied to this particular basket. In the example given about the discount codes are A5 and B2.

We have a very simple list of known discounts, and can implement a simple conversion function:

object Discounts {
  def displayString(code : String): String = {
    code match  {
      case "A5" => "Reduced to clear"
      case "B2" => "Pre-Christmas offer"
    }
  }
}

We already had a class that wrapped this small XML document, creating a cached field for the item nodes.

class Basket(val rootNode: Node) {
  private lazy val items = (rootNode \ "item");
}

We can then apply a series of functions to convert the items:

class Basket(val rootNode: Node) {
  private lazy val items = (rootNode \ "item");

  lazy val discountsApplied =
    items.map(item => item.attribute("discountCode")
         .map(attribute => displayString(attribute.text)))
         .flatten
}

The above code pulls out all the “discountCode” attributes, and applies a conversion function to convert them to human-readable form. Since item.attribute returns an Option, we use flatten to get rid of elements that are essentially null.

Unfortunately, while there is a toSet method, and a list, there isn’t a great way to do both inbuilt. However, by constructing a TreeSet (a sorted set), we can append all the results and get the same effect. We end up with the following:

class Basket(val rootNode: Node) {
  private lazy val items = (rootNode \ "item");

  lazy val discountsApplied = sortedUniqueSet(
    items.map(item => item.attribute("discountCode")
         .map(attribute => displayString(attribute.text)))
         .flatten)

  private def sortedUniqueSet(sequence: Seq[String]) = {
    TreeSet.empty[String] ++ sequence
  }
}

I first used cURL on a project a few years ago whilst testing a RESTful applciation. It’s a really great tool and plenty of options to do things. I however, keep forgetting some of the simple commands you might use to interact with a RESTful, or even just a web application. This is really good if you want to test AJAX resources as well.

I’m putting the examples I’ve used the most up here for easy reference. You might even find it handy as well.

Perform a HTTP GET instead of POST

curl -G -F "formParamName=@fileToSendOnDisk.txt" http://localhost/someGetUri

Sending the contents of a file from disk as part of FORM data

curl -F "formParamName=@fileToSendOnDisk.txt" http://localhost/someUri

Note that the @ is very important here. You can use curl to give it content type as well.

curl -F "formParamName=@fileToSendOnDisk.json;type=text/json" http://localhost/someUri

Sending form post data as a single string

curl -d "param1=value1&param2=value2" http://localhost/someUri

Send some form post data and print the HTTP response code as the last row to the console

url -d "param1=value1&param2=value2" http://localhost/someUri -w "%{http_code}\n"

Post data to a HTTPs endpoint ignoring self-signed certificates

curl -d "param1=value1&param2=value2" https://localhost/someUri -k

Follow redirects, printing out response code and URL that was last fetched after posting data

curl -d "param1=value1&param2=value2" http://localhost/someUri -k -w "%{http_code}\n%{url_effective}\n" -L

Hope you find this useful although you can find a much larger manual in the man page, or on this site here.

On my current project, we’re using the logback framework (behind SL4J) to do logging. For some parts of our system, it was particularly important some information made their way into the log files, and so we wanted to not test the correct output. Rather than do it with interaction based tests, I followed the pattern that I described in a previous post.

Here’s a test I might write (note that I’m writing the test in a way to actually test the appender behaviour in this case because my domain class doesn’t nothing special):

package com.thekua.spikes;

import org.junit.After;
import org.junit.Test;
import static org.hamcrest.Matchers.is;
import static org.junit.Assert.assertThat;

public class LogbackCapturingAppenderTest {
    @After
    public void cleanUp() {
        LogbackCapturingAppender.Factory.cleanUp();
    }

    @Test
    public void shouldCaptureAGivenLog() throws Exception {
        // Given
        LogbackCapturingAppender capturing = LogbackCapturingAppender.Factory.weaveInto(OurDomainWithLogger.LOG);
        OurDomainWithLogger domainClass = new OurDomainWithLogger();

        // when
        domainClass.logThis("This should be logged");

        // then
        assertThat(capturing.getCapturedLogMessage(), is("This should be logged"));
    }

    @Test
    public void shouldNotCaptureAGiveLogAfterCleanUp() throws Exception {
        // Given
        LogbackCapturingAppender capturing = LogbackCapturingAppender.Factory.weaveInto(OurDomainWithLogger.LOG);
        OurDomainWithLogger domainClass = new OurDomainWithLogger();
        domainClass.logThis("This should be logged at info");
        LogbackCapturingAppender.Factory.cleanUp();

        // when
        domainClass.logThis("This should not be logged");

        // then
        assertThat(capturing.getCapturedLogMessage(), is("This should be logged at info"));
    }
}

And the corresponding Logback appender used in tests.

package com.thekua.spikes;

import ch.qos.logback.classic.Level;
import ch.qos.logback.classic.Logger;
import ch.qos.logback.classic.spi.ILoggingEvent;
import ch.qos.logback.core.Appender;
import ch.qos.logback.core.AppenderBase;

import java.util.ArrayList;
import java.util.List;

public class LogbackCapturingAppender extends AppenderBase<ILoggingEvent> {
    public static class Factory {
        private static List<LogbackCapturingAppender> ALL = new ArrayList<LogbackCapturingAppender>();

        public static LogbackCapturingAppender weaveInto(org.slf4j.Logger sl4jLogger) {
            LogbackCapturingAppender appender = new LogbackCapturingAppender(sl4jLogger);
            ALL.add(appender);
            return appender;
        }

        public static void cleanUp() {
            for (LogbackCapturingAppender appender : ALL) {
                appender.cleanUp();
            }
        }
    }

    private final Logger logger;
    private ILoggingEvent captured;

    public LogbackCapturingAppender(org.slf4j.Logger sl4jLogger) {
        this.logger = (Logger) sl4jLogger;
        connect(logger);
        detachDefaultConsoleAppender();
    }

    private void detachDefaultConsoleAppender() {
        Logger rootLogger = getRootLogger();
        Appender<ILoggingEvent> consoleAppender = rootLogger.getAppender("console");
        rootLogger.detachAppender(consoleAppender);
    }

    private Logger getRootLogger() {
        return logger.getLoggerContext().getLogger("ROOT");
    }

    private void connect(Logger logger) {
        logger.setLevel(Level.ALL);
        logger.addAppender(this);
        this.start();
    }

    public String getCapturedLogMessage() {
        return captured.getMessage();
    }

    @Override
    protected void append(ILoggingEvent iLoggingEvent) {
        captured = iLoggingEvent;
    }

    private void cleanUp() {
        logger.detachAppender(this);

    }
}

I thought it’d be useful to share this and I’ve created a github project to host the code.

I’ve seen a number of different patterns for testing logging and we just ran into this again at work, so I thought it’d be worth writing up a couple of them.

Simple logging
Many of the java based logging frameworks allow you to log and then choose to separate what you log from what needs to be done by attaching appenders to them. The common pattern here is to declare a static log instance inside each class, typically using the fully qualified class name. Most logging frameworks then treat this as a hierarchy of loggers that allow you to configure what type of logging at different levels.

I find the best strategy for testing this style of logging is to add an in memory appender that will capture the output that is sent to the logging framework. I will post an example with given frameworks in a second, but here are a few different concerns you need to think about:

• Getting a reference to the log – Most loggers are made private static. You can choose to break encapsulation slightly by weakening the access to package local just so that a test can get access to the log. I find that injecting it in as a dependency in the constructor appears to complicated, and dislike setter based dependency injection in an attempt to keep fields more immutable.
• Creating an appender to capture the output – This is where you’ll have to go to whichever logging framework and find out how appenders work. Most have a console appender, or something that you can simply extend and capture a logging event
• Make the appender capture the output – This is pretty easy. You must make a choice whether or not you want only your appender to capture the log events, or if you want it to go to other appenders as well.
• Clean up – The consequence of adding an appender with state is not a problem in a single test. When wired up across a long test suite, you potentially increase the amount of memory being consumed to the point where you’ll get out of memory errors. I find that it’s important to make sure that your appenders remove themselves from the logger at the end of the test to avoid side effects and to make sure they get garbage collected by the JVM. In a following post, you’ll see the pattern I tend to use.

More complex logging services
If you’re application requires more than just file based logging, and other actions need to be performed, you may still consider injecting a type of logger into the class that uses it. At this point, testing it becomes like any other interaction-based test and you can probably use mocking or stubbing to test the correct things are passed to to it.

By default, I wouldn’t really go through the motions of setting up a logging service unless there was some real need for it. The standard style of loggers and configuration of behaviour gives you quite a lot already.

I needed to convert some code into an image for a presentation recently and found a number of different ways of doing so. The easiest, of course, is when you take a screen capture of the code in your IDE. This fails when your code goes well past the side of your screen and you still want to show it all.

Alternatively, you can do this in a two step process.

• Save the code to HTML – I know that both IntelliJ and NetBeans allow you to do this for Java code.
• Use webkit to save to an image – I used PhantomJS for doing this. Take a look at the example code of how to do this.

Leave a comment if you’ve had any other good experiences doing this. I’d be interested in other ways that have worked for you.

Just stumbled across this really interesting site for generating unique images for text. Below is the unique robot for this post.

In java, if you’re formatting a small XML document, it might be tempting to simply do a String.format to substitute it directly into a string. Transitioning into scala, this is then easy to convert into one of their XML representations with XML.loadString. You might very well end up with code that looks like this:

val myValue = "will be substituted"
val xml = XML.loadString(String.format("<node>%s</node>", node))

You can actually just do this inline with scala directly, and end up with this instead

val myValue = "will be substituted"
val xml = <node>{myValue}</node>

Neat-o!

Short Description: A facilitation technique (e.g. for retrospectives) or also for planning that helps the quieter people to also come up with ideas.

Original source: Facilitation training by Grape People.

Example Use:
Questions are prepared by facilitators. Three different rounds

1. Me – Everyone writes down answers for him/herself using sticky notes
2. We – Discussing with your neighbour and answers refined
3. Us – Combine all issues into one big chart

Contributed from the participants of my XP2011 workshop

See Doc List’s original post.

Comments:
Gets everyone involved. People understand better by explaining. It’s really about learning by teaching. Generative thinking. Works well if you go around twice. Widely applicable. Can be used for almost anything. Makes a non-talkative group more talkative.

Tips:
Enforce the circle. One person at a time and use a talking stick/token. Egg timers work well for Italian and Spanish groups. The more challenge the team has to stay on time, the more rituals need to be introduced/enforced.

Contributed from the participants of my XP2011 workshop

Short Description: A way to create a metaphor that reminds the team of the holistic view of the team

Original Source: Looks like it’s here.

Example Use:
Labelling the expected fruits, very useful when a team has the fundamentals but could be better. Used as a roadmap to move towards higher performances. Shows that many practices are rooted in values.

Notes/comments:
Doesn’t always work. Some people don’t connect to the metaphor. In that case, the technique should be dropped. Can be used in open spaces to show the value streams, etc.

Potential Variants:
Garden or orchard -> organic seems to work better than mechanic. Allows you to talk about the weeds

Contributed from the participants of my XP2011 workshop

Short Description: What I’m doing in the next seven hours, next seven days, seven weeks put onto a board

Example use
Introduction of yourself as a coach, and used to articulate what the coach does in flip chart using visual information. Set up a board with three columns with the title “7 Hours”, “7 Days”, “7 Weeks” and add activities to demonstrate what you’re doing.

Contributed from the participants of my XP2011 workshop

GROW stands for Goals, Reality, Options, Will/Way Forward. This is quite a well known coaching tool that even has it’s own wiki page.

Contributed from the participants of my XP2011 workshop.