Just thought I’d share with you our implementation of Kanban work process at Lonely Planet in one of the teams we have here;

Here’s how I recently “summarised” our development process as it has evolved on Atlas 2:

This original summary was written by our lead developer, Simon Harris, and is a pretty good summary of what/how we evolved our process to. I have hacked into
his description without referencing where the change is, but I know Simon would be fine with this.

This project was failing badly and we had large numbers of card clogging our board and impeding our ability to deliver, identify constraints and generally
get on with it.

The process changes we put in place helped us very quickly focus on the immediate high-value stories and prioritise accordingly. We were also able to
observe where our constraints where and ease/remove them.

Can I also refrence this post/site:
http://leansoftwareengineering.com/ksse/scrum-ban/ which was our original introduction and starting point.
**Follows is original description with editing by me.

We’re currently running with a VERY lean approach to development which has been the result of two or so months worth of refining:
* No more than one card per pair in dev at any time
* No more than one card per pair in ready-for-dev at any time
* Nothing to be blocked; If it’s blocked we work to remove the blockage
* New cards are demand pulled into ready-for-dev as cards are moved from dev to ready-for-test
* We have big picture story card sessions as required
* We have planning meetings at the start of each iteration where we discuss what’s “planned”
* We give everything t-shirt sizes (S, M, L) – Bruce here: I than attach numbers 1,3,5 to these for my Burn Up Chart
* No technical stories; everything must be done because it delivers business value ( We are generally very good at this..)
* We don’t measure velocity – However I do measure our burn up to a date as we have this as a project constraint (Time)
* We aggressively split cards
* I repeat, we aggressively split cards
* Daily stand-ups
* Parking lot for post-stand up discussions
* Full-time pairing where possible
* We release when we have a MMF rather than around the sprint cycle. Essentially the Release Early/ Release Often. We sometimes release every 2 days if the option/opportunity arises
* We use the iteration cycle of two weeks for an opportunity to re-focus via Retros and increasingly lighter weight planning sessions.
* We try to focus on doing things as simply as possible
* We try to focus on building things correctly rather than as fast as possible
* We fight to have a REAL user available to better understand their needs
* We rally against the usual cries of “but I know we’ll need it”; We trust that by building things simply we can always add on the extra functionality later
* Trying to deliver everything to everyone leads to delivering nothing at all to anyone
* T-shirt sizes help the business prioritise not estimate delivery dates; Business value is a function of, among other things, time/ cost to build – As mentioned above – I translate the T-shirt sizes to points (1,3,5) for external reporting in the form of a burn – up chart. We use this solely to track releases.
- We have started using Cycle Time tracking to measure Start to Finish time on cards. Not really sure where this will take us, but if I remember I’ll report back on this if people are interested (Bruce T)
* Rolling technical stories into stories that deliver business value force us
to change course slowly and justify changes
* We usually have parallel implementations of some things as a consequence
* Minimal changes are allowed on “old” implementations; anything substantial requires a migration to the “new” implementation
* If we can deliver _some_ business value early by splitting the cards we do so as soon as possible; Eg. business can view existing data in the new form but editing is a new card because they can still use the old mechanism for that.
* It’s critical that the whole team is taken on the “journey” so they understand _why_ things are being built. Doing so brings the team into alignment and also allows the team to make informed decisions such as re-structuring work to enable splitting cards for aggressively.
* Bringing the team along for the journey can be painful, never gets easier, and is always worth the effort.
* Just-in-time stories really does enable the business to leave the decision as to what’s important to the last possible moment
* Implementing the smallest amount of code possible for each story is critical to enabling just-in-time development; less code == greater flexibility; E.g. don’t use a database when the data comes from a spreadsheet and presently only ever changes in a spreadsheet.
* We do as much forward thinking as possible/practical; We think of as many likely scenarios as we can and keep reducing the scope of the implementation so as not to preclude implementing them later on
* Almost nothing ends up looking as we thought it would when first envisaged.
* More important than writing the code is working out how to structure the implementation so that we get the job done without precluding possible future work; sometimes this means at least thinking through a strategy for migrating from one implementation to another later on if necessary.
* It’s amazing how splitting stories reveals just how little the businessvalue certain aspects of stories
* We almost never get through everything that was “planned”
* We almost always end up doing stories that weren’t “planned”
* At some point we hit a tipping point and development switched from a whack-a-mole game–where a change always seemed to make something else break/harder to develop–to delivering incidental benefits as a result of the normal development of stories–e.g. speed improvements that we knew needed to be addressed but hadn’t actually planned on looking into anytime soon.
* We’re motivated by getting things done; call that velocity if you will but we really haven’t found a need to measure velocity. (Caveat: Now that we have achieved good throughput, we have been using countback velocity – measuring cards completed previously, to produce a burn up when reporting to Stakeholders. However, I am hoping to use Cycle time to reducing estimation from Points on a card to “How long a card takes to get from point A to point B as a reasonable and useful measure. Not sure how that will wash with senior stakeholders outside the project team though)
* Delivering a constant stream of small but valuable stuff into production every week is VERY motivating.
* As developers we value delivering something over delivering nothing
* We actively plan for change

Caveats:
* We have a highly competent team
* We have a fixed budget
* We have internal and external users
* We have UI and data-only users