Email iconarrow-down-circleGroup 8Path 3arrow-rightGroup 4Combined Shapearrow-rightGroup 4Combined ShapeUntitled 2Untitled 2Path 3ozFill 166crosscupcake-icondribbble iconGroupPage 1GitHamburgerPage 1Page 1LinkedInOval 1Page 1Email iconphone iconPodcast ctaPodcast ctaPodcastpushpinblog icon copy 2 + Bitmap Copy 2Fill 1medal copy 3Group 7twitter icontwitter iconPage 1

Over the last 6 months we’ve been honing our Agile process and discussing the tools we need to support it. Like many before us we originally made the mistake of thinking that tools come first and we inevitably hit a few brick walls, eventually realising that in reality tools are the icing on the cake to a well thought out, simple process. In fact, I would add that a well thought out process should actually be possible to execute without any tools at all. A wall you can write on and a pack of post it notes is all you need to start with: only when you are confident your process is right should you start to add tools to the mix and the only reason you should add them is to make the process more efficient.

When I say ‘tools’ of course I am referring to the many pieces of software out there which purport to make your lives easier when designing, developing and managing a project. There are literally hundreds and we have only scratched the surface with a few but I thought I’d write about the one’s we tried and eventually the ones we settled on as it might be of some use to other agencies.

Before I start, I want to re-state in no uncertain terms that if you’re looking for a tool before defining process you’re going about it the wrong way: no matter how good the tool it will fail you if you don’t actually know your own workflow because you won’t actually know what to look for and won’t be able to make a judgement as to its success (how will you know the tool is making your process more efficient if you don’t have a marker to judge it against?). Don’t just start using a tool because so-and-so recommended it or some flashy agency has written all about how it changed their world. Just because something works for one company doesn’t mean it will work for you. I’ll say it again (and I write this having made the very same mistakes), start with a wall, a bunch of post-its and some semblance of an understanding of what YOUR sprint consists of. Try it, adjust it and try it again. Make mistakes and learn each week. Then find a set of tools that fit and if they don’t make life easier be prepared to ditch them quickly and move on. Don’t be afraid to pivot and start again – there is no shame in that in the world of Agile.

The winning combination

Trello is the Jewel in the crown

A big factor in our decision making process was that Trello was already well used (albeit informally) throughout the office. Developers, designers and project managers were using it independently to manage their own day-to-day activities. It’s such a powerful and flexible tool that each time we tried something different, it just didn’t work and we all become just a bit sad that Trello was not part of our lives.

What we needed to do was formalise the studio workflow and allow Trello to take centre stage, it’s now the jewel in the crown of our Agile workflow with everything else factored in to support it.

We use it as a holding bay for the user stories identified in user story workshop/s:

And we use it for our sprint workflow after pulling stories from the backlog to the sprintboard in the Monday morning sprint workshop:

To encapsulate a user story we use Trello cards. Everyone collaborates on a card to agree scope and determine effort. Acceptance criteria on each card form the basis for our behaviour driven development (BDD) tests (we use SpecBDD, phpspec2 and behat):

Time tracking made fun with Harvest

For Agile, all sprint time must be tracked against a user story: designers, developers and testers alike, there is very little exception. As we all know, if you want to track time accurately (and don’t kid yourself, you need to), it can be a painful process getting staff to fill in time sheets (don’t do it!) so you need to make damn sure the tools you use don’t interfere with their all important productivity and that they are easily able to track all their time against a user story.

To track the all important effort spent Vs. estimated we use Harvest app. Quite simply, Harvest equals pain free time tracking: there are so many ‘add-ons’, employees have no problem finding one that works for them with minimal fuss. I’m not about to tell them which add-on to use so long as they find one that suits (note: you can track time directly from Trello cards using the Chrome extension meaning you don’t even need to leave the card (user story) you are working on.

Our sprints are one week long (Monday to Friday roughly 100 hours) and Harvest is perfect for reporting because all views are by default 1 week. Therefore, I can get my hands on studio productivity and financials without any effort at all. I get studio utilisation, billable hours (we bill per sprint) and as all times are recorded against the user stories I can immediately compare actual time spent on a user story Vs. the original estimate which is most useful for the sprint review when we discuss what we can improve.

But there is a missing link in all of this. We love Trello and we love Harvest but we need them to love each other: I don’t want to duplicate effort by having to input the same user stories into both. We need something that joins the dots…

The missing link is Zapier!

Enter stage left Zapier. Zapier does what it says on the tin, it ‘makes it easy to sync data between web apps.’ We set up a ‘Zap’ (a link between two API’s) which automatically creates a task (user story) in a Harvest project when a Trello card (user story) is moved from the product backlog to the sprintboard in the Monday morning sprint workshop.

Tools worth consideration

  • Pivitol tracker: this is the favourite of our friends at Browser London
  • Board Trail: Looks like a great way to track time from Trello
  • ScrumDo: This looks good because it doesn’t try to tackle everything, it’s lightweight and concentrates on the elements you care about. In their words it’s ‘not an enterprise behemoth with Scrum as an afterthought’ (see Atlassian’s JIRA GreenHopper notes below).

The tools we tried and failed with

I’d like to preface this with a note: just because these didn’t work for us doesn’t mean they aren’t good tools. Whatever anyone says, there is no standard way of doing Agile (which is where I disagree with Scrum evangelists): Agile isn’t about following any single doctrine, it’s about being flexible and be willing to try, fail and try again so you may well find what wasn’t useful for us fits neatly into your process.

Active Collab: We used Active Collab for years (we trialled basecamp before) but to cut a long story short it didn’t cut the mustard and frustrated everyone in the end. It was almost impossible not to think of projects in a Waterfall style (a project consisting of milestones, tasks, subtasks requiring the whole project to be planned in it’s entirety up front) and it became an albatross around our neck. Its planning module was poor and the interface style clunky. We ended up with lots of open projects 75% complete even though we’d moved onto new projects – more an archive of invalid assumptions made at the start of the project than anything else. There’s no ability to affect workflow, just a set of milestones / tasks and checklists, OK if you’re a project manager who likes to tell people what to do and when to do it by but terrible in an Agile environment where fluidity is needed. What’s more, our developers hated it and ended up ignoring the notifications, probably because no one really wants to be told what to do via automated, faceless email notifications which in my opinion is a failure in lots of these project management systems.

Team Gantt: Team Gantt does what it says on the tin: it’s a web-based gantt chart scheduler. We trialled this software to help us manage the overall studio schedule and allocate studio resource. However, there were three fundamental issues. Firstly, it created division between developers and project manager because it’s primarily a scheduling tool (which developers – rightly – didn’t care about). Secondly, it created duplication of effort resulting in inefficiencies because user stories were planned and then replicated in Team Gantt. The project manager was then constantly playing catch up with current progress constantly having to adjust based on feedback from developers even through developers had already adjusted their plan. Finally and most importantly, a gantt chart is fundamentally Waterfall. Yes, it can be adjusted but a gantt chart craves absoluteness: people who create them plot cradle to grave project plans with absolutely fixed scope and once the scoped is fixed in a chart it becomes a must have item in the delivery. Agile this is not.

Atlassian JIRA with the GreenHopper add on: We fell into the trap of comparing the features against our wish list and thinking we’d found the holy grail. It ticked all the boxes in theory. But in practice the Agile add-on is pretty clumsy and the whole application smells of early 2000’s user experience. It’s clunky and clumsy and within 2 days of using it the entire team were ignoring it and pasting user stories into their personal Trello boards. It just feels like a behemoth bug tracking tool with an Agile module shoe-horned in.