AgileTHIS

 I have been watching several discussions over the years between brilliant people where clear perception of the problem prevented them from solving it.  It is so easy to marry ourselves with our suggestions of action (how) that we loose focus about  what the nature of the problem really was.

For cases like this, I advice teams to follow this problem solving algorithm:

1. Surface problem
2. Concretize problem  – write it down!  (what, when, how, who)
3. Find root cause
4. Surface ideas  (start with those that helps improving the existing situation)

For seeing situations like this, I try to keep the following "aha" reminders in the back of my head..

As an arguing manager, if I can’t concertize the problem it is a sign I need step back and put the right decisions into the right hands – the people closest to the problem.

As an arguing engineer, have I progressed towards engineering a solution, or even evolved into solving another problem (which I felt needed to be sorted first), before concretizing it’s nature with my counter part?

Read more…

If you’re interested in Kanban I can recommend this course in Stockholm, there are still a few spots left. If you don’t know what Kanban is you might take a look at: http://www.limitedwipsociety.org/resources/

… or my article Kanban vs Scrum or (if you only have a minute) my cartoon One day in Kanban Land.

My philosophy is simple: life is short, time is the only truly limited resource. If you’re ever going to attend a course, go to the source. That’s why we enjoy working with people like Mary & Tom Poppendieck, Jeff Sutherland, Ron Jeffries, Michael Feathers, and David Anderson.

David Anderson is one of the leading pioneers of Kanban-style software development, so he counts as a Kanban source  )

See you there!