I went to a Kanban event where we discussed some of the principles of kanban while putting together a "Tower of Kanban".
I can't remember if I've spoken about it before, but kanban started out in the automotive industry as a way to implement "just-in-time" or "lean manufacturing". The idea is that you only ever have what your pipeline can handle. There's no point having a machine that can pump out 100 tyres per hour if your downstream assembly system can only handle 50 per hour. Sure, the tyre making machine isn't being 100% effective, but there's a cost to stockpiling a heap of tyres in the factory, waiting to be used. Plus, you may end up making far too many tyres, that aren't needed when you switch to a new model, so you've also wasted time and money.
It's a principle that has been adopted by the software development community, but the idea can really be used in a wide variety of industries.
In software development, the typical flow goes like this:
- Business analyst gathers requirements to work out what needs to be done
- Developer makes it happen
- Tester makes sure the change does what it's meant to do and nothing else broke as a result
- New feature gets shipped
However, it's quite rare for there to be the perfect balance of incoming requirements, development velocity and test velocity. So you may have a huge backlog of requirements awaiting development, or a ton of features that are ready for testing with nobody free to test it.
Because software is not tangible, it can be difficult to see where bottlenecks are happening. One of the practices you see on the tower in today's picture is "visualize", and a lot of teams have what's called a kanban board (which is funny because kanban means billboard / sign board in Japanese, so billboard board seems a bit redundant).
Each piece of work is represented by a card, and you have different columns representing the status of that card, e.g. backlog, in dev, in test, done. By having each piece of work represented visually, you can see where most of the cards are sitting.
Another of the principles is limit WIP (work-in-progress). Though it may seem counter-intuitive, assigning yourself to less things lets you get more done. There is a cost associated with changing from one task to another task, so if you have too many tasks going on at the same time, the cost of all that context-switching may end up being more than the cost of the time spent actually working.
Sort of related, one person talked about how they realised they were spending a lot of time analysing and estimating upcoming work. It was actually eating up 30% of their work time doing this analysis, which would often result in lots of scrapped ideas. They found that 95% of their estimates were pretty much the same anyway, so the manager decided that whenever someone asked for an estimate, the team would just respond with that default number. Even though sometimes the default number would underestimate the task, the amount of time they saved not doing extra estimation work made up for the underestimation.
A couple of other things I picked up from the night:
One team tried putting a WIP limit on their backlog. If the backlog was at the limit, and the stakeholder wanted something added, then something else would go into the bin. He found that when stakeholders had to start to prioritise their suggestions like that, they had a huge reduction in the number of willy-nilly suggestions, and an increase in the number of suggestions that actually made it through the entire workflow into becoming an actual feature.
A few people talked about some of the frustrations in having these tech debt-style tasks build up - ones that you know you should do, because it would make your life easier, but doesn't have any actual business benefit, so your stakeholders don't see the value in it. The developers become frustrated, because they may have a lengthy workaround in place because they don't have time to fix something properly. At Kogan, they have what they call "Ship Frenzy", where they are asked to ship as many stories in that period as possible. What ends up happening is that developers will find a lot of small tasks, which tend to be these tech debt tasks, and get them done. Because they know they only have a short period of time to do this, they become a lot more focused, and they also become happier because they finally have the chance to do these annoying little things.
The whole kanban concept is something I keep trying to integrate into my life. I have so many projects that I want to do, but I think I end up thrashing a lot, and end up doing nothing, until something comes along to kick me into action. Such as yet another person leaving my team, which has prompted me to make another video.
Tomorrow, I plan to put together my Trello board for all these little projects I have, and see if I end up getting more done when I try and apply those Kanban principles.
If you'd like to read more about kanban, here's a link the organiser recommended: http://leankanban.com/guide/
-------------------------------
Been a while since I've had one of these. I've been pre-writing a lot of posts so I can go out at night without worry about meeting a deadline, but it does tend to mess up my Tuesday measurement posts, as I won't have the measurements until Tuesday, and I forget to edit my pre-written post.
Today is the end of week 9:
Weight: 58.4 / 59.1 / 58.9 / 58.6 / 58.3 / 58.5 / 58.5 / 59.1 / 58.7 / 57.4
Waist: 74.5 / 75.5 / 75.5 / 74.5 / 73 / 75 / 73 / 75.5 / 75 / 73.5
Hips: 88 / 89 / 90.5 / 88.5 / 88.5 / 90 / 87.5 / 89 / 89 / 88
Bust: 89.5 / 91 / 89.5 / 90 / 89.5 / 92 / 91.5 / 90 / 92 / 90
Left thigh: 52.5 / 51.5 / 53 / 52.5 / 52 / 53 / 53.5 / 53 / 53 / 52.5
Left calf: 35.5 / 35.5 / 37 / 35.5 / 35 / 34.5 / 34.5 / 37 / 35.5 / 35
Right thigh: 53.5 / 53.5 / 54 / 53 / 54 / 54 / 53.5 / 54 / 53.5 / 53.5
Right calf: 36.5 / 36 / 36.5 / 35 / 36 / 35.5 / 35.5 / 37 / 36 / 35.5
Left bicep: 31 / 29 / 29 / 29 / 30 / 28 / 28 / 28.5 / 30 / 29
Right bicep: 30 / 29 / 30.5 / 30.5 / 32 / 29.5 / 29.5 / 30.5 / 31.5 / 30
Sort of related, one person talked about how they realised they were spending a lot of time analysing and estimating upcoming work. It was actually eating up 30% of their work time doing this analysis, which would often result in lots of scrapped ideas. They found that 95% of their estimates were pretty much the same anyway, so the manager decided that whenever someone asked for an estimate, the team would just respond with that default number. Even though sometimes the default number would underestimate the task, the amount of time they saved not doing extra estimation work made up for the underestimation.
A couple of other things I picked up from the night:
One team tried putting a WIP limit on their backlog. If the backlog was at the limit, and the stakeholder wanted something added, then something else would go into the bin. He found that when stakeholders had to start to prioritise their suggestions like that, they had a huge reduction in the number of willy-nilly suggestions, and an increase in the number of suggestions that actually made it through the entire workflow into becoming an actual feature.
A few people talked about some of the frustrations in having these tech debt-style tasks build up - ones that you know you should do, because it would make your life easier, but doesn't have any actual business benefit, so your stakeholders don't see the value in it. The developers become frustrated, because they may have a lengthy workaround in place because they don't have time to fix something properly. At Kogan, they have what they call "Ship Frenzy", where they are asked to ship as many stories in that period as possible. What ends up happening is that developers will find a lot of small tasks, which tend to be these tech debt tasks, and get them done. Because they know they only have a short period of time to do this, they become a lot more focused, and they also become happier because they finally have the chance to do these annoying little things.
The whole kanban concept is something I keep trying to integrate into my life. I have so many projects that I want to do, but I think I end up thrashing a lot, and end up doing nothing, until something comes along to kick me into action. Such as yet another person leaving my team, which has prompted me to make another video.
Tomorrow, I plan to put together my Trello board for all these little projects I have, and see if I end up getting more done when I try and apply those Kanban principles.
If you'd like to read more about kanban, here's a link the organiser recommended: http://leankanban.com/guide/
-------------------------------
Been a while since I've had one of these. I've been pre-writing a lot of posts so I can go out at night without worry about meeting a deadline, but it does tend to mess up my Tuesday measurement posts, as I won't have the measurements until Tuesday, and I forget to edit my pre-written post.
Today is the end of week 9:
Weight: 58.4 / 59.1 / 58.9 / 58.6 / 58.3 / 58.5 / 58.5 / 59.1 / 58.7 / 57.4
Waist: 74.5 / 75.5 / 75.5 / 74.5 / 73 / 75 / 73 / 75.5 / 75 / 73.5
Hips: 88 / 89 / 90.5 / 88.5 / 88.5 / 90 / 87.5 / 89 / 89 / 88
Bust: 89.5 / 91 / 89.5 / 90 / 89.5 / 92 / 91.5 / 90 / 92 / 90
Left thigh: 52.5 / 51.5 / 53 / 52.5 / 52 / 53 / 53.5 / 53 / 53 / 52.5
Left calf: 35.5 / 35.5 / 37 / 35.5 / 35 / 34.5 / 34.5 / 37 / 35.5 / 35
Right thigh: 53.5 / 53.5 / 54 / 53 / 54 / 54 / 53.5 / 54 / 53.5 / 53.5
Right calf: 36.5 / 36 / 36.5 / 35 / 36 / 35.5 / 35.5 / 37 / 36 / 35.5
Left bicep: 31 / 29 / 29 / 29 / 30 / 28 / 28 / 28.5 / 30 / 29
Right bicep: 30 / 29 / 30.5 / 30.5 / 32 / 29.5 / 29.5 / 30.5 / 31.5 / 30
No comments:
Post a Comment