King & McGaw Developers

We decided to try out kanban/agile for the development of our new Kubrick platform. None of the team had much experience with agile and we all agreed from the beginning that we didn’t want to take a strict approach to it, but would like to try it out and see how it fits with us. This is what we ended up with.

The board

Our board has columns for Icebox (someday), backlog (someday soon), todo (next two weeks), in progress (now), QA (done but needs review) and done.

We use actual, real post-its. This has numerous positive side-effects: visibility of progress throughout the office, avoiding more software (we’re big Basecamp users here at Easyart), and taking pride in the “done” list. The negative aspects of this: no visibility on progress outside of the office (we have offices in London and Newhaven, and some staff working from home), no ability to comment or add details to the task and of course the questionable legibility of my handwriting.

Action tickets are either small (pink, ¼ day) or medium (yellow ½ day) tasks. Anything longer than that needs to be broken down or to become a discovery ticket. Discovery tickets (green, no time allocated) help us keep an eye on the more mysterious parts of the project, or various technologies, refactors or improvements that could be useful for us. They can usually be broken down either by workshopping the specific issue, or by spending 2 or so hours researching. Mostly they will spawn new action tickets, but sometimes the discovery is a dead-end.

Processes

We do daily stand ups at 9:15. We actually drag the whiteboard into the meeting room every day to have our stand-ups. I tend to waffle on, so these can sometimes run longer than 5 mins, but we do try to keep them short. These only happen Wed-Fri (which I’ll make the subject of another post).

No locked-in sprints. Being flexible about the amount of work in a sprint is very un-Agile and makes it difficult to measure the overall velocity and predict milestones, but so far that hasn’t been a massive issue.

Pair programming. This has been invaluable for us, both to increase our skills and share knowledge.

Weekly wraps. Stakeholders are invited to a recurring meeting every Friday at 4, where we demo the week’s progress. This is useful both for the team (who might not have been involved in each others' work) and the stakeholders (to get a clear sense of progress). It’s also usually paired with a well-earned beer and move the “done” tickets to the wall.

No user stories. Without user stories our process can hardly be called “agile”, but as we’re so far building a platform with no external customers we’re yet to find a place for user stories. I think in time we will.

What we still have to work out

Where does design and creative fit in?. I’ve found it challenging to work with design creative tasks within this process. Tasks like “design hero module for homepage” or “include links to related categories on product page” are fine, but we keep finding ourselves with tasks like “refactor homepage”, which is not very useful. So far I’m yet to find a compelling model for including design tasks in the agile workflow.