Our current Card Of The Day board at Eden

Retrospectives are something we’ve been doing regularly for quite a while at Eden, but we’ve hit a problem. It’s very easy to come up with a great list of actionable items, and then very easy never to look at them again. Don’t tell me you’ve never done this :)

We’ve started doing something slightly different at Eden to try and stop this happening: we’re using a method we’ve called Card Of The Day.

When the retrospective is finished, we take all of the cards with SMART action goals and put them on our company kanban board to ensure they’re done. Then we take all the cards that are a little more hazy (the sort of cards that say: “Be better at X”), we pin them up on the wall, and every morning after standup we read one out at random to the team.

Normally this has a “ahh, yes” effect on the team. Sometimes it generates a conversation, sometimes an action we hadn’t thought of yet and something else to go on the Backlog. There’s always something that comes out of it.

It’s not a perfect method, but it’s working better than the alternative: feeling guilty at the beginning of the next retrospective about all the terribly important things we haven’t done.

Have you tried something similar? Or do you have an alternative way to remember to do retrospective actions?

Creatives and agile – The smell of fear…

When I first started at Eden; in the designer part of my role, faced with an agile developer asking me to commit to short iterations, my gut instinct was panic. Not because I felt incapable, but because creativity isn’t something you always have, or can turn on, on demand. This was of course not the right reaction, or even justified. It was however, I suspect what most ‘creatives’ feel when faced for the first time with seemingly short iterations.

Reality Check

It’s true, creativity waxes and wanes, but we cope with this all the time.

What are the tricks we use to do this?

• Limiting the fidelity that we work at (In the traditional design world, Marker visuals, Lorem ispum, Photoshop comps, low-res thumbnails of photos)
• Trying our ideas out as quickly as possibly and discarding LOTS of bad ones. You still scribble stuff, right?
• Slowly refining and enhancing ideas and designs (thumbnails, to mockups, to proofs etc.)
• Working with a team to get things done quicker
• Only presenting part of the solution (e.g. We need the Brochure first, lets start there)
• Getting feedback from the client and refining at each stage.
• Building some extra time into the deadline to make sure there is ‘wriggle room’

Hmmm - Maybe it’s not so bad… Breathe.

You are already doing it!

• Limiting fidelity, Agile Story Cards are a lo-fi method of capturing the idea of a piece of functionality.
• Slow refinement - well that’s iterative development
• Working with a team - You are part of the team (and maybe have your own team as well - double win!)
• Only present part of the solution - Work on a small chunk of functionality at a time
• Getting feedback early - Weekly (or even daily or less) releases mean constant feedback.
• Wriggle room - You should be in the planning meeting and state if you can do it in time.

But What’s in it for me?

1. Shorter time-frames add focus. Given longer, I won’t actually get more done, I’ll procrastinate until I have a looming deadline, then find focus.
2. You’ll have happy customers At the end of the day, we all want to deliver things customers are happy with. The problem is that at the beginning of most projects, the customers think they know what that is (and don’t) and you think you undertsnd what they want (and don’t). If you do Agile design right, you can combat this by really establishing what the needs are and then delivering a solution to the real problem.
3. Built in Fail. Sounds odd, I know, but it is liberating to acknowledge that you don’t have a crystal ball, and it’s not reasonable to expect to entirely acurately understand every problem and therfore, it’s impossible to provide a correct solution first time, every time.
4. When you do get to see the whole, you have something real to design If you’ve iterated on your project, and kept the design (skinning) to a minimum, you can at the last responsible moment, start doing PSDs with the benefit of a working prototype which removes the ‘we’ll probably need a twitter widget here’ page filling that creating PSDs often induces.

What techniques can I use.

This is a blog-post (or series) in itself. However, we’ve been trying out Story Mapping, and Sketchboarding, both of which we’ve found pretty helpful.

My main tips are:

1. Pens and paper Scribble your ideas, perfect drawing is not required (anyone can draw a box!) and use it as a tool to facilitate conversation about your ideas.

2. Conversation You need to talk. To your client, to thier stakeholders, to your team, to your developers and ideally along the line, you should talk to users (a lot).

3. Avoid Photoshop early on We’ve found that photoshop gives a false impression of a finished solution. Unless your stakeholders need Photoshop visuals to get buy in, we say avoid them. Try and steer them towards wireframing. If they need them for buy-in (which many do) be very clear that they are an indication of what could be. Nothing more.

Caveat lector

No amount of Agile allows you to not have to think. You still need an overview of the whole project in the back of your mind, when you are working on a small piece.

You’ll have to have an understanding not just of the problem, but of the solution, the technologies, the implications of decisions on the team and budget.

You will have to push back against developers and customers from time to time. That’s OK. Defend the things you genuinely feel are required.

You are part of the team

Agile is all about collaboration. You need to be one of the team. Seriously, the siloing of creative vs. technical is just rubbish. Developers are unlikely to have your skills and vice versa. You will learn and teach a lot (as will they). Share your skills liberally, and everyone will benefit.

I think there is a whole post in how you get ‘on the team’ and as it’s late and this is already a long post, I’ll come back to that another time.

I think i’ll go do a few powertyping exercises, followed by a few rounds of typeracer. In the meantime, enjoy this video that Enrique made: it’s me and Tom playing typeracer yesterday lunchtime!

Type Racers from Enrique Comba Riepenhausen

I scored 102 words per minute, at 100% accuracy!!

Yesterday was very fun. I worked with aimee on a client project, getting Jasmine working so we could test some javascript that we wanted to refactor. To test that we had to break up the code quite a bit, and then mock out things that touch the DOM. This is mostly because we couldn’t work out getting fixtures generated for jasmine, so maybe we’ll work on that today.

On another note, my typing (seeing as I’m participating in #learn2typewk) seems to be getting worse. However, I’m somewhat aware of my problem areas now (pretty much anything not on the home row), so I know what to work on. I’ve also started a Trickle ListODO: Link here) for keeping track of my typing practice.

Corey has encouraged us to set a goal for the end of the week. I will make it my goal to get to 100wpm on the 5-minute test. I feel that this should easily be possible by going at the speed that i am currently doing, but removing all the mistakes. This morning i managed the first minute without a single mistake, but the mistakes started to creep in after that. On my typeracer games i have noticed that a mistake costs a significant amount of time. It’s more effective to go a bit slower and think more, rather than rush ahead and make a mistake.

In my practice time I am continuing to learn to touch type numbers and symbols. I’ve found it very satisfying, just a single run through a lesson on PowerTyping.com is enough to set it into my head where a few more symbol characters are. The real test comes when i’m programming: can i find the parentheses when i need them? Curly braces? Where is that hash key? Do i need the shift key or the alt key, and can i find it without looking?

I didn’t do many rounds of typeracer yesterday, so i want to do a few more today. My fastest yet has been 109wpm but i’d like to push that up to 120wpm. Two words a second, consistently … that would be so awesome!

There have been some interesting conversations just lately about whether or not you have to touch type to be an effective programmer. Of course, you don’t, and i think we would be unwise to apply the sort of value judgements that imply any sort of eliteness or inferiority between those who touch type and those who don’t. The key word here is effectiveness. I recognise that many people are able to program very effectively without touch typing.

However, i believe there is always opportunity to get better at what we do. The questions to ask yourself are whether you feel you could be more effective at typing, and do you want to learn? With the tools we currently have, i believe the keyboard is the best interface between our brain and the computer, so it makes sense to use it to the best of our ability.

Oh my gosh, Frances has just made the most amazing double espresso EVER!! <3

Yesterday I gave a tech talk on Clojure to part of the Eden staff. The talk itself went reasonably well, although I hadn’t prepared anywhere near as much as I’ve prepared for previous talks, and it showed. This really reminds me of how important practice is, especially for speaking to groups. After the talk I ran through the string calculator kata in Clojure with the group.

Having not practiced this at all (as well), and not done that much Clojure in the past month left me feeling a little rusty, and it showed (at one point I couldn’t remember the java api for making a regex out of a string). I will be giving this talk again on Friday at the Software Craftsmanship UK meetup, so I need to practice more.

To get into this practice, I am starting to do a kata every single day on the train home. This week it’ll most definitely be the string calculator, next week I’ll switch to something else (if you have suggestions, twitter at me).

I was delighted last night when i managed to complete one round of typeracer at 99 words per minute with 100% accuracy! That is something for me to be very proud of! Now if i can just get to that accuracy and speed consistently, i will be very happy!

This morning i’ve done my hands-covered 5-minute test at FreeTypingGame.net and scored 76 words per minute, slightly slower than yesterday’s 78. I made more mistakes, particularly with quotation marks and exclamation marks.

Other resources we have discovered:
TypingWeb.com – typing lessons that save your progress. (only Qwerty)
aTypeTrainer4Mac – a Mac program to download and use offline.

Yesterday (the fourth day) was interesting because I was working on Eden as a business, not directly on code. Most of the things I learnt were with regards to marketing, as opposed to coding.

I did have some time to talk to Enrique about the wiki exercise. Reflecting on this further, I realise that I completely overworked the testing side of the assignment, to the expense of the actual code, a trap I have fallen into before. The lesson I took away from this is to remember why writing tests is important; which is that it helps deliver business value.

I am now going to redo the whole assignment (from scratch), concentrating more on the actual wiki, and less on testing.

However, one of the hardest things I’ve found to master is the concept of different levels of thinking to help you prioritise what to do next.

In GTD, to decide which tasks are more important than others, first you look at the context you are in and only consider tasks within that context. For example, it’s hard to blog when you’re in the supermarket, but it’s a handy time to remember you need to buy toothpaste. Then, you look at the time you have available (this isn’t worth starting as I don’t have time to finish it) and energy available (might not be a good idea to draft a difficult and taxing work proposal just before bed).

If you still can’t decide, then it gets interesting. GTD invites you to take a step back: moving from “ground” to “10,000ft”. Which project that these tasks are for will have the short-term effect I’m most interested in? Then step up another level, and another: which project advances my goals for the year? Which is the more important area I should be progressing now at this stage of my life? What meshes with my whole-life purpose?

These are deep questions, and I used to struggle to apply them to everyday task prioritisation. It seemed hard to remember where in my life purpose some of my more mundane tasks fitted, partly because I was thinking about deeper things much less frequently. So I left the “take a step back” method alone, going with what just felt right instead (which isn’t a bad way to prioritise to be honest).

However, through the power of 750words.com, I’ve finally managed to nail this part of GTD.

Morning Pages

There are many ways to clear your head and get yourself to focus. One is to write down everything you’re thinking about in an attempt to organise your thoughts. Some people call this Morning Pages: write three pages a day first thing in the morning, about anything and everything.

Morning pages is a great idea, but sometimes it’s difficult to motivate yourself to get on with private writing. Three pages seems a tall order to write every morning. That was, until I discovered 750words.com. This handy little site ensures that you not only do it, but that you do it every day. Using a full-featured incentive system of points, badges and challenges, you really don’t want to disappoint yourself by missing a day. The site gets you writing, and throws in some nifty writing statistics at the end of the process for some fun analysis of your state of mind. Heck, it even measures your typing speed, which comes in handy for Learn to Type Week!

I thought I’d give it a go a few weeks ago, as I had a fair amount on my mind at the time. What I didn’t realise was the effect it would have on my productivity. My mind was immediately clearer, and I was decisive and more focused. Blogging became easier again: once you’ve written 750 words of effectively brain-dump ‘whatever-you-want’ writing in the morning you are ready to keep on going with something more structured.

Because I use the time for fairly intense personal reflection, this practice unlocked the GTD prioritisation method. I’ve found that I’m moving up and down the GTD “ground”, “10,000ft”, “40,000ft” levels much more effectively. I often know just how a particular task fits into my life goal, as I’ve just written about that this morning. I’m naturally keeping the big picture in mind every day.

The word-crunching statistics that are produced over time are very telling. I’ve noticed an interesting effect now I’ve been doing it for the last three weeks: at first I found it hard to stop and all my writing was concerned with the present. Now it’s harder to think of what to write, but my thoughts are more valuable and much more reflective and deeper. I’m now using it to consider hard life decisions and priorities.

I’d very much recommend you try morning pages, especially if you struggle to focus, get carried away by random disparate thoughts or find it difficult to concentrate. I’m getting a lot out of it.

What I personally like about his story is the message Kerry sends (indirectly) to the developers out there who are not working in an environment where caring about the craft and continuous improvement are part of the day to day.

What I really like though about his entry is his reminder to look outside your companies boundaries and search inspiration and knowledge from other people.

There are many wise people out there from whom you can learn an awful lot!

Who’s code have you studied recently? What new techniques have you discovered?