Agile development has been a breath of fresh air in all our developments recently; it has helped us tackle a number of traditional development problems:
- we get working code to clients quickly so they can visualize the solution,
- we can work with people track and understand the cost of change and scope creep,
- and it gives our teams clear insight into where and what’s happening.
At any one time there can be a number of projects going on, and not everyone has space on the walls for all the post-it notes, so we use Trello to manage the projects. Trello is an online collaboration tool that lets you organise things into boards, lists and cards. It’s like a big virtual post it note wall
It’s an incredibly flexible tool, that can be used a number of ways. For project management we have used it like this:
A project board
Each project has a board. The board has everything that is going to happen on a project, at the start of a project we have the kick off meeting, in the kick-off meeting everyone who is working on the project (and preferably the client) build the project board by working through the core features of the project.
our trello board
Core and Long Grass
At this point we also capture the nice to haves; on most projects this means we have a core features and a long grass list. The core features is everything that we think (at this time) that will be needed to launch the project. The long grass is the stuff we would like to to if we get the time.
Estimates and scores
Scoring cards
During initial scoping of a project we will have gotten a feel for the length of time it’s going to take but as the project is put into the board we like to understand the time for each item.
At this point we use a chrome plugin – scrum for Trello, that allows us to add resource times to the board.
For each item we allocate a time – the rule of thumb we use is nothing in core should go over 5 – and that’s at a push. 5 hours is realistically a day’s work, and it’s not ideal if things get lost in a day.
The aim is to break the project into 2-3 hour chunks.
For the long grass list - it is different as these are often just ideas at this point. We give them a rough estimate which can be as much as a few days to a week. As we aren’t sure we will do anything from long grass we don’t waste time working out the finer detail yet.
Sprints
Projects are broken down into week long sprints, which is things we can do in one week with the team. The exact amount the team can do in a week depends on the number of people in the team – a rule of thumb 20-25 hours per team member but that depends on what other commitments your team might have.
We create sprints in a single list, this is a bit different than most because traditional agile boards will probably have backlogs, in progress and done. We keep them on a single list so the board doesn’t get too cumbersome. We then use labels to track progress.
Labels
Labels
Trello allows you to quickly assign up to 6 labels to any card. We use the labels to indicate the area of the project team the card is for (i.e. development, design, and content) and to push things through our very simple project workflow.
###
Workflow
Our simple project workflow, is assigned, ready for review, completed.
- When something is allocated to a sprint it is assigned to a member of the team,
- They then work on the card, when they finish they mark it for review
- The project owner (in the team) then reviews and marks it as complete.
The scrum plug-in has a neat feature changing the value from one with braces “(2)” to square brackets “[2]” causes it to be counted as complete. Changing the resource time on the list
Scrum / Sprint review / kick off
Once a project is in full flow we have scrum meetings throughout the week, these 10 minute meetings are to keep the project momentum going, capture any issues quickly and if need be highlight we breakout meetings need to happen.
The sprint meeting happens once a week and acts first as a sprint review of the last weeks sprint, followed by the kick off for the next week; at this point we check and close down the sprint list for one week, and create a new one for next week.
In an ideal world we get the client in for the sprint meetings, but where that’s not practical or possible one of the team assumes the role of the client and helps define what’s in the next sprint / if we are done yet.
Agile as an approach
The difference in the progress of an agile project vs traditional project is stark, and where possible we always choose to embark on agile projects, with some clients this can be difficult for a number of reasons including commissioning models and pre-conceived expectations. It’s something for another post, but we work very hard to show people how agile can work for them – because it works so well for us.