Full utilization is not effective, not efficient, and causes delays
Being busy all the time is bad for you, your team, and your organization. It is far better to allow for slack, which is not a bad thing, but creates opportunities for improvement without needing to schedule them.
“Recipe” for what to work on next, incorporating slack:
- Can you help progress an existing kanban? (planned, started work)
Work on that.
- Can’t do that?
Find bottleneck and work to release it.
- Can’t do that either?
Do work which
- won’t create any work downstream,
- will improve future throughput, and
- can be paused as soon as existing kanban related work is available.
A bit more reading related to slack.
Denne artikkelen ble først lagt ut på blogg.bouvet.no.
Det finnes mange ulike beskrivelser av Kanban. Er du interessert i å vite litt mer om hva det egentlig er?
At LKNA13 in Chicago this year I listened to @JoshuaKerievsky talk about #techsafety.
He made me think about quite a few aspects of safety and injuries for a programmer. Here’s a few quotes and elements:
- safety on team (ref own dev competence)
- «working with CVS is hurting my soul.»
- safe from uncertain work situation
- safe to deploy – bugs, crash
- safe from pressure – politics, policies
- Emotional Injuries: Schedule Stress, Lost Respect, Fear of Failure, Torn Trust, etc
What’s interesting is his claim that having #techsafety as a primary value would be profitable and produce outstanding results. I think I buy into that, even if he hasn’t had time to prove it yet with his own company, @IndustrialLogic.
A few twitter notes from the session.
Edit: Joshua wrote a blogpost on #techsafety himself: http://www.industriallogic.com/blog/techsafety/