January 12, 2010
Here’s a little something for all you people making lovely apps for Android. If you use a pencil before you start to take your app to the digital realm, then we’ve made some templates to help you design for some of the Android handsets out there.
There are a whole variety of devices to choose from, with different screen resolutions, and hard or virtual keyboards. We find these help give our sketches a little context when we’re presenting them internally or to clients.
The PDF is Letter size (8.5 inches by 11 inches) and the handsets are to scale, so you can use these quite happily for paper prototyping and get a realistic sense of scale. There’s a subtle 10×10 grid on the screens to help you with your pencil based needs. If you’re short on Letter paper, you can get away with printing them on A4.
If you have any suggestions, comments or improvements, feel free to suggest them here.
All that’s left is to snack down on cupcake, donut or eclair, or if you’re feeling greedy – all three. Enjoy – and click here for the templates.
These templates were designed and lavishly tooled by Ali Driver, Senior Designer at Future Platforms.
September 14, 2009
We’re launching a little side-project today. It’s an app for Android phones that lets you read The Guardian, anywhere. We’ve imaginatively called it “Guardian Anywhere”.
It’s designed to meet a simple use case: you want the news on your phone to read on your commute into work. You can tell the app to download your newspaper whenever you like, perhaps early in the morning before you wake up. You can also tell it to only grab the news over Wi-fi; there’s a surprising amount of stuff in the Guardian each day, and we don’t want you running your battery down grabbing it all over 3G.
Once it’s downloaded, the content lives on your phone – perfect if you’re travelling on the tube or through some of the more radio-challenged parts of the countryside (like, coincidentally, the Brighton-to-London line). As well as news stories, you get a pile of photographic imagery which the Guardian publishes every day. We’ve also tried to retain a little bit of the Guardian look and feel throughout, though this isn’t an official Guardian product.
If you play with it a while, you’ll discover a few other nifty features tucked away, like:
- Saving some of the fine photography to your phone as wallpapers;
- Choosing which sections of the paper to subscribe to (or which to avoid);
- Clipping articles or photos into a “Saved Articles” folder, to help you skim for interesting stuff and then peruse it at your leisure;
- Browsing through articles by section, author or tag. This makes it easy to find, say, all the articles in todays paper relating to executive pay and bonuses; and if you’re really interested in a tag (or author), you can subscribe to it;
Guardian Anywhere is the brainchild of James Hugman, who kicked the project off during his gold card time and has been demonstrating it to us ever since at our fortnightly reviews. We’ve been testing and revising the app internally, and launched it onto the Android Marketplace after putting it in for the Android Developer Challenge.
All feedback is, as always, warmly welcome – please do try the app out and leave us some comments in the Market. The little 2D barcode you can see to the right of this paragraph is quite handy for getting hold of the app. Scan it with the barcode scanner on your Android phone to be taken to the right place in the Android Market, click the link if you’re reading this with an Android phone, or just search the Market for “Guardian”.
June 9, 2009
The MDA kindly organised a gathering at the Royal Statistical Society yesterday to discuss how the mobile internet can make money.
In keeping with the venue, here are a few stats – I’ll leave the comment for a later date:
- Vodafone’s worldwide data revenue is up 43% year on year, and is at the same level as SMS was in 2003 (Terence Eden, Vodafone)
- 20% of UK mobile users are mobile internet users (Royal Statitics Socety)
- Vodafone India acquire 1.6M customers per month (Terence Eden)
- 50% of UK 9 year olds have a mobile (Alex Meisl, Sponge)
- Autotrader’s mobile site for 6M impressions in March ’09 (Alex Meisl, Sponge)
- Green Thing’s campaign on Blyk went from 5% WAP clickthrough to 11%-22% (Richard Warren, FirstPartner)
- Mobile advertising spend in Europe is expected to grow to €950M by 2012 (Richard Warren, FirstPartner)
- UK mobile advertising should go from €50M to €220M in 2013 (Richard Warren, FirstPartner)
- A few iteresting figures from the delightful Mark Curtis from Flirtomatic:
- Flirtomatic are now over 1.3M UK users
- Revenues is over $10 per month per spending customer ($1.50 ARPU overall)
- They achieve 160M pages per month on mobile (a lot more than Autotrader)
- Users exchange 30M messages per month
- In 2008 they earnt $2.6M from premium services
- The Strongbow campaign on Flirtomatic, allowing users to send pints to each other for free, achieved a 10% clickthrough rate
- On May 1st, when Vodafone allowed free data to pre-pay customers, Flirtomatc’s acquisitions went up x13
- 2 years ago, Flirto got 3500 new users by advertising on the 3 portal for 3 hours (mirrored by similar experiences we had at Future Platforms)
- 3 UK customers used 34M Skype minutes in Jan ’09 (Rory Maguire, 3)
- 18% of Facebook’s mobile users are on Three (Rory Maguire, 3)
- 21,557 Bebo mobile users are on 3 (Rory Maguire, 3)
- 27% of 3 customers download content, 45% have used MMS (Rory Maguire, 3)
And here are a few interesting quotes:
“As mobile internet grows, it will move off portal” – Richard Warren, FirstPartner [but will it just move to other portals like iTunes, Ovi, Google?]
“mobile advertising takes you to a mobile site at best, it really needs transactions integrated at the end” – Richard Warren, FirstPartner [while we wait for mCommerce, mobile apps may be good candidates as mechanics for retaining a consumer’s attention]
“There is more VALUE in meeting new people then reconnecting with people you already know” – Mark Curtis, Flirtomatic [i.e. people are more likely to pay for Flirtomatic or LinkedIn than for Facebook or Bebo]
April 20, 2009
When developing mobile software at Future Platforms, one of our key objectives is always to keep the application as compact as possible. This is important for a couple of reasons: firstly, it minimises cost to the user when downloading the application over the air, and secondly, some handsets impose an upper limit on the size of application they accept.
The competition rules state that the total app size must be 5120 bytes or less. For Java ME, this consists of a compressed, obfuscated JAR file.
My idea was one which I had wanted to do for a while: an application which lets you easily communicate your location to a friend using your phone’s GPS. Myself and Thom have discussed on a couple of occasions how useful it would be to just zap your location to somebody when arranging a rendez-vous, and let them view it on a map: far better than providing lengthy directions over the phone. I was sure this could be achieved in 5K.
I ended up with a reasonably full-featured application. We make use of the Location API to access the handset’s GPS and landmarks store, the PIM API to access the contacts list, and the SMS API to access messaging functionality. Additionally, we use the Push registry to automatically start the application when a relevant SMS is received.
Once the location is saved as a landmark, it is easy to use the phone’s mapping software to view the location on a map. We even provide the facility to attach a short text message. If the location is sent to a handset which doesn’t have the application installed, it is usually possible to view the location and message as a normal SMS (depending on the handset).
We are more used to making applications in the 300K region! So creating one with a 5K size constraint was good discipline. The application consists of only two classes, with work being done in as few methods as possible, and variables being reused for several different purposes. With some careful refactoring and a bit of experimentation, the size was brought down to exactly 5120 bytes. This even includes code allowing the application to fail gracefully when installed on a handset without GPS.
The application should work on any handset with GPS available, however it has only been tested on Nokia Series 60 devices (N78, N82, N95, 6220 etc).
A few extra bits I would have liked to include are animation on the “Finding location” and “Sending message” screens, and the facility to manually enter a number to send the location to.
It was interesting and instructive to see how it’s possible to create a fairly complete and useful application in a small amount of code.
To try Where Are You on your phone, point your mobile browser to http://tinyurl.com/c4o4op.
April 1, 2009
Here are the main themes I picked up from the conference. I also presented case studies of how clients have achieved success in mobile and took part in a panel discussing the issues around mobile applications.
I missed the beginning of the conference, but the iPhone effect was still clear to see on day 3. Everyone in the industry accepts it as the standard everyone has to aim for. The problem is that it is different in so many ways that people end up cherry picking from it to support their own causes/interests.
What are going to be the dominant platforms in the next few years?
There was consensus over the fact that only 3-4 will survive. With Limo and Symbian reppresented, it shouldn’t come as a surprise that they felt that mobile OS’s are going open. iPhone is however the notable exception.
Bondi amongst others also suggested that whatever happens in mobile OS, the browser is going to be the most viable runtime platform, with more standardised support and additional (and hopefully also standardised) APIs plugging into device functionality.
Mobile Interet 2009 saw a heavy reppresentation of mobile operators and releated service providers, so most of the discussions about revenue were focused on mobile operators.
The long term picture isn’t so rosy. In several countries, flat data tariffs are expected to become the norm and have been pushed to fairly low levels due to competition within the industry and with fixed line providers (with the broadband dongles). The operator’s concern is getting to the situation where 4% of users consume 75% of the network traffic and where they many not ultimately benefit from the expected growth in data traffic.
On reflection, flat tariffs may have a wider implication for the whole industry: operators have so far encouraged mobile internet development with the expectation of increasing revenues. Flat rate will put a cap on those expected revenues and will actually introduce an incentive to reducing/optimising network utilisation – unless network operators find alternative ways of generating revenue from the mobile internet. A few thoughts/models:
+ charge for different bandwidth levels (the problem being that people won’t necessarily appreciate how high the limit is and may therefore limit their behaviour)
+ charge for service packages, similar to digital TV broadcasters, where higher bandwidth services like video streaming are charged at a higher rate
+ control the advertising (more below)
+ establish themselves as the payment method of choice
+ sell value-added content and services
The general feeling is that mobile advertising is still in its infancy, but that it is bound to grow and become a significant source of revenue for the industry. UK mobile web advertising spend last year was less than £10M. Brands and agencies want to spend, but they need the right data to support mobile as the channel of choice (although they do not seem to need much data when commissioning iPhone apps).
TeliaSonera are experiementing with content transcoding as a way of adding advertising to off-portal sites. The PR spin on that is that it enhances the user experience by allowing access to sites that would otherwise be inaccessible and providing a control bar. The real reason is that off-portal content transcoding promises 5-6 times more inventory than on-portal.
March 25, 2009
Today was our first review and planning day with the new two-team Future Platforms, and to give ourselves a bit more space to stretch out, we tried holding the morning session at The Skiff – a coworking space run by the Inuda folks a couple of streets away from our offices.
The facilities there were excellent. As well as more space we had walls to stick postits onto with (and lots of visibility, room to walk around, etc.), a projector, and beanbags galore. All of this – plus being in an unusual space away from the usual workplace – made a big difference.
The review went well, with our two teams (Anjuna and Tonberry) demonstrating projects they’ve been working on for Microsoft and the BBC respectively. Compared to the limited visibility you get by passing a couple of handsets around a room, having 5 foot tall on-screen demos felt like heaven… and the demonstrations themselves seemed to “flow” a little more than in previous reviews. If only I could talk a little more about their content; as usual, NDAs have my lips sewn shut. Unusually, our design team weren’t presenting their work this time around – much of it has involved supporting the development teams (and was therefore visible in the dev team demos), and South by Southwest had taken its toll on our design resource over the last fortnight….
I was really looking forward to the retrospective, and wasn’t disappointed. The near-unanimous view from both teams was that splitting the company into two had been a success. Each team felt more focussed on their respective projects, had been less affected by context switching, and found stand-ups both quicker and more useful. Even better, we could see measurable and significant improvement in the productivity of the company split into two teams (vs all being in one team).
One issue which was surfaced by 4 different people was that of planning and testing time. We have a persistent experience where testing effort bunches up towards the end of sprints – so that at the start of each fortnight there’s sometimes not enough for our dedicated testers to do, and at the end of the fortnights too much.
My own tendency is to attack this problem by trying to spread the load of testing more evenly throughout the sprint (encouraging units of work – user stories in our case – to be taken through development and testing to done before starting on others) and having other team members help out with some of the testing work when there’s too much (whilst some of it demands the eager eye and magic software-breaking fingers of a good QA specialist, I feel there are areas where the rest of us can usefully pitch in). We had a fairly lively debate on this one, and didn’t reach a useful conclusion. In particular I had hoped to bring in some of the limiting-in-phases techniques Karl Scotland covered in his recent Kanban presentation (also held at the Skiff), but we didn’t reach consensus on adopting this – so I’ll give it another go next time around.
Burndown charts also stimulated a bit of conversation. I’d experienced a worrying few days with Anjuna mid-sprint, when progress on getting stories to completion was minimal even as the team frantically worked on a core section of the product… and I’d found myself noting a problem but stuck on what to usefully do about it. In the end the team pulled through and delivered, but I’m left feeling slightly worried; we’ve had sprints in the (thankfully distant) past where a flat-lined burndown continued right to the end, thanks to my ignoring the signs. Putting a positive spin on it, the worst that we’ll ever do is experience a single unproductive fortnight, but even that would feel like a huge opportunity wasted. More thought required.
Finally, on design; last sprint we opted out of planning it formally, this time around we’re officially embedding the design team with Anjuna, where they can crack on with pushing that particular product forward together (and without distractions from other projects).
A solid day; we saw the juicy fruits of our work, had some productive discussions on how to get better, persuaded a sizable chunk of the company to come out for gyoza etc, planned in two teams’ worth of work for a fortnight, and still managed to finish dead on 6pm. Considering that a year ago planning days were regularly overrunning and leaving us all half-dead, with a smaller team, it’s great to see how we’re improving. On that particular point, it’s amazing what benefit an hour or so of working up a sprint backlog for each team the day before planning can deliver…
Thanks as usual to Joh for her facilitation of the retrospective, and to the Skiffers for hosting us!
March 15, 2009
It’s a while since I last wrote about how we’re getting on with Scrum, and we’ve had an eventual few weeks… so here goes.
We’re doing This Thing, right, and I can’t tell you anything about it at all, except that 9 of the Future Platforms team flew into Hong Kong a few weeks back and spent a fortnight working on-site for Microsoft in China, to kick off the project we’re doing with them…
It’s been quite an experience in many ways: travelling abroad as a team, working across cultural and linguistic divisions, and fitting our processes in with those of the worlds largest software company. We wanted to colocate ourselves for all the classic reasons: tackle risky elements of the project together, put faces to names, and build relationships which can weather the inevitable highs and lows of a collaborative project. And of course, we’re running things in the way we always do – I hope I’ll be able to write more about this in time, I think we’re going to be learning a *lot*.
For those of us lucky enough to go, it was definitely an adventure: hard work, thanks in the main to the sheer dedication of the FP team who were heads down for a full working day and frequently carrying on back at the hotel… but we had a lot of fun, too – as our various Flickr feeds will attest – and our hosts took great pains to make us feel welcome.
We landed back into Heathrow at 4:30am on Monday, and have been collectively fighting jetlag ever since – at the same time reuniting with the crew who remained in the UK whilst we travelled abroad, and our newest hire, James Hugman – who I’m maxi-chuffed to have working with us.
One thing we’ve been conscious of in recent months is that our team size is starting to become a bit cumbersome. Stand-up meetings feel less relevant when there’s 10 people working on a few projects, retrospectives become harder to run with so many opinions to bring out and discuss, and it’s easier to lose focus when planning. And personally I have always cherished the times when I worked in a small (3-5 person) team – it’s when I’ve had the most fun as a developer.
So before we flew to China, we’d held an end-of-sprint retrospective where we agreed that now might be a good time to split the company into two teams – and on Wednesday we did just that. It was quite involved, and in the course of the retrospective we covered:
- Make-up of the two teams, ensuring they were balanced from a skills perspective and that they allow for continuity. We want to keep folks who’d just built relationships with Microsoft carrying on the good work, for instance;
- Office space, making sure the teams are colocated and have control over their own environment (they’ve already chosen radically different desk layouts), and that both have space to meet around a task board daily;
- Running planning days; I was keen to bring the whole company together for reviews so that we all get to see what we’re collectively up to, but we eventually decided to do the same for retrospectives (with a view to learning as much as we can from our experiences even across teams), whilst separating planning out into two per-team 90-minute sessions in the afternoon of planning day, and running separate daily stand-ups.
- Naming the teams 🙂 Anjuna and Tonberry it is!
The day went surprisingly smoothly and was unusually calm. Mary, our Product Owner, has been doing an excellent job of pre-planning preparation (grooming the product backlogs of our various clients into sprint backlogs efficiently), which pays dividends, and we were finished by 6:30pm tonight even after office rearrangement and a 90-minute lunch break, in which we introduced Mr Hugman to the delights of E-kagen.
The main problem we’ve had is that of accurately predicting a velocity for the two teams. In China our productivity was unusually high (greater than it’s ever been, in fact), which we ascribe to working long hours with an unusual level of focus on a single project. Some of this (the focus) we can try to carry forward – in fact, the two-team split should assist us in doing so. But with the company split, we’re not in a position to accurately estimate what one of the new teams can get through, until the end of this sprint.
So we now have 2 development teams, each comprising 3 developers and a full-time QA – plus a design team of 3 supporting them. We’re running design separately for the moment: we have a couple of large design projects, one of which involves no development at all, and will be bringing designers into daily standups for any sprint in which they’re doing any work with the dev team.
Next steps: we’ll bring in another Product Owner (we need to give our clients more love, and this will help – watch this space!); and see how well the team structure we’ve chosen works over the coming weeks.
December 27, 2008
Go read this article, “There is more than one mobile context“.
For some time now I’ve been becoming gradually uncomfortable with the notion that mobile content is purely about snacking on small chunks of content or limited to snatched moments of time – though I’ll hold my hand up and admit this is a view I’ve held, and frequently espoused, for years.
A few observations have drawn me away from this view:
- Watching Trutap become a primary means of connecting to web services for a couple of hundred thousand folks in Asia, and learning that there’s a huge middle class who are leap-frogging ADSL in favour of 3G;
- Noticing that peak times for a casual gaming service we run are after 11pm, when I’ll bet most folks are at home near their PCs or games consoles, not on the bus; and
- Slowly finding that around the home, my iPhone is replacing my laptop as my means of quick web access. It’s not as fast, as large, or as flexible, but it’s always there. Walking 10 feet and opening a zip-bag and case may only take 10 seconds, but as the Googlers know, when reduce the time between wanting X and getting X, you sell more X;
I think that, in the UK at least, this is still unusual behaviour. But when you see this happening in a tiny corner of one territory and already starting to play out in others, there’s not much conceptual hopscotch to be played: it’s not if this happens, but when.
A quarter of iPhone users say it’s displacing a notebook computer. 28% of iPhone users surveyed said strongly that they often carry their iPhone instead of a notebook computer.
My gut instinct is that this isn’t purely an iPhone phenomenon, and that there’s something more happening here – an acceptance that availability trumps screen size? An across-the-board improvement in access speeds and UI?
There is more than one mobile context. Decide which you’re interested in.
I think this article is lovely, but the author has left out one context: the mobile as your primary means of getting online, not because you’re away from home, but because it’s yours, it’s nearby, and it’s how you choose to be online in general.
November 29, 2008
It’s 2008; if you’d asked us a few years ago, we might have hoped fragmentation would be a thing of the past by now. It’s still a topic of much debate at industry events and considered a bete noir for anyone launching a mobile problem. But is it really such a problem?
Developing large J2ME applications like Trutap is typically a two-stage process. The first stage is to complete the functionality of the application, generally by targeting a couple of reliable handsets to create a couple of “reference versions”. Once the features are working well and to the satisfaction of the client across the reference handsets, the next phase is to port the product across a greater range of devices and fix any problems that arise.
The porting process is affected by fragmentation (differing availability of phone features), handset limitations (e.g. varying amounts of memory and storage available), and bugs (broken or badly implemented features on specific handsets).
The bad old days
The traditional way to tackle porting is to create separate builds for each device, or family of devices. Conditional compilation and preprocessor statements are used; effecively, portions of the application are written multiple times, each time working around unique quirks of particular handsets. Font sizes, key mappings and the ability to run in the background are typical sources of variance between devices.
When building the application, the portions of code required by each handset are picked, according to a set of characteristics that we assign to each handset. For example, a handset that we know is able to use socket based connections will run a different version of the application to one which is only able to connect via HTTP.
All sorts of problems exist with this approach to porting. It relies upon a prior knowledge of every target handsets capabilities in order to work effectively. That is, all the issues that may affect an application running on any given handset need to be understood before a version can be built. You also end up with a slightly different version, uniquely tailored for every handset that we support. If you are targetting even a moderately broad range of handsets that’s a whole lot of different builds, and keeping track of what code is going in to each can be very difficult. The QA effort is also vastly increased. Once ports are built and tested you can only be confident in delivering the ports to the handsets you have tested on. When new devices come onto the market or existing devices get software upgrades, /more/ porting and testing is needed before these new handsets can be supported.
Things get even worse when your aim is to use restricted APIs or be featured on many operators’ application portals. In order to do this, your application builds need to be thoroughly tested by an official verification body and digitally signed. This is charged on a per-build basis; having many tens of builds of your application will increase these costs dramatically. And remember that every time you release a new feature or bug fixes, you need to recertify.
A different approach
Having been troubled by many of the issues discussed above in the past, we decided to turn this approach on its head with the new version of Trutap. We judiciously apply some carefully chosen prior knowledge of the features common to the devices we’re targeting and let the handsets tell us the rest when we run the application. We can reliably tell on the fly what a device’s screen size is, and whether it supports features such as camera, phonebook or Bluetooth. This way, all devices run essentially the same version of the application.
The consequence of this is that devices that lack certain features will have pieces of the code on there that they will never use. However, for the price of a few superfluous bytes of code on some handsets, is an application that has a much higher chance of *just working* on any phone on which it is loaded. And nowadays there are very few handsets on the market where, even for a large application, the additional code size is a problem.
The Trutap UI just falls into place, scaling itself on the fly with regards to screen size, image assets and font height. And as a result, we’ve spent the bulk of our porting effort solving a few real problems with our target devices, rather than nudging the UI into place on, say, a handset with obscenely large fonts. The end product: a single version of the application, with only three different packages for distribution (each containing small, medium and large icons). The consequence: a clean, maintainable codebase, a relatively painless porting process, and a far simpler testing phase to boot.
So where’s the magic?
Most of the time if UI components are implemented carefully and robustly, they can scale themselves to the resolution of the device they are on and there is no need for magic. Features that require special device functionality can be included or left out as and when it is needed by detecting what APIs are accessible. A handsets colour space can be accounted for by writing to and reading back from hidden test images. Accurate font height can be detected at runtime in similar ways.
With a thorough understanding of handset behaviors it’s nowadays possible to sidestep at runtime most of the problems normally associated with fragmentation.
Fragmentation hasn’t gone away – but it’s not such a problem any more.
Thom Hopper & Douglas Hoskins
Lead Developers, Future Platforms
November 28, 2008
Yesterday afternoon we invited the Trutap team down to Brighton, for a post-project retrospective. It’s the first time we’ve done one of these with a client – normally we run them every fortnight with the whole FP team. On top of learning what we could from our largest Scrum project to date, we wanted to lift a bit more of the veil.
I won’t go into the full details of how we ran the day; aside from anything else, the festivities afterwards have blurred much of my memory, but I do have a good set of notes regarding our learnings. As is traditional for us, we split these into things that went well, things that didn’t go so well, and things we’d do next time. There was also an opportunity for us to call out individuals for particular appreciation, which I liked.
So, here’s some of what we got out of it:
What went well
- Porting has been extremely smooth this time around. Within 10 days of completing a reference version of the product, we’ve fully QAd and released the new Trutap for around 150 handsets, with more following as I write. Most of the credit for this rests with our fine development team, who’ve been leading us away from the industry-wide nightmare of maintaining hundreds of different versions of the product, and towards a rosy future of fewer SKUs. There’s another post about this on its way, and I mentioned how we’ve done this in my Future of Mobile presentation. Suffice to say TT version 1 had more than 30 SKUs, all built from a single code-base but targeting different devices. TT version 2 has a single binary, and comes in 4 flavours for different screen sizes.
- Shared documentation and tools, in particular the product backlog (all work remaining to do) and our bug tracking system, really helped. We were operating very transparently; I do wonder whether a less technically capable client would be as interested, but for those who want it, we’ll do this again.
- The relationship between the development teams at Trutap and FP was strong: we like each other and we got on well. ‘Nuff said.
- Weekly meetings were very useful, though we only started holding them a couple of months into the project.
- Change was handled smoothly; we were able to accept change, addition of scope and iterate aspects of the product as necessary throughout.
- We worked at a sustainable pace; we week before launch there was an eery calm at both Trutap and FP. Tthe product was there, the bug count was close to zero, and we hadn’t had to work evenings and weekends to get to this stage. Compared to the period before previous launches I’ve known (even for Trutap), this was incredibly calm. I don’t think our adoption of Scrum can take all the credit for this – the project involved a skilled team at FP and TT who’d worked together before, for one thing – but I certainly think it’s helped.
- Wireframes were a poor means of specifying the product, requiring a lot of clerical maintenance and attention from both sides and offering an ambiguous level of detail: too much in some areas (e.g. screen layouts), too little in others (e.g. error states and flows).
- We started the project haphazardly at both sides, and had to act to bring it back on track a couple of months in.
- The design process had “too many cooks” and could have been more focused.
- We should have spent more time explaining our approach, from both a project management and a technical perspective. We never actually sat down with Trutap and said “this is how we’re going to work”, instead keeping the details of our process to ourselves. With a large successful Scrum project under our belts and a bit more self-confidence, we’ll do this next time. Equally, from a technical perspective we had a clear idea of how we broke down the work (into screens and UI components) which we could have shared earlier on.
- Using version 1 of the product as a catch-all default was a mistake; where not otherwise specified, the product was to “work like version 1” which led to some scope being missed off planning at the FP end, and some confusion where new features didn’t dovetail with old behaviour.
- We had many means of communicating: Google docs, Basecamp, Fogbugz, a Jabber chat-room, email, face-to-face meetings, etc. This sometimes led to a lack of clarity and nervousness: when a chat-room had been set up but our dev team weren’t available in it (because they were getting on with work!), the client worried. Next time around we should clarify communications methods: different tools seemed good for different jobs.
- Early in the project, we weren’t as good at making collective decisions as we were later on. A looming deadline always helps focus the mind 😉 but we’d try to get this focus earlier on future projects.
Next time around…
- We’ll prototype more and wireframe less. We may invest time into tools to support this. Wireframes don’t cut it.
- We’ll plan to iterate from the beginning, allowing contingency in timescales and commercials (in fact the latter was planned for, as it turned out ;))
- We’ll introduce any change at fortnightly sprint boundaries. A couple of times we had mid-sprint changes which led to the dev team at FP thrashing and progress slowing. Lesson learned: we should be more disciplined here.
- Towards the end of the project, we had a day we called the “UI Sweep”, where the TT product team sat with our developers and worked through final bits of polish. This made a difference to the product quality disproportionate to the amount of time spent. It’s quite gruelling for the developers, and relies on good tools and practices that let you make changes there-and-then, but was ultimately very worthwhile. The idea of an on-site customer is classic XP.
- We’ll have weekly meetings from the beginning, with everyone engaged and involved.
- We’ll get everyone to the pub more often 🙂
And the role of honour: called out for particular thanks were Ali, Tobias, Luke and Rob @ Trutap of Trutap, and Thom, Doug and Serge at FP. Thanks again guys, we built something fantastic 🙂
None of this would’ve been possible without the able and entertaining facilitation provided, as ever, by Joh Hunt – cheers Joh 🙂