A kanban experiment with a feature development team

The what and the why

The team I am Scrum Master on at Aconex, Extensions,  has been moving further away from Scrum 101, and towards a version of Kanban over the last few sprints. We have also inherited a new Product Owner/BA and this led me to decide to attempt to document our process.

I say attempt, because the longer it takes me to document, the less like the process the document becomes, not because I am rubbish at documenting, but because our process evolves constantly (as it should)

But, I’ll give it a go anyway, and in the process, there should at least be some truths in what I record, as well as an insight to someone new to the Agile process/experience.

What is “Extensions”

Extensions is a agile development team within Aconex that deals primarily with the add on modules to the main Aconex application.  The team consists of Product Owner, Java engineers, UI engineers as well as QA engineers.

Over the last few sprints, the Extensions team have noticed a lot more issues from Triage entering our sprint backlog. This has made maintaining a fix prioritized backlog impossible. As one of the tenets of scrum suggest you need certainty in your backlog to be able to make commitments, we have decided to trial a version of Lean/Kanban instead.

The essentials

• We aim to have our focus is on the ‘release’ rather than the sprint.
• Kanban has lane limits (Limited WIP),
• disconnects planning from sprint cycles,
• encourages ‘just in time’ planning
• Records ‘cycle time’ as a preferred metric to measure team performance and help enable better planning

Kanban story board (Current)

Backlog	In Analysis	Ready for Development	In Development	Ready 4 QA	in QA	Done
(4)	4	4	4	3

Column name: Backlog

Column WIP (Work In Progress) limit: 4

The product owner can have up to 4 items in the on-board backlog. This backlog represents the ‘next’ highest priority items in the backlog. When the number of items in this column drops below 4, the product owner places more items in here. It is generally up to me to nag the product owner to keep this lane full. It is also a clear indicator to the product owner to get some stories ready for development.

The product owner should endeavour where possible to have done ‘some’ preparation before cards enter this column, such as, break stories down as much as they are capable, basic scenarios written. However, they should ensure they do just enough, just in time, as any effort on cards that get pulled is essentially waste.

Stories in this column are not yet estimated.

-          Stories in here could be epics.

-          Stories may or may not have Scenarios written

In analysis (Overlay responsibilities)

Column WIP limit: 4

This is essentially the column that replaces ‘planning sessions’. Cards are pulled into Analysis by free team members, QA’s, Engineers etc. This is to perform a number of tasks which we have specified as ‘exit criteria’ for this lane.

Exit criteria:

-          Story size is okay (i.e. is it too big, does it need to be broken down, is it an epic)

-          Sceanarios are complete

-          Technical analysis is complete/design decisions communicated with rest of team

-          Story is estimated (1,2,3,5,8 etc)

Ready for Development

Column WIP limit: 4

This is essentially a holding place/buffer for stories moving through the system. We haven’t actually decided if we use it very well yet. Cards tend to be pulled directly from ‘In Analysis’ to ‘In Development. This lane may become useful if we start to get our QA resources/BA’s focusing down (or upstream) from their main areas of focus. They could well work on cards in the Analysis section and once completed all the exit criteria, move them to the “Ready for Development” queue, creating some buffer of cards for the Engineers.

In Development

Column WIP limit (1 more than number of available pairs on team)

As the name suggests, this lane is for work in Development. We have a lane limit here for a number of reasons. The limit should not be higher than the number of people able to engage cards here. This prevents people be split across cards, and thus dividing their focus. Also you may reduce the lane limit to smaller than available team to encourage other behavior such as pairing/looking beyond their areas of focus(i.e. helping with QA) etc.

Ready for QA (Overlay responsibilities)

Column WIP Limit: 3

Another Buffer zone, lane limit here is important to ensure we keep an eye on cards building up for testing. The limit should reflect number of resources available for testing, or to encourage other team members (not specialist QA’s) to support the testing effort. If an engineer wants to move a card into this column, and it is at its limit, they need to relieve the bottleneck before they can. This means, they need to pick up a card and place it into the QA column with their avatar on it to create a space.

In QA (Overlay responsibilities)

Column WIP Limit: None

QA of feature, this column isn’t seen as the sole domain of the QA engineers. As the closest lane to the done column, this should be the highest focus of the team. Items left languishing in Ready for QA, or in QA represent wasted opportunity getting product to market.

Other notes

Daily routine

Stand ups – preferably first thing (we do ours at 9.15)

Walk the board

Stand ups are done as 'walk the board', were the team discuss each card specifically, rather than the 3 questions. We start from the Done column and move Right to left in order. Anyone with anything to contribute on the card does so. We also have a ‘parking lot’ for discussions on new cards, other matters.

Kaizen/Parking lot

This essentially means continuous improvement, we have a parking lot for improvement suggestions on our board. People can recommend improvements to the process in here, as well as introduce cards/stories for discussion after the main stand up is completed.

Kaizen is something borrowed from Toyota. Essentially in scrum this is generally something that happens during the Retro, where issues with the sprint are discussed and put into practice for the next sprint.

Just in Time planning – during release cycle

We plan when we need more stories, we have set a lane limit of 4 on our backlog column. This acts both as a limit to the number of stories that can be placed in the immediate backlog, but also as a signal to the Product owner. If there are less than 4 stories in that lane, the product owner needs to look at the next highest priority story and get it onto that lane. This ensures that the stories in the backlog are always the highest priority