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



Comments

Post a Comment

Popular posts from this blog

Experience report: Building an offshore agile team in India - The Australian perspective - Part 1

Experience report: Offshore agile teams – An Australian in India’s perspective Offshoring software development, in this case, using agile as a software development methodology contains many opportunities to learn. These kinds of teams have specialised requirements both in the technical realm as well as social expectations on the individuals hired. A lot of organisations have tried, and failed in a lot of cases, to set up independent agile teams in India . With the right approaches and expectations set, Aconex has shown that it is possible to successfully set up agile offshore operations as we did. To get your offshore program on a sustainable footing you’ve got to understand the market and be prepared to be responsive to local conditions. What sort of people are/were we looking for? A simple explanation would be, agile software engineers and product people with a desire to work in self managed, highly collaborative teams. We use the terms ‘passionate, self-starter, indep
Read more

Using an agile storyboard as a scale of certainty

Image
As per my previous post, In my current team we have started using a 'Just in Time' (see how I feel weird about saying Kanban, not sure why yet) approach to doing various activities around development. Mostly this is around planning, but in that sense, we are also doing as much Just inTime as possible in giving an estimate. Scene setting We are a team that does 2 week sprints, but we also don't do a major release at the end of each sprint. We tend to wait for 5 sprints to pass before we do releases, there are a number of organisational reasons for that, but suffice to say, thats the way we do it around these parts. Our story wall (in ugly table form) The table below is a basic representation of our Story wall. As you can see, for the story wall, we deliberately do not just focus on the current 2 week sprint. We also have columns heading beyond the current sprint to encapsulate the entire release timeline (in this case the team have already completed two sprints so their are
Read more

Building agile teams in India: Part 3 - challenges at the hiring stage (especially for a fresh face in the market)

Part 3: Constraints/Challenges of building a ‘boutique’ agile team in Bangalore/India (especially if you’re an unknown in the market) Low brand recognition In India, brand is seen as really important for a lot of candidates even in 'considering' an organisation. Family recognition of the organisation is seen as very important to candidates, acceptance of the organisation by candidates parents is often a key factor. There is also evidence that candidates enhance matrimonial chances by joining a known brand, I've even had conversations that dowry can be increased dependent on the name of the company.  All of this leads to an uphill challenge for smaller organisations, however: The candidates that do join you are joining because you've sold the company culture and challenge well, which increases loyalty/retention. Also, working on brand building is shown to pay off over time, hence partly an answer to the question of “Are you ready for this to take ‘x’ ye
Read more