XPMan Introduction to Kanban

Tonight I facilitated an intro to Kanban at XPMan.  This was to run through what Kanban is, and introduce the 5 core properties of Kanban.

The slides for the presentation/discussion points contained the following:

  1. Visualising workflow
  2. Limit WIP
  3. Measure & Manage Flow
  4. Make Process Policies Explicit
  5. Use Models to Evaluate Improvement Opportunities

We didn’t cover everything in Kanban, but hopefully people got an idea of what it is and how they can start using it.

I’d like to re-emphasis that you should apply it to your current process – it doesn’t replace what you do currently it just overlays it.  Look at the stats that you get out of it, and let them drive your incremental change

Links:
Kanban Dev mailing group
Limited WIP Society, Manchester
Kanban 101
Limited WIP society

Books:
Kanban – written by David Anderson the “creator” of Kanban for software development.
Personal Kanban – how to apply Kanban to yourself!
Scrumban – applying Kanban with SCRUM
The Goal – need I say anything?

XPManchester:
XPManchester blog
XPManchester group

Thanks to everyone who turned up and joined in.  Hopefully provoked some interesting conversations and more importantly gave you some ideas to take away.

Collective Code Ownership

I recently asked the following question – What does good team code ownership look like?

  • Everyone adding (good) test coverage
  • Discussing the code
  • Design strategy
  • Adhere to code standards
  • Tool box of patterns

Everyone adding (good) test coverage

This is especially important, tests make everyone feel secure when making changes to the code base.  Everyone in the team must know the benefits of tests, so must maintain them and add other good tests.

Discussing the Code

The code is essentially a living entity, i.e. we add functionality, we have to look after it, it is often sick!  So it’s important that the team talks about the code base.  This is powerful because it gives people are deeper understanding of the code base.

Design strategy

A way to improve the design – most code bases have areas that don’t give us the necessary ways to change the code, or they are hard to test.  So they need to be refactored & improved upon.  We are currently doing this with our UI – using MVP.

Adhere to code standards

Currently we don’t have any standards, however, I do think we have a good code style.  This is mainly garnered from Uncle Bob’s clean code videos – which are excellent by the way – you should watch them if you’ve not (or read his book Clean Code)!

Toolbox of Patterns

You’ve got to be able to change the code, this becomes linked to discussing the code.  Patterns can help with discussing the code…  Having a design strategy – links to this!

This is not a comprehensive list but it’s a good start…

Remember:
“It’s important not to own code you’ve written in a code base; however it’s important that people respect the way the code was written”