Inevitably Agile

somethings are just inevitable …

Kanban

A couple of weeks ago I read up on Lean and so got introduced to a new buzz word/concept, kanban.

This loosely translated means “visual card”, which leads us straight to the core concepts of kanban:

  • Make work visible
  • Limit work in progress
  • Help work to flow

If you’re familiar with scrum, the biggest differences to me are:

  1. No iterations
  2. Stand Ups are board-orientated – focus on bottlenecks, rather than people and tasks
  3. Less rules – hence less confusion around not implementing it correctly
  4. The board looks similar to a scrum board but has a kanban limit imposed on each column (this is the important bit!)

These sights provide EXCELLENT guidance if you’d like to learn some more about kanban:

Personally I think kanban is a better way for most companies to work… and those that are disciplined enough can then transition into scrum. But that’s just an opinion 🙂

I think kanban can benefit my existing employers on my current project.

Why? Because we cannot commit to a 2 week iteration or even a 1- week iteration, there is too much change that happens (and is allowed to happen – this is how the business works). Also – along with new projects, there is a fair amount of QA and production support that needs to happen. The team works across all projects, including the support needed. Often the bottlenecks are getting a test environment up and running, testing the front end, performance testing.

As you can imagine, the bottlenecks are often not attended to and then don’t get done properly. Code reviews, adherence to coding guidelines (standards) are also not conducted.

At the moment the current thought is – when dev is done we’re 90% complete, with the remaining 10% being testing. That’s just not good enough – or true. When our dev is done – we’re actually about 60% there, the 40% remaining, is testing and integration, and this needs time and people allocated to it to be done.  Thorough testing (UI/integration/performance etc) on a large complex system takes time – hence the 40%, and on this project it is not catered for.

Also – we tend to lose track of who is working on what and where, as the boards/monitoring etc are all project focused and not team focused.

I think kanban will assist with this.

How? One board with all projects on it and people can only work on one task at a time –this allows everyone to see who is busy with what and when they expect to be done. The “to-do” column allows analysts/product owners/project managers to decide on which projects task is highest priority. The limit on columns will get the team members to assist with creating test packs/ test environment etc much sooner in the process. After all – you cant work on a new item if you have hit your limit in that column!

Like I said – just some thoughts … 🙂 about what I love … teams and process and LOVING what you do.

Advertisements

One response to “Kanban

  1. Pingback: A kanban presentation « Inevitable

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: