Criteria for Innovative Success

I've got this in my head and want to write it down. I'm still tweaking it, and would like feedback.

Criteria for Innovative Success:

• 1a) A Shared Vision of Success
• 1b) Willingness to drive towards that Vision
• 2) Reflective Problem Solving Staff

A Shared Vision is, well, shared. Everyone involved should be able to articulate it, write/draw it on a single white board.

I split 1) into two parts, or more specifically added the second part. I think that just having a vision isn't sufficient, the will to see it through and cut away what's not helpful is critical. I suppose the metaphor for 1b) would be chipping marble away to make a sculpture.

"Reflective Problem Solving" is a phrase I got from "Managing to Learn" by John Shook. I've got more to say about this book and will review it when I can, but having a team of people who refectively problem solve is very different than a team that does what it's told.

In my experience at the Lean Kanban conference I concluded that a Kanban board with WIP limits is a "concrete reflective tool". I'm now on the hunt for "concrete reflective" tools and ideas, with a strong belief that such tools will be adopted by more teams than abstract or prescriptive tools.

Presenting at Austin JUG tonight, Kanban

Update: The presentation went well, lots of good questions and conversation.

Link to the slides: http://gistlabs.com/john/pubs/2009/05/AJUG/


I'm presenting at the Austin Java Users Group tonight, on Kanban.

The slides will get posted there and on my company website, http://gistlabs.com, shortly.

Setting up our Kanban board

Last week one of my clients and I set up a Kanban board for the team. We did it as a physical board, and we're backing each card with an issue in a tracker.

We plan to use the issue tracker for these purposes:

• generate a Cumulative Flow Diagram (perhaps scripting an export to CSV or Excel)
• searchable index of activity
• release management tracking
• conversation (comments, emails, checkins) for details larger than a notecard
  

Here's what the board looks like:
Some details (that are hard to read):

• A Prioritized Queue on the left, highest priority on top
• Three workflow/VSM steps: InProgress, Review, Deployment
• Review is for developer peer review, and Staging (on QA for general review)
• Deployment Ready is available for production deployment, Deployed is recently deployed.
• Three swimlanes: two for development activities, one for IT operations support.
  

This is the current prototype for the cards:
Some of the tools that we use include sticky post-it notes and Stikky Clips. (Note: We found the Stikky Clips at a teacher supply store, not a big office supply store.)

My Lean Kanban trip report is...

Posted up on the Agile Executive Blog.

See the whole post here: http://theagileexecutive.com/2009/05/11/john-heintz-on-the-lean-kanban-2009-conference/

Back from the Lean Kanban Conference

I'm back and planning on posting to my blog more. I've been posting on Twitter (http://twitter.com/jheintz) fairly regularly now. Some stuff just doesn't fit within 140 characters...

The Lean and Kanban conference was awesome: both humbling and inspiring. My trip report will show up on The Agile Executive blog (http://theagileexecutive.com/) soon... I'll post a direct link.

Below is a summary of my twitter activity, just to get warmed up.

1. @TheOtherAlistai @RonJeffries Iteration is like metronome, Kanban is like multiple rhythms, from #lk2009 (must find who said that...)2:42 PM May 9th from Tweetie
2. RT have a YouTube link for this eating style ;) -- @jeremiahakin: Langston eats apples like mr peepers from Saturday Night Live9:36 PM May 8th from Tweetie
3. #lk2009 So long, Miami, and thanks for all the fish!3:02 PM May 8th from Tweetie
4. @agile_exec Picked up a Lean Kanban Conference preceesings book for Israel... Who really should have been here! #lk20091:10 PM May 8th from Tweetie
5. @alshalloway great conversation about how/why Kanban removes fear/impedemnts to individual learning, must blog! #lk200912:37 PM May 8th from Tweetie
6. @agilemanager why is introducing Kanban easier than Scrum? I'm suggesting Kanban provides concrete reflection tools, lowers barrier #lk20098:36 AM May 8th from Tweetie in reply to agilemanager
7. Err, I meant tuning WIP and workflow is easy for people that wouldn't normally contribute to retrospective #lk20098:26 AM May 8th from Tweetie
8. Tuning WIP limits and workflow on the board is low resistance, even fir people that normally would say a think in a retrospective #lk20098:24 AM May 8th from Tweetie
9. I said concrete introspection is maybe the reason kanban is different. Just telling people to reflect doesn't just work. #lk20098:22 AM May 8th from Tweetie
10. I said concrete introspection, I mean that most people won't retrospect. Getting more people thinking in the biz is the real win. (hypothes)8:21 AM May 8th from Tweetie
11. Laribee just compared Kanban boards to the RESTful web metaphor... #lk20094:40 PM May 7th from Tweetie
12. Any good survey of online kanban tools? #lk200911:20 AM May 7th from Tweetie
13. Any good summary of online kanban tools? #lk20911:03 AM May 7th from Tweetie
14. Alisson Vale contract agreements: problem solving, support, improvements for sustainability, new value #lk200911:02 AM May 7th from Tweetie
15. Alisson Vale defined four (social?) contracts with customers #lk200911:00 AM May 7th from Tweetie
16. Alisson Vale "long term relationships require long term contracts" #lk200910:58 AM May 7th from Tweetie
17. @carlacorkern Chaka what? :) I'm at the learning gemba, not vegetarian.10:42 PM May 6th from Tweetie in reply to carlacorkern
18. @dennisstevens I'm not sure TWI is right either, but I have a strong hunch that is has wisdom for teaching knowledge workers. #lk20094:12 PM May 6th from Tweetie in reply to dennisstevens
19. #lk2009 link to TWI resource: http://delicious.com/jheint... training within industry is a WWII management system that influenced Lean.4:05 PM May 6th from Tweetie

Hotkeys for Omnifocus/Firefox

Until I get a chance to try out this integration for Firefox and Omnifocus (http://forums.omnigroup.com/archive/index.php/t-4510.html) I wanted to make a record of the hot keys I'm using right now.

Goal: Get a link to the current page I'm viewing in Firefox into a new task in Omnifocus.

Steps:

1. Command-L to get the browser location URL highlighted.
2. Command-C to copy that location.
3. Control-Alt-Space to open a new Omnifocus inbox item.
4. Type a short description of the new task.
5. Command-' to open the entry field for the notes. (This is single quote, not back tic.)
   
6. Command-V to paste the previously copied URL.

It works, avoids using the mouse, but that is too many steps.

My best code review

In 1998 (or maybe 1999?) I was a fairly junior developer, but fortunate to be working under a really smart mentor (Aamod Sane).

Among many things that I'm grateful for was his relatively constant practice of helping me through constructive code reviews.

The one that sticks out, the one that changed my view of how to write my own code, started out with me excited with finishing the code and a few tests for some now forgotten task.

After reading through it myself to hopefully avoid really stupid mistakes ;) I kind of ran down the hall to get the attention of my supervisor/mentor.

Once he finished what he was doing we started walking back towards my workstation.

[...this is where it starts to get interesting...]


On the walk back towards my machine I was nervously and rapidly telling him what, why, and how the code does what it's supposed to.

[Me doing all this quick overview talking was important actually...]


We sit down at my machine, swivel the monitor over, and he start reading.

He....
sighs.



Then....
shakes his head.



Really. That's what happened.
Yes, you know what I felt like. ;)


If it had just ended there it would have been like any other awful code review (see http://www.osnews.com/story/19266/WTFs_m)



So, finally, the really good conclusion.

Before he left he said this to me:

Just make the code look like what you just told me.

That walk between machines earlier when I rambled my way through telling him what the code did was actually a fairly clear description of things. The code I had actually written was really detailed, messy, and all together just "code".


After the advice of my mentor, I looked at the code with fresh eyes and I could see better method names, better looping patterns, and just better ways to "tell the story" of what I was trying to do.


Now, I try to write my code so that it "reads" like a good story. Sometimes I do a really good job, and other times not so much, but I have a clear goal that I'm shooting for.