Inception

New Gig

Having come into the team around 3 months ago, I've been listening to people's experiences from previous releases and also making my own observations of the way we make decisions and communicate.

There are a few things I've picked up from that:

1. Business people are asking for visibility/control of maintenance work
2. Maintenance work is not prioritised
3. Juggling priorities (project/maintenance) is difficult for some of us
4. I feel we're working on too much at once and could be more focussed

Where I looked for inspiration

My previous 13 years have been either scrum-centric or XP-centric (i.e. iteration management).

My initial temptation was to simply re-introduce scrum and I was having a think about which bits to introduce, how to make work visible to the team and other stakeholders etc.

I was trying to think of ways to avoid the resistance to change I've experienced in the past with scrum. I was also reflecting on my experiences of scrum and realising that it often didn't fix the "too much going on" issue.

Feeling a little ignorant, I started looking around for wisdom and inspiration:

• I asked the team what they thought
• We have a great UX team, I chatted with them
• We have some cool project walls around, so I asked other PMs
• I phoned a friend

Trigger point

I had heard about Kanban a few times, but never had a chance to read much about it.

In August, I went along to the Agile Sydney meetup, where Jason Yip gave a very informative presentation about Kanban.

I immediately liked it, in particular because:

• It's minimalistic and non-prescriptive
• It's simple and easy to introduce
• It seems to directly address the "too much work" issue
• It appears to be compatible with the other practices in our team
• I liked the WIP/done concept for our wall

Over the next couple of days as I started to spout on about it, our lead developer mentioned he'd proposed Kanban in the past and is also keen.

He gave me a paper copy of "Kanban and Scrum - making the most of both" (which is also available free online. I read it overnight and was keen, so we decided to give it a go.

Before we started

Duration, funding and reputation

The current project team and application have been running for around a year.

It is seen as successful within the organisation and has exceeded its business targets, which are largely around the ability to avoid further increases in call centre volumes whilst providing self-service for customers who prefer to work online.

Funding and delivery have been in in 3 to 4 month blocks.  We generally release every few weeks with something significant.

Stakeholders

We do our own testing with end users and our internal stakeholders are distributed around the country.

There is no one person who has authority to make business decisions, particularly when it comes to cross-divisional sales or pricing impacts. Despite this, we generally don't struggle with roadblocks too much.

Our primary business sponsor is the COO of our division and sits next to us.

Processes and team

From a software engineering point of view the team is mature, with continuous integration, automated unit tests with reasonable coverage, some automated functional tests for acceptance / releases and so on.

The team is very cohesive and positive, with a couple of people swapping between roles quite often (e.g. swap to manage testing after doing requirements or design). To date the developers have been lead by a development lead, who assigns work and makes technical design decisions within the core web space.

We have traditional round-robin daily stand-ups for intra-team communication and to identify roadblocks.

While some previous releases have worked to a scrum-like hearbeat, this has not been the case for a few months.

How work is managed

In short, project work is structured and all other work is ad-hoc.

Work comes into the team in a variety of ways. Some work is dictated by funding scope (e.g. new features promised as deliverables).

Other work is related to running the platform and tends to come in via phone calls and emails to various team members.

Finally there is a long wish list in Jira that holds anything anyone has ever suggested we look at, in terms of ongoing improvements, problems, ideas and so on.