Tag Archives: קנבן

Check out a Prezi for one of my Kanban Training workshops

Estimated Reading Time: 1 minute

Want to improve effectiveness of Product Management? Here are some ideas for metrics to look at

Estimated Reading Time: 1 minute

I recently worked on some measures/metrics that help answer the question "How effective is our product management process, and how is it contributing/affecting the overall performance of our product development line"

Here are some slides from slideshare about the topic. I might write it up in a more elaborate form in the future. 

If there are specific questions about concepts I mentioned, mention it in a comment (or on twitter or something) and I might write up a specific area. 

If you have examples of dashboards showing similar measures in practice, I'd love to see!



Estimated Reading Time: 2 minutes


Our coaching team at agilesparks runs into this question a lot. 

Many of the teams we are working with are familiar with Scrum and using it. Other teams are just now going into Scrum. 
Since kanban is becoming a hot buzzword, we often get asked – so what is this kanban thing? How is it related to Scrum? 

We needed a good answer, that depends on the context, the amount of time you have to answer, and the maturity of the person/forum asking.

In this post, I will try to give the answer you give when someone finds you in an elevator, the last 2 minutes of a workshop, or on the way back from lunch, in short both you and him have a very short time to give an answer. 
Add to that that his knowledge is quite limited. 

Here goes:
"What you might have heard about kanban is that its scrum without sprints. 
I would say that Scrum is an agile approach where the container used to protect, focus and challenge the team is the time-boxed sprint. 
Kanban is another Agile approach! In Kanban the container used to protect, focus and challenge is limiting the amount of things we do in parallel – Limiting the Work in Progress. If you need to remember one thing – remember and lookup Limit the WIP"

If you are in a very high building, you can also add:
"Mixing the two can lead to beautiful results – called ScrumBan. Also one of the biggest differences is in how an Agile change usually looks like with Scrum/Kanban. Scrum is a revolutionary big change up front approach. Kanban is more of an evolutionary laser-focused approach where you find where to focus (using the WIP limit as the challenging force), do something there, continue to the next area to focus on. If you've heard of TOC, its quite similar in how it manages change. "

Now all of this is very simplistic, but probably concepts like Cycle Time, the Lean origins, and other Kanban goodies are too much for a rookie with very short attention span at the moment. 
The important thing is to grow an interest for what this WIP limit means and look it up. 

If productivity experts tell me to keep email closed most of the day – why shouldn’t I avoid looking at defects for most of the release?

Estimated Reading Time: 4 minutes

An interesting question was raised to one of our coaches at Agilesparks. 

Question: Isn't it more efficient to wait till the end of the release and then all together handle all the bugs?

One of us answered that same like you probably prefer to answer emails throughout the day rather than at the end, you want to deal with bugs during the sprints. 

I of course fully agree that you need to deal with bugs during the sprint/release, or in other words keep the Bugs In Progress number limited. (Anyone for Limited BIP society?)

But this answer doesn't convince me. 



many productivity experts (e.g. http://www.inboxoverload.com/time_management-partI.htm) will tell you to turn email off for most of the day, and open it in specific slots throughout the day, to avoid context switches, etc. This will protect your flow on the tasks you should be focused on. This is btw different between managers and makers, and is similar to how their calendars look like (see a great post by Paul Graham ). I would say that the more reactive your role is, the more responsive you probably need to be to email, and the less actual creative flow you can expect. When you do need to make something, TURN YOUR EMAIL OFF. 
I would add a caveat to this rule to say that in collaborative environments like Agile teams, care and balance need to be applied to allow both Flow to happen, as well as collaboration and fast feedback/osmosis in the team. 
Now what do we tell those makers of software, that we instruct to ignore their EMAILs for most of the day? that they need to deal with defects as soon as possible? Why?
The reason its different is that emails during the day don't really "ROT" like the vegetables in the market, do they? or at least a major part of them doesn't.  The cost of addressing an email a few hours late is not much different than addressing it a few minutes after its sent. 
Again, the caveat is those decisions others are making in our team, that they want fast feedback and collaboration on. We should find a way to allow those to come in (maybe by coming by and talking?), maybe by marking the emails from the team as higher priority, whatever. 
With defects or decisions in software development in general its different. the cost to deal with late feedback is exponentially higher as time goes by. Also, having the large inventory of those issues risks the release since you don't exactly know how long it will take you to fix all of them. 
Back to email – yes, if you keep all emails to the end of the day, you don't know exactly how much time it will take to fully address them. but you can decide whether you are scope-driven so you get to inbox zero every day (check out 0boxer btw for a nice gmail extension that makes a game out of this…), or whether you give a time-slot priority based and do what you can, and periodically deal with the overflow. 
For sure, probably reading your mailing lists (e.g. kanbandev, agile-testing) are all highly valuable, but can be described as intangible benefits to the day, so can be scoped out if necessary. Again, some of us actually see participation in the lists as a tangible ROI, but then probably the way to deal with that is put it on our schedule, think about the appropriate SLA, etc. If its important enough to answer in realtime – then by all means make kanbandev a high priority email in your inbox and let it thru. Have it SMS you, twit you, whatever. But be aware of the decisions you are making. This is similar to managing demand for a product development group…
The decision about the level of WIP and cycle time you are shooting for should be an economy-driven decision. both context switches as well as late feedback have a price, in the waste they create. you need to weigh the price and decide what is best for your context. 
The reality of product development in most of the projects out there, seems to be that its MUCH more economic to build quality in and don't let defects rot outside in the sun. 
PS If MY inbox was turned off, I would probably not see this email from my colleague and write this post. Now what would be the price if I answer him in the evening? Probably the cost of answering and dealing with the feedback would be the same. Thinking about it caused me to context switch and write this blog post. Now I usually just defer answering to such emails, and writing blog items (I use rememberthemilk.com and have various draft post ideas there that I get to at some point). If I was perfect, my algorithm for when to answer and when to defer would really be economically sound. Since I'm not, it's probably more about enjoying the moment and the journey. Which is something this colleague of mine especially appreciates 🙂 you know who you are!

Encouraging Feature-level progress tracking in Kanban

Estimated Reading Time: 4 minutes








What are the gaps?











