Author Archives: pauldyson

Delivering Software with Cards, Magnets and a Wall

IMG_0574

“We need some new development task tracking software. What is everyone using?” asked someone on a CTO email list I’m a member of. “Is Jira still the standard?”

Jira, Trello, LeanKit, Pivotal and their ilk have never been for me. Since I first started practicing XP mumble, mumble years ago it’s always been about cards, magnets and a wall. Above is the old Singletrack office with two separate boards for our two main product strands and a third for customer roll-out work.

“But what if you have a dispersed team with remote workers” a Trello fan will ask. Well, maybe if we were entirely dispersed I’d use something like Trello but I’m also a fan of co-located teams so even with several remote workers at any one time we have most people working in front of the wall and stick smartphone pictures onto Slack for those not in the office. Local people move cards on behalf of the remotes.

“What about reporting?” asks the Pivotal advocate. Who needs reporting when I can go stand in front of the wall for a few seconds, see where everything is, and ask devs questions about what they worked on and are working on now?

“What about losing cards and work not getting done” says the Jira guru. In those mumble, mumble years, even working with teams of 50-odd devs it’s never been a problem. Very occasionally a card goes missing but we realise that pretty quickly and write it afresh. And you can’t tell me tasks don’t get lost in Jira sometimes; in fact I hear that is more the norm than the exception.

However these objections miss the fundamental point. The real value in using cards, magnets and a wall is in the physicality of it. Cards get written collaboratively, not entered into a system. A card might get written once in a planning session then ripped up and re-written as two or three more cards: it’s such a low-friction process. We use different coloured cards for different types of work, badges to indicate different initiatives, coloured star stickers for priority work. Stuff get’s written on the front and on the back and related cards get clumped together.

And it all just sits in front of the whole team, and indeed the whole company, the whole time.

We had a developer in for interview the other day and she told us her current team had to schedule a daily reminder to make sure their Trello got updated otherwise they forgot to do so. The mind just boggles.

But that’s just the day-to-day mechanics. Last year I got to fulfil a long-held ambition and  had a custom wall built to replace the old magnetic whiteboards when we moved into a new office:

IMG_0604 (1).jpg

In explaining what I wanted to the initially very skeptical designer, who was a big fan of Basecamp,  I had to describe the purpose of the wall, not just the function. Here’s what I wrote for them:

“To me, it is not just a functional tool. It is where the challenge of what the technical team needs to deliver is quite literally writ large. You can see the cadence of releases in the ebb and flow of cards on the wall and the hither and thither of developers and QA as they go to move cards.

“It is easy to spot when a card gets stuck in the backlog or priority cards aren’t being progressed. I know when we have just reviewed all the work because the board is all neat and when we’ve got a good chunk of work done as it’s all messy again.

“It is a physical manifestation of what we’re tasked to achieve and we celebrate that rather than hide it away in an electronic tool like Basecamp or Trello.”

A week or so after this exchange with the designer one of our graduate developers had a real aha moment after a couple of months with us. “I think I get it”, they said “it’s not about “here’s the work” [mimes being given a card], it’s about “here’s the work” [waves their hands across the whole of the wall]”. Spot on; not the work you have to do as an individual or a pair but the work we have to do together as a team.

A couple of months ago someone on the same CTO mailing list asked if anyone had an example of an inspiring bit of office design and Jonathon Lister Parsons of PensionBee was kind enough to suggest our wall. Which was such a thrill as that is exactly what it is designed to be: an inspiration to the team.

Technical Details

The Singletrack Wall is constructed of plasterboard mounted on batons attached to the office wall underneath. Glued to this are sheets of 0.8mm ferrous metal (avoid magnetic paint or self-adhesive magnetic sheeting, the magnetism isn’t strong enough) which is covered with mildly textured, hard-wearing wallpaper. Strip lights at the top and bottom give the Wall a ‘glow’ and we have office lighting directly above it so the cards are never in shadow.

The wall is divided into sections using magnetic tape so it can easily be reconfigured. We have a variety of magnets as different people prefer different styles. Our Head of development likes multi-coloured ones, the lead on our analytics product stream only uses black ones (you can see those in the top section of the board) and I love these neat little extra-strong Neodymium numbers. This mixture does nothing for my OCD tendencies but, self organising team, what can I do?

Exciting news: we’re just about to move the Product Engineering team to their own office so I get to build a WHOLE NEW WALL. Any suggestions for improvement?

 

Advertisements

How XP helps me keep coding

“But do you still code?” is a commonly asked question when I tell people I’m a ‘hands-on CTO’.

“Yes. Not every day, but most days.”

“Real code? Like production code, not just R&D?”

“Yes, production code.”

This is extremely important to me. In amongst all the other responsibilities I have as CTO I feel that being able to get hands-on with the code keeps me grounded in the reality of delivering our technology, it helps me relate closely with our developers, and it keeps me sane. Well, sane-ish.

Then someone asked me a question no one else has asked before:

“How do you do that?”

As their company grew they had less and less time to code and, when they tried, it just didn’t work. The codebase was so unfamiliar that they struggled to get started and if they got started they never had time to finish. Within just a few months they felt they no longer had the ‘right’ to change a system they had single-handedly built the earliest versions of.

It turned out the answer was simple: an XP process, specifically, TDD and Pairing, and a bit of commitment.

Last week we needed to make a very quick change to an important data processor. The change was subtle but complex so rather than asking the dev team to read the spec from the data consumer, or get a lecture on it from me, I paired in with one of the devs to write the tests and then the new functionality. Pairing on the tests was actually pretty quick which meant that if I had got dragged away to deal with something, someone else could have taken over on the functionality update. But, as it was, a couple of fun hours later we had all the changes deployed for final testing and then into production by the end of the day.

Recently I ran a new static code analysis tool that highlighted a specific set of code quality issues. I wanted to understand the cost and the benefit of addressing the highlighted issues before raising them with the dev team so I spent a few one hour sessions refactoring code to address one or two examples of each issue. TDD is more than just having tests but not for the first time I was thankful for the comprehensive and trustworthy test suite to prove I’d not screwed things up. Making these changes was valuable for me to evaluate the validity of the issues and served as a good set of exemplars for a team-wide initiative to address all the issues and add the tool to the build process.

TDD and Pairing are easy, they’re just how I work. Commitment is much harder but just a few hours a week is all I need to retain a very real connection with our technology and our development practice.

How could I not do that?

Digital Nostalgia

Some time in 1992, the inspirational Bruce Anderson told me I needed to learn Smalltalk. The web was in its infancy and with little information in the University of Essex library my only resources on this quest were a 720Kb 3.5″ disk with Smalltalk/V on it and a videotape. Being an impoverished student I first had to borrow a video recorder and then my introduction to a programming language still more advanced than most of what is out there began.

The video is only twenty minutes long but I had to watch it in two parts due to the headache induced by the lack of vertical sync between the video camera and screen. Bruce tells me the video was made in 1985 at Queen Mary College, London on a Tektronix 4400 series.

Many thanks to Bruce for giving me permission to publish this small but pivotal part of my programming history

Collaboratively Choreographed Chaos (with Common Cause)

I recently discovered that the best way to spend some time in Venice is to buy an all day ticket for the Vaporetto (ferry bus), find a seat at the front, and just take it all in. Over time I found my attention drawn to how the various users of waterways picked their way through the Canal Grande.

Elegant Gondole present tourists with a facsimile of romance and a personal tour of the city’s heart.

DSC_2446.jpg

Luxurious Taxi d’Acqua provide both the fastest way of getting from A to B and a comfortable way of touring.

8427362769_3d5793d73c_o.jpg

(c) Ted McGrath https://flic.kr/p/dQGrm6

Utility barges bring wine and beer (and presumably other goods) into the city, and take the garbage away.

Lumbering Vaporetti move large numbers of tourists and workers en masse through the city.

And so on, all sharing the same small area of water.

DSC_2434.jpg

Given the vast differences in speed, size and agility of all these craft you might expect a series of strict rules and controls to govern all this, but it appears not. There are no traffic lights or aquatic roundabouts, there is no requirement to stick to one side of the canal or other and no clear right-of-way precedence. What there is is a series of calls and signals that indicate the intentions of the pilots, taxi-drivers and gondoliers to each other. There appear to be a number of common-sense conventions based around the needs and abilities of each craft which are applied, or not, as each situation demands. And the men and women that navigate the canals on a daily basis are highly skilled at what they do.

It is a chaotic system in the physics or maths sense of the word: a complex system whose behaviour is so unpredictable as to appear random. But it is not the randomness of total mayhem, rather the collaborative choreography of a diverse group united in common cause: to service, directly or indirectly, the tourists who are the lifeblood of the city.

Returning to work I was struck by some parallels between the seemingly random and yet ultimately highly effective Venetian waterways and our development process at Singletrack. As a team we have lots of different demands on our time: core product development, support, customer-specific customisations, new customer roll-outs, support of sales efforts and so on. All of these move at different speeds and have different, sometimes competing, characteristics and constraints.  Our development process is a mild variation of late-90s XP: a variant because we’re self organising and most of the team wasn’t doing development in the late 90s, and mild because those core practices and principles still work. Its very lightweight, everybody understands it, and its very effective.

I’ve recently begun to worry that this lack of evolution from how I learned to do things nearly two decades ago demonstrates an unwillingness or inability to change. To keep up with the state of the art. I spend time looking at new and different processes and techniques but somehow they fail to engage me and, other than the occasional cherry-picked idea, I go back to what I know.

I realise that it can’t be that Scrum or Kanban or Modern Agile are sham approaches that deliver nothing. It can’t be that NoEstimates and NoProjects have nothing worthwhile to say (even if they do seem to be determined to say it in a particularly negative way). MobProgramming must be good for some people somewhere. But I’ve found them to be limited in value to me.

What my Venetian experience helped me understand is what’s important is that you have a set a of calls, signals and conventions that allow you to collaboratively choreograph your movements, not what that those calls, signals and conventions actually are. The ones that are called XP work for me, maybe the ones called Kanban and MobProgramming work for you. What’s important is that your approach actively works towards the common cause of your organisation not that its the one that gets the most hashtag traffic on Twitter.

When I thought about writing this blog post I did a bit of research on Venice and its waterways. It turns out that what rules and restrictions are imposed had remained unchanged for nearly 200 years until the death of a tourist in 2013 (http://www.telegraph.co.uk/news/worldnews/europe/italy/10268403/Venice-to-control-boat-traffic-on-crowded-canals.html). The response to this tragedy wasn’t to impose a totally new regime of strict controls but simply to update the conventions slightly to reflect Venice in the modern era. Barges have had the hours they can enter the city limited, and illegal docks and piers have been removed, but the fundamentals of the collaborative choreography to suit the common cause remain intact.

So don’t look for the latest or the ‘best’. Look for the calls, signals and conventions that work for you. Find the collaborative choreography that marshals all the disparate people with their disparate needs and disparate talents towards your common cause. Make it work and then keep it working.

DSC_2443

 

 

 

Getting the best out of Tech at Sales meetings

Like most enterprise software there is usually a point in our sales cycle where the prospect’s technical team want to do a bit of technical fact-finding or due diligence on us. As we grow one of the common internal complaints is Sales find it hard to secure time from our tech team to attend these prospect meetings. So I wrote a short guide to getting the best out of tech at Sales meetings which I realised is not particularly specific to Singletrack:

Tech at Sales Meetings

Its primarily aimed at Sales but its also partly about what a tech team should be able to support.

A Paean to Speccy

“Remember the ZX Spectrum?” the Guardian asked a few days ago. Remember it? That fragile black-and-grey box with the jaunty flash of rainbow colours and precariously attached ‘RAM Pack’ set me on a path that has come to define my entire life.

I remember hooking it up to the battered second-hand black and white portable that served as our family TV in the early 80s and loading in a copied game from tape. Brrrrr, chi. Brrrrr, CHEEEEE etc.

I remember getting it to print ‘Hello World’ 10 times using BASIC, and then modifying that to print ‘Hello Paul’.

I remember the hours of typing Hexadecimal from cheap-paper magazines smudged with sweaty fingerprints. “Is that an E or an F”. Like alchemists we toiled over our steaming cauldron of a computer trying to turn the base metal of those listings into the gold of a simple game. We even succeeded once or twice.

I remember the animated Valentine’s card hand-crafted in Z80A for my first girlfriend. Diagonal scrolling, jaunty tune, teenage poetry. She dumped me the next day for reasons I still haven’t fully grasped.

Getting a chord out of a one-channel sound chip. Creating a spinning wireframe cube. Ghhhhheestttbushhhhhterssshh. High Speed Dubbing tape-to-tape ‘sharing’. And Elite. Oh My God Elite.

Eventually, of course, like my Star Wars wallpaper and Superman duvet cover I grew out of the Speccy and replaced it with a ‘proper’ computer – an Atari 520ST.

But i still miss that little box of magic. And that wallpaper.

“Talented, motivated and keen to learn” Yeah? You and everyone else

Singletrack is hiring again. Generally I love the hiring process and I’m looking forward to adding some fresh new talent to our growing development team in the new year. Personal contacts and word-of-mouth referrals only take you so far and we, like every growing business, have to deal with recruitment agents and advertising. I don’t mind: a good agent is worth their fee and ads can bring in unexpected delights.

But what the fuck has happened to CVs recently?

I rarely receive any CVs longer than two pages and the cover letters are bland variations on a theme: “I’m a talented and professional programmer seeking a new challenge. I’m hard-working, motivated and keen to learn.”

Yeah? You and everyone else.

How am I supposed to tell anything useful from a paint-by-numbers cover letter and a two-page resume where the first half of the page is an alphabet soup of programming languages, technologies and methodologies. Where the remaining page-and-a-half is a line or two about the projects you’ve worked on with almost everything about the project and nothing about your work?

How can I get any kind of feeling about you when your CV is devoid of all personal information apart from your name? Worried about discrimination? Aren’t we all but I, as I’d imagine most tech employers, don’t think that way and finding out you’re 50 and have cross-trained to programming after a career as an English teacher is something I’m going to find out pretty quickly anyway. In my case something like that is likely to make you more interesting to me, not less.

Here are my top five tips for getting a job with Singletrack or the many other employers looking for great people to join their development teams:

  1. Write a specific cover letter. Given you’re applying I know you want A job … I want to know why you want THIS job. It just has to be short and specific letting me know you’ve read and understood the job description, that you know a little about what we do and that you think you’re the person we need. 15 minutes of your time is all that’s required and if you can’t spare 15 minutes finding out a little about a company you might end up joining you’re definitely not the person for us.
  2. Write an adequate length CV. This ‘make everything fit on two pages’ approach is bullshit. We generally look for people with significant experience and there’s no way you can adequately tell me about the work you’ve done, the skills you’ve got and the person you are on two sides. Guess what? I’ve been hiring people for well over a decade and I know how to skim-read a six-page CV and spot good stuff, especially if the covering letter has already caught my eye. I don’t want chapter-and-verse but a short, pithy precis of everything you think I need to know about you if we’re going to work together.
  3. Tell me what you’ve done. Okay, I need to know a little bit about what a company or project was about to get some context on the work you’ve done. But its just background. This is your CV so don’t just tell me what the company does or what the project delivered, tell me about your role in it, what you took responsibility for and what you achieved.
  4. Tell me what you’ve learned. I can’t believe how few CVs I read that contain phrases like “On this project/at this company what I learned was …”. The thing about what you’ve done is its generally a factor of time: you can only do so much in a period of time. The thing about learning is its a factor of your capacity, openness and willingness to engage. Between a candidate that has done much and learned little and a candidate that has done little but learned much there’s only one winner.
  5. Tell me about you. Show me the person as well as the employee. Single mum who’s taught herself programming at nightschool? Now that’s hard-working, motivated and keen to learn. Lover of philosophy? Someone who knows about how to think. Fan of 80’s electro music? We’ll no-one’s perfect but I won’t hold it against you; it didn’t stop me founding a company with someone.  Fanatic Mountain Biker? There’s a reason we’re called Singletrack Systems.

The first three are really the basics: don’t do these and you’re just letting yourself down. The last two can make a stand-out difference. We’re looking for people to come and spend days, weeks, months and years with us so finding out about the person, not their skills and experience, is the number one priority.

And it all starts with the CV.