Category: Feedback

Feedback for Conference Presenters

After presenting at the recent Quarterly Technology Briefing in London, Manchester and Hamburg I had a very good question from one of my colleagues about what feedback I found most valuable.

Our feedback forms were quite short with two quantitative questions (out of a 1-5 scale), and three or four free text questions. Although the quantitative questions gave me a good indication of general feedback from the audience, it is not specific enough for me to really understand what things to do more of, or things to do less of. It reminds me of a traffic light system some conferences used (red, yellow, green) for evaluating conference presenters. Fun, quick, but entirely useless to know why people put numbers down.

Although the free text answers to feedback forms take more time to read, the feedback is much more helpful, particularly around getting an understanding of where expectations for a session matched or didn’t match, and useful suggestions or ideas to focus more on. I can take this feedback and actually do something about it for a different presentation.

For conference organisers, or if you’re putting feedback forms together for your own workshop, please don’t leave feedback as a binary, or based solely on numbers. Although there are advantages to getting quicker to an evaluation, you don’t really know why people rated something well or not well. Ask open ended questions and provide these to speakers unedited and raw.

I think if conferences really wanted speakers to get better as well, I think having some peer presenters sit in a session and provide targeted feedback would be even better. I could imagine something like this could focus solely on the mechanics and/or execution of the presentation and give timely, helpful feedback to improve the session and the presenter.

Simplicity of Leaving Things Out

Last year, I worked on an in-house application replacing a 3rd party product our client picked. The 3rd party product had numerous problems such as reports that threw “SQL column not found” errors at end users and a clunky interface that required so many clicks to accomplish a single task. More importantly the vendor could not meet new hosting requirements demanded by new geographic legislation. We involved a User Experience designer very early on in the rebuild, focusing on who used the system and what they needed it to do.

In the end, we ended up with a very simple application. We did nothing special from a technical point of view but we fought hard to keep unnecessary features out until we validated how it would be used by end users. I’m glad we did it as well.

Our Product Owner took the Net Promoter Score (NPS) for the original tool. This score is something that apparently Apple rely on heavily for user feedback. The 3rd party tool scored a disappointing -27%. Our Product Owner took the score again a couple of weeks after the release of the new tool. This new tool got an amazing +63% (a 90 point change!).

Our endeavour to keep the application as simple as possible paid off. Users had a much easier time accomplishing what they needed to do instead of clicking all over the place.

8 years at ThoughtWorks

Friday marked eight years since working at ThoughtWorks and thought it’d be a useful exercise to reflect on it. During that time, I’ve seen the company grow and the number of opportunities grow with it as well. I was at the pub last night (one of those ThoughtWorks UK traditions) and was trying to explain my role to someone. On my business card, it’s the title of Generalising Specialist. I’m a developer most of the time and although as a Technical Leader you don’t develop 100% of the time (who does?) I still get to do a huge amount.

Reflecting on the past
I’ve had plenty of opportunities to do a lot of public speaking and was proud to be invited to speak at Øredev, QCon and this year to Goto Aarhus (formerly JAOO). I see it as a great way to share knowledge and contribute back to the development community and to continue to spread great ideas. As I always tell people there is a lot of value in being a meme-carrier and helping introduce memes into newer communities.

At the same time, I’ve worked as a trainer, facilitator and an advisor doing some short term pure consulting engagements working with CTOs and CIOs on how they run their software organisation, how they’ve architected their software systems and helping them build a roadmap to a better pace. My passion for Systems Thinking, Lean thinking and the belief of constantly being open to new approaches and ideas helps me see and explain things that others often get stuck on.

Work wise, I’ve now worked in many places. Last year I spent a significant portion of that time in Germany, Berlin to be exact. It’s not the best place to learn German, but my passion for learning drove me to self-learn enough that I can hold a conversation in a bar reasonably well. I’ve got plenty more to go before I can start writing any blog entries or immerse myself in a completely German speaking work environment but pretty happy with the progress so far. Overall I’ve worked in Australia, Canada, Denmark, Germany and the United Kingdom for my clients with travel for conferences to many more.

I continue to appreciate the different opportunities and the continuous mix of people that I get to work with. As an example, we have a project of about 15 people all representing about 12 different nationalities. We have four females on our project (2 of which are developers) and so many interesting approaches and conversations with a consistent focus on trying to do the right thing for the client. I have to always remind myself other companies or contractors do not stand for the same values and I constantly appreciate.

Thinking about the future
Although I’ve been published in a book before, my goal is to finish a book, The Retrospective Handbook some time this year. Leave a comment to let me know what you think or tell me about your interest.

I will continue to write code, although this year I plan to specifically deepen my javascript and ruby skills. I will continue applying systems thinking but deepen its application into the software realm and how it can be made more appropriate.

I plan on cutting back on the number of speaking engagements. Last year it was almost one or more every month and the variety proved rather stressful at times when trying to balance life and work.

Writing feedback as a conversation with the recipient

We had a couple of people roll off our project recently. Even though we had been doing regularly feedback as a group, each person still wanted some written feedback to take with them to their next project. In writing down the feedback (and trying to collate all my thoughts from previous sessions) I found it was immensely useful to write the feedback as if I was talking to the person.

In past occasions, for some reason, I wrote a lot of feedback as if someone else was going to read it. For example, “I worked with <Joe> and noticed… It had this impact…”

Rather than as if I was writing feedback for someone else, I tried to write the feedback as if I was talking to the person. Framed in the context of the person who will benefit from receiving the feedback, I think it really changed the way that it made me think about it. It really focused my attention on feedback that would really help the person grow – reinforcing those behaviours that they should continue doing, and bringing to attention those behaviours that continued to puzzle me, or bringing to attention those behaviours that might take much more time than a single project to develop.

I found that writing feedback as if I was talking to the person also helped me humanise and personalise a lot more of the feedback I wrote down. Why don’t you give it a go next time?

Long Feedback Loops

Almost five and a half years ago, one my first project in the UK, I built a constrained email tempting engine to be used by marketing folk with a small team of three other developers. I think we worked for about six to eight weeks to develop the entire application, including retrofitting its integrate its output with another system.

A year or two ago, we had some consultants return to the client who talked to one of the original developers who still worked for the same client. They spoke fondly of the good times he had on our team, and spoke proudly about the application we wrote. In the four years or so of constant use (they would revisit their emails at least once a month), the users apparently only ever reported one bug. He mentioned that bug (a special character in the email subject line) was also deprioritised from the original work we did. It was an enough fix and with test around it, was not a problem updating the system.

I certainly appreciated the feedback, particularly since you don’t always get to return to see the long term results of the work you do as a consultant, or even just as a developer.

Some of the great things I learned from that project.

Acceptance Test Driven Development is entirely possible
We worked hard to test drive this Swing based application from the start. It really changed the way that we designed the application and all of us learned a whole heap about understanding testable presentation patterns. It formed the basis of several talks and the knowledge, particularly the separation of concerns is entirely applicable to all sorts of other tools and interfaces such as javascript, or command line interfaces.

On a different note, coverage combining end to end acceptance test and unit tests meant we had 100% code coverage. It was never the goal, but interesting to see on this application it was entirely possible.

Never discourage people from trying new things
The organisation was rife with contractors. Not all of them entirely passionate. I love building great teams and the fact that everyone was learning, and saw things being delivered reignited people’s passions to do various things. I distinctly remember two events made possible by encouraging people to explore their passions and strengths.

One of the developers, interested in the User Experience side asked if he could do some user testing with the application. I can’t remember exactly what I said, but certainly encouraged him to do that. He did, what some people call Guerilla Usability Testing – grabbing someone who didn’t know anything about our application, and giving them a task list to complete as he watched them over the shoulder. Based on this study, we found out, to no surprise, the way we laid out the application didn’t make some of the tasks as easy as they could have been. We channeled this feedback into our interface and helped make life easier for its users.

The other event, a contractor, seemed to find his passion for developing usable software reignited. Everyone will know that swing applications aren’t the nicest things to look at. I remember coming in one morning to find that whole interface reskinned and redeveloped. It looked a whole load better than what you’d get with swing out of the box.

I found out much later that he had, by his own volition, worked a couple of extra hours one night because he wanted to add that extra polish and make the interface attractive to users. Awesome stuff that would never have happened without encouragement to do “the right thing”.

Involving real users
As a systems thinker, I know that the purpose of the project should have been an intermediate step. The real problem the organisation was a missing feedback loop from IT back into marketing. I knew that then, and I know that know, however being pragmatic and realistic, you can only do good things within your own sphere of influence. Trying to change how the entire marketing and IT department silos worked (or failed to work together) would take much more than the two or three months I was going to be there.

Fortunately, we had one person on our project who had worked for their company for a while and had a couple of good contacts in marketing. Whilst we couldn’t change the way projects spun up, we managed to get someone who was going to use our software down, early, and show them what we were building for them. More than that, they asked for somethings (that we could almost immediately turn around for them) and they were blown away that their feedback actually mattered and made a difference.

Conclusion
I appreciate good projects, and where possible, create those environments for others to thrive in. There are many good things to carry forward in these things and can only hope others benefit from it as well.

It’s never been about what you do

I find it fascinating talking to people about their agile implementation. Some people immediately claim they’re agile by describing the practices they use. I often ask a few more questions such as, “How is that working for you?” and they start to describe a number of problems they have. Another answer people often give is, “We’ve been doing agile for ages!”

“Doing agile” has never been the point. The agile mindset is about working with customers or stakeholders to deliver solutions whilst always continually improving. The practices are simply ways of getting there. It’s never been about what you do. What matters is how you do it.

Improving how you do something is easy yet requires constant discipline. First, you need to be continually asking yourself, “How does this practice help us?” and searching for answers to another, “How can we get better at this?” Talking to people outside your organisations often help, as does following what other people do around the world (made easy through social channels like twitter and blogs).

Thoughts On Øredev

Last week Sweden’s Malmö hosted Øredev for the sixth time. I believe it attracted more than 1400 people, all with varying backgrounds and interests. Unsurprisingly, the majority of attendees turned out to be Swedish and Danish people (with Malmö very well connected to Denmark via their famous Baltic Ocean crossing train).

The Cultural Experiences
Being held in Sweden, the organising committee did well to treat us to some cultural delights including the Swedish sauna-Baltic Ocean run followed up by a delicious traditional fish meal). One of the organising members even welcomed us into their home for drinks before the speakers’ dinner where Glögg continued to keep the cold at bay. The difference of soaking raisins and almonds really surprised me. Malmö’s deputy mayor then welcomed us at their majestic townhall where all the speakers unanimously marvelled at the decadent surroundings. The meal stayed true to the region with first, a regional speciality, black soup (and yes, like black pudding, it has a very special ingredient) before following that up with a hearty roast goose meal and a spiced apple pudding for dessert.

Logistics and Organisation
The organisers impressed me with how smoothly the entire conference ran. Malmö’s Slagthuset (slaughterhouse) hosted the conference for the first time and although not all the spaces turned out ideal (with small walkways between some major rooms), I think it contributed to the friendliness and openness I discovered.

The organisers also did a fabulous job responding to attendee’s needs. For example, on Monday they moved a number of tutorials to warmer rooms after realising the strong draughts let in by workmen who still needed to complete their work. Another example is when they quickly disabled the authentication on the wi-fi when it proved to be another barrier to being connected. Unfortunately the wi-fi turned out to be a little bit flakier throughout the conference.

I also really enjoyed the evening entertainment that flowed into the venue rather than the “move to another location and lose people” approach several other conferences do. This helped to keep the conversation flowing (and we all love our flow!).

Topics
Øredev offered a huge variety of interesting topics with tracks covering mainstream languages such as Java/.Net, NoSQL, Agile & Lean, Collaboration, Patterns, Smart Phones and Architecture with lots of really interesting topics. I’d keep an eye out for their website and trawl the twitterverse (#oredev) for the interesting discussions.

The keynote presenters also turned out really well.

Dr Jeffrey Norris presented what he thought as agile values leading to mission critical success at NASA (Vision, Risk and Commitment) demonstrating through a “wow” 3D demonstration using the ARToolKit. He used the stories of famous inventors, particularly the rise of Graham Alexander Bell to emphasis these elements very effectively.

I saw John Seddon a few months ago and although I’d heard him present pretty much the same talk, appreciated his message was an important one that more people really needed to hear. I think there is great value in spreading his emphasis on holistic system thinking even further in the work that we do. Entertaining and very British, Seddon completed his keynote without leaning on any slides and to a very positive reaction from the audience.

I missed Henrik Kniberg‘s keynote so can’t really comment.

The final keynote came from Atari Corporation geek legend Nolan Bushnell envisaging what the next key software projects would be in the future. I think everyone enjoyed the talk simply because it was Nolan though I think wasn’t as executed as professionally as it could have been.

People to meet
One of the really great parts of Øredev was all the people around you. As one person put it, you could be talking to a person and then suddenly realise that they created X (where X = language, framework, tool, etc) or someone who wrote a lot of the blog entries that you’ve been reading. I think that the conference does a wonderful job of creating a really relaxed atmosphere for people to converse and the speakers are all really approachable and involved in all of the sessions as well.

I have to admit I also really appreciated the opportunities to connect to a number of fellow ThoughtWorks colleagues (both past and present) who I’d either not got a chance to meet, or hadn’t seen for a very long time. This is one of the consequences of working for a global consultancy – you get to communicate and build relationships for a distance yet rarely get to meet people face to face.

iPad observations
One huge point worth noting was the large role that the iPad played during this developer conference. Obviously, being fairly geeky I hadn’t expected so many of them yet it proved to be one of the best devices for capturing notes & particularly useful for reading and contributing tweets. Laptops lose out on both portability and, on average, a very so-so battery life.

Reading tweets to view session using the native iPad twitter client also worked really well without having to use the keyboard or mouse – this is where gestures and multi touch really shined.

My session
Chris Hedgate, organiser for the track on collaboration invited me to speak. Titled, “Tightening the Feedback Loop“, I spoke about how to give and receive more effective interpersonal feedback. I had some great tweets in response and some great feedback on the presentation (meta!) I’m encouraged that more people will be better equipped in their professional and personal life after attending.

Conclusion
I highly recommend presenting and/or attending Oredev. You’ll meet a whole heap of really interesting people and, no doubt, come away with at least an idea or two.