just checked the time zones and it should be around 02:30 your time, while I'm in Stockholm, Sweden cruising through the morning (0930).
I thought I'd introduce myself and pose a first question/answer that I think that many of you are asking yourself.
My name is Marcus Hammarberg (@marcusoftnet on twitter and http://www.marcusoft.net for blog). I'm a software developer that about 8-9 years ago got more and more interested in how we can work more effective together as a team. I struck me one day that my typing speed probably not is the main constraint on the speed that we deliver software. It had to be something else... So I've looked deep into agile methods such as XP and Scrum, and now lately Kanban. I'm a very practical person and hence have looked into the practices that makes agile tick; TDD, Specification by example, Continuous integration, Continuous Delivery etc.
I'm married to Elin and have three boys. We're moving to Indonesia in a month (waiting for visa right now): http://www.marcusoft.net/2013/06/moving-to-indonesia.html
Ok - let's talk about something more interesting; what is kanban?
The thing that fascinates me about kanban is that it's a meta process. You like: a process for processes. It helps you and your team to improve little by little towards a future that is better than you even thought you could be. And it works every time.
That's a very cocky statement but I'm confident that it will happen. You know why? Because it's y'all (see, getting a hang of it ) that will make the improvements. Kanban can just point you in the right direction. Kanban is like a shrink for your process that way; it helps YOU to improve YOUR process.
In it's core kanban is really just three simple principles that guides you on your improvement journey:
- Make work visible; this simply means that you should strive to make your process and the work in it as visible as possible. You cannot improve what you cannot see. Make it big and in your face for you and people around you. A big board that shows the state of your process with a sticky that represent the work items you are working with is a great start.
- Limit work in process (WIP); by setting a limit for how many items you work with at a the same time you are also creating a tension in the system. That's a Good Thing (tm) because that will reveal points in our process that we can improve. Note that Limit WIP doesn't say: "Strive for a WIP of one". Limiting WIP is a tool that you can use to adjust how many improvement opportunities (also known as problems ) you want to reveal and in which tempo.
- Help work to flow through your process; by focusing on flowing the work through our entire time as fast, smooth and interruption free as possible we are also focusing on lowering the lead time of our process. This is great because that will give us feedback faster which in turn helps us learn about what worked, how our process operates and what our customer think about our product. It goes without saying that helping the work to flow can be done in a myriad of ways. Let's talk about them.
That was a very short introduction to kanban. The main thing to remember is that it's a meta process, a process for improvement processes, a shrink for your process. You can start using it today and start improving tomorrow.
I'm looking forward to spending a day with the good Code Ranch people.
See you around!
Hope this helps
Thank you for the jump start. I'm wondering though about the practicality of kanban for people who are working on more than one team.
From what I've read, it seems the general scenarios is that there's one board for a project and everyone involved is focused on the project. How does that work for someone who's on two or three projects as far as limiting WiP goes?
SCJP, SCJD, SCEA 5 "Any sufficiently analyzed magic is indistinguishable from science!" Agatha Heterodyne (Girl Genius)