Kanban: The Point and Practice of Limiting Work In Progress

"A real game-changer in the long run is when we start limiting work in progress (WIP). That’s where we influence the change of behaviors. That’s where we introduce slack time. That’s where we see emergent behaviors. That’s where we enable continuous improvements.

We understand that limiting WIP is a good idea and yet realize that introducing such a practice is not easy. Is there another way?

How about focusing on these outcomes? It’s fairly simple. It’s enough to write a simple guidance. Whenever you finished work on an item first check whether there are any blockers. If there are attempt to solve them. If there aren’t any look at any unassigned items starting from the part of the board that’s closest to the done column (typically the rightmost part of the board). Then gradually go toward the beginning of value stream. Start a new item only when there’s literally nothing you can do with ongoing items."

Brodzinski, Pawel. (2015). Don't Limit Work In Progress. Software Project Management - Lean, Agile and Kanban. Retrieved on December 12, 2016 from http://brodzinski.com/2015/10/dont-limit-wip.html

Four Harmful Java Idioms

In summary, I suggest that the following idioms should be favored as the preferred style:

• Use a naming convention to distinguish three kinds of data, not two: local variables, fields, and method arguments.
• Prefer the package-by-feature style over package-by-layer.
• Prefer immutable objects over JavaBeans.
• Order items in a class in terms of decreasing scope, with private items appearing last.

O'Hanley, John. (2008). Four harmful Java idioms, and how to fix them. JAVAWORLD from IDG. Retrieved on December 22, 2016 from http://www.javaworld.com/article/2077883/java-concurrency/four-harmful-java-idioms--and-how-to-fix-them.html?page=2

Introduction to NodeJS

Get stated with NodeJS