Our first week

Our focus for the first week

In true agile fashion, we wanted to implement the basics first and then improve from there.

For the first week we ended up working on:

1. Structure of our first Kanban board
2. Rationalising the existing Jira backlog

Kanban Kolumns

As mentioned in Inception, we had a copy of "Kanban and Scrum - making the most of both".

We picked up that v1.0 of our board would be transient, so we tried to avoid spending too much time on it.  To start with, we copied the columns from one in the book - why reinvent the wheel?  

Real wall or electronic?

Next was a key decision; do we have a "real" board, or do we use Jira's ability to do swim lanes for each Jira state?  This took a few days.  

My initial temptation was to use Jira because we want to make the work visible to people in other offices around the country.   I'll also put my hand up and admit that after 13 years of agile experience, I'm still pretty amateur at setting up "real" walls that are maintainable.   Muchos work tended to go into maintaining consistency between the wall and various work and test tracking tools.  

We decided to go for a "real" Kanban wall in the end though.   This was based on one problem - we didn't have free reign to create new states in our Jira installation.   This is because we share with other projects.   The Jira columns are based on states and we didn't have enough already so we couldn't use it.

We scrounged around for free wall space but other teams on our floor were hogging that :)

Irish, our lead developer, suggested we go for a whiteboard with wheels, so we could move it into meeting rooms.   Genius man.   Bummer, none to be seen but we eventually spotted a couple and managed to borrow one with broken wheels and with makeshift tools The Hadster fixed it up enough to hobble along!

Putting things on the wall

I worked with The Hadster for an hour, mainly thinking about some of the work we were currently doing and how it would flow.   We got side-tracked a few times wondering if our implementation of Jira could inter-operate, but left that in the end.

The one alteration we made was to have two swim lanes to represent project work vs.  maintenance.   I figured these would have different sizes, speed and limits.   It was also important to me that we keep our funding obligation (project work) in focus at all times.

Kanban Board v1.0

Here's how it looked:

Kanban Board v1.0

WIP Limits

I arbitrarily set the WIP limits for project work.   For me, this was the driver for trying Kanban in the first place so I felt reasonably comfortable that this was a better situation than not having a limit at all.

We didn't immediately set a limit on the maintenance stream as we knew it would take a while to get all WIP represented there first.   Limits would hopefully be obvious after that.

Our first Kanban stand-up

During our first stand-up, I spent a few minutes explaining the basic idea (make work visible, limit WIP) and explained that we'd probably evolve to a stand-up that focussed more on bottlenecks etc than the round-robin update that we'd been using to date.   This was something I picked up from the book.

There were quite a few questions that came up during the session so it took a full half an hour (rather than the normal 10mins).

There were loads of questions we didn't have answers to.   I tried to focus on the things that we could see/touch/feel at the moment.   Quite a few "what if" scenarios came up, we left those unanswered for the time being.

A few things worth mentioning.

• "Noise" (work less than 2hr) would not go on the board for now
• Should we use avatars to indicate who's working on what?
• Development bugs would not go on the board for now, we would just fix them, track with Jira
• We needed to figure out how Jira fits in
• We should put Jira numbers on the cards

We discussed production and development bugs.   Until we had better metrics, I was keen to manage production bugs the same as any other "maintenance" item.   This was just a preference from experience.   In reality production bugs, if they're of a non-urgent nature, need to be evaluated against everything else in the pipeline, so I don't see the point in labelling them as different, at least for now.   Development bugs on the other hand are relating to code that's fresh in everyone's mind, so the overhead of "just fixing" is low in comparison with the overhead of managing / prioritising them - something I picked up from a good developer on a previous job.   Our releases are reasonably frequent, so we dont' get a huge backlog of bugs that require this sort of overhead.

Making it work with Jira and Greenhopper

It was obvious we needed to get a clear connection between Jira (where the wish-list of work items pre-existed) and the board.  

We were keen to find a way that didn't require a significant amount of dual maintenance.

This took us quite a while, because we are limited in what we can change in our internal installation of Jira.  

An example: We wanted to call our Jira types "project", "maintenance" and "development bug".   But we share a Jira installation with other projects and there's a desire not to muddy everyone's list with items that only our project uses, which is fair enough.  It's causing a bit of confusions at the moment because people are creating new "maintenance" tasks as the Jira "new feature" type - which is the one we're using for "project".   Just because they're new items doesn't mean they're project work of course.   Bummer, we'll get there!

After a couple of days looking through (and trying to rationalise) the list of items in Jira, we came up with an approach as summarised in this diagram:

Jira states in relation to the board.

In summary, here's how it works for now..

1. Jira "open" means not yet on the board (backlog)
2. When an item moves into the board's "queue" column, we set it to "in progress"
3. When development/unitTest is done, Jira's state moves to "resolved"

This way we're hoping to minimise the number of state changes we do in Jira when post-its move on the board - while still maintaining consistency between the two.

We're hoping this will make is easy for people in other offices to easily tell what's on the board (because it's in a state other than "open").

How did Kanban help?

As soon as we started discussing the idea of Kanban, particularly the limited WIP part, we started to change our mindset.  

The Cool and I had an easy conversation about his focus for UX - which was currently across many many things in Jira even though they weren't actually "in progress" yet from a development standpoint.   Because those things were not on the board, he could relax a little and focus on a smaller number of things.  This was a relief for him.  

As soon as we had v1.0 of the board up, it was immediately obvious to the whole team that we had some problems other problems too.   You can see that there is a big void in a couple of places.

The first void is between current project work and what what's in test.   This means we're going to run out of project work to start development work if we don't get a hurry on.   So we know where to focus our energy/priority/focus for a few weeks there.

The second, which compounds the first, is that there's a void of maintenance work "ready for development" i.e.  in the "pre-dev" "done" column.  

What's been happening up until now is that the development team would work on technical tasks like refactoring and specific features like purge jobs.   I could see that I needed to deal with this as my most urgent priority, to make sure we also had real business improvement tasks added to the stack.

All in all, a hectic week trying to get ready for a release next week and at the same time get our heads around a new way of working.

What I would say in closing is from a personal perspective...

It was much less strain on the team this week to introduce (the two basic ideas of) Kanban - than it has ever been for me to introduce the Scrum methodology.   I'm not dissing Scrum; we're still using many aspects of Scrum, but that ability to introduce something very simple yet very effective has been "heaps good", as the kids say down under :)

..  ( transmission ends ) ..