Author Archives: Steve Barnett

Plans, Details, Dates, and The Future

Naga IT Services
Filed under: Process, Reading

I’ve been faced with a number of rather large planning documents recently, and it’s been making me sad. Some of them feel a lot like specification documents. There was talk of having hard dates attached to things, some of them far in to the future, which would have made the documents more brittle. Being a card-carrying, flag-waving, agile person this raises my hackles a bit. It got me thinking about planning and levels of detail: here’s my (over-simplified, I know) take on things.

Plans should be more vague as they get farther into the future: the level of detail in them, and the dates attached to them. A good form of plan is a product roadmap. Even there, though, it can be tempting to go into deep detail and lock things into specific dates.

Less details the farther into the future you go.

Why less detail?

There’s no reason to go into lots of detail about things far in the future. Those things will probably have changed by the time we get to them, and we we want to be able to respond to change (rather than follow a plan). That’s where agile companies really shine: they learn new stuff and the plan and the doing of things bend a bit to take this into account. Marty Cagan talks about a related issue (things not working) in The Inconvenient Truth About Product.

Before development starts on a new bit of work, you should be building prototypes and doing user testing with them. This always results in some changes to the plan, and often results in rather large charges. You can’t plan what these changes will be: you don’t know until you’ve done your user testing.

I really like how Janna Bastow talks about roadmaps in her article Why Your Roadmap Should Be Flexible on Mind The Product. Her diagram is a great representation of the right way of thinking about scope / detail and time:

The flexibility of a roadmap in terms of time

Why not specify dates?

Things often take longer than we expect. Something far in the future will have a number of dependencies and things affecting it. Each one of those things will have been scheduled based on estimates. In Coding, Fast and Slow: Developers and the Psychology of Overconfidence, Dan Milstein talks about how it’s essentially impossible to make accurate long-term estimates.

Another reason to worry about including dates is that they often get taken as absolutely fixed deadlines. John Peltier talks about this, and how to manage dates and deadline in a roadmap in his article Product Roadmaps: Drop The Dates.

Okay, but what about when a date really is fixed?

Then you invoke the Iron Triangle. Sure, you can definitely have a thing on that day. But it might not be what you expected.

Simple and usable: web, mobile, and interaction design

Naga IT Services
Filed under: Books, Images, Reading

I recently jumped through Giles Colborne’s book “Simple and usable: web, mobile, and interaction design.” Although I found some parts of the book felt a little dated (it was released in 2010), there are some excellent product and user experience bits of advice in there.

I picked up Mr Colborne’s book hoping to find some ideas and inspiration for simplifying the user interface and experience of Vumi Go, and I wasn’t disappointed. Vumi Go is the web app that lets people set up Vumi conversations. It’s a bit of a beast: it gives you access to a lot of the powerful things that Vumi can do with its messaging services, but they’re complicatedly intertwined with each other.

We’ve already made some Trello cards for acting on one of the strategies for simplification: removing. Specifically: tidying up the code and interface by removing broken bits and pieces that seem to have kept hanging on.

Here are my sketchnotes from the book.

Sketchnotes page 1

Sketchnotes page 2

Sketchnotes page 3

Designing for Performance by Lara Callender Hogan

Naga IT Services
Filed under: Process, Responsive

I finally managed to carve out time to read Lara Hogan’s Designing for Performance and I’m really glad that I did. Ms Hogan guides the reader through everything important about performance: from why it’s important, through how to make the changes, and (perhaps most importantly) tips on how to bring about a culture change in your organisation. I highly recommend picking up a copy. Below are my sketchnotes (click picture for larger versions) and a few more thoughts on the excellent book.

Ms Hogan begins by focusing on explaining how Performance is the same as User Experience, and goes into some of the technical details about what factors contribute to performance. One thing that I appreciated being reminded of is that, especially on mobile, Latency trumps bandwidth as a constraining factor.


The next section of the book talks about page speed, optimising images, optimising your front-end code, and responsive web design. It offers lots of practical tips and things to think about.


Ms Hogan then goes on to talk about process-related things: when and how to measure and iterate on performance, and offers advice on making decisions that are between aesthetics and performance. There’s lots of useful stuff there for both developers and designers.

The last chapter is heavy: it deals with introducing a performance culture to your organisation. A lot of the lessons and advice ring familiar from advice on bringing cultural change to accept responsive web design as the norm, and of bringing a focus on User-Centered Design. Ms Hogan again offers lots of practical advice that will be very useful in championing performance as a key measure of success, and therefore bringing more decisions back to the user experience of your site or app.


Go buy the book: you’ll find bunches of stuff that you can apply to your work that will make a difference for you and your users.

Gathering stats and Herding Cats

Naga IT Services
Filed under: Industry, Projects, Talk notes

On Thursday 5th February, I gave a short talk at the Cape Town Scrum Users Group about RailsBridge.


My slides are up on Speakerdeck. I talked about RailsBridge itself (the upstream organisation and how our Cape Town chapter came to be) and the Cape Town team’s focus on Continuous Improvement. I talked about the various methods we’ve used to gather feedback (and how successful or not they were), what feedback received, and what we did with it (lots of things!).

I’ll be giving a remixed version of this talk at the Cape Town Ruby Brigade in March, where I’ll focus more on the Ruby and Rails bits, and the curriculum.

(Yes, me doing all this Ruby stuff is slightly odd, since where I work now (Praekelt Fuondation) is a Python shop. Vumi, for example, is all Python. ¯\_(ツ)_/¯ )