Experimenting with Visual Notes, sketch notes, inspired by Lynne Cazaly

This week I spent a five days out from work-time to attend an IBM Technical Bootcamp on MDM: Master Data Management. This is an investment in myself for my own learning and growth, in case I need to branch out into enterprise data management, leaving the world of set top box software (one day!). MDM is quite a niche bit of technology, with a lot of potential for growth, seeing the world is moving toward big data, data harmonisation and overall customer/product data governance. The market in South Africa is still small however, so I will have to monitor this one for a while...at least I came out with enough knowledge and technical understanding, including the internal architecture of an MDM system, which, a week ago, I didn't really have...

Anyway, the point of this post is really to share with you my current progress in my own journey of returning back to being creative again (I never took any art lessons or courses by the way). I have previously shared some of my sketches from childhood (left pic), which has been dormant for a long long time. Not so long ago, I came across the work of Lynne Cazaly on visual facilitation, and now I find myself quite inspired by visual note-taking, hoping to use this technique in my own facilitation workshops one day.

I am currently working through Lynne's book "Visual Mojo", as well as Mike Rohde's "The Sketchnote Handbook". I have also David Sibbet's "Visual Leaders" on my todo list once I've worked through the first two.

Inspired by Lynne's encouraging words as well as Rohde's own personal transformation from detailed note taking (which I used to), I decided to give this visual note-taking thing a shot, and use it for the MDM Technical Bootcamp. Equipped with a simple notebook, and two black felt tip pens (0.1 & 0.8 Mitsibushi Pencil Uni Pin Fine Lines which I've had for 5 years unused), and only halfway through both Visual Mojo & Sketchnotes, I took the plunge, and daring to share my very first attempt with you!

What do you think eh??

Incremental VS Iterative Development

Earlier this month, whilst paging through one of the books (Impact Mapping) on my reading table, I came across an interesting reference to an illustration that Adzic attributes to Jeff Patton, on the difference between incremental versus iterative development, which I found quite striking, and in keeping with pretty much most of my own experience in software development projects as both a developer as well as a manager of such projects. So I took out my phone, snapped it, and tweeted. Lo and behold, this quick tweet has been retweeted 74 times and favourited 36 times and counting -- no hashtags, no @anyone, so it seems the picture has resonated with a few people! 

(If you were one of the people that RT'ed, thanks!)

Here is the pic:

Attributed to Jeff Patton from Adzic's "Impact Mapping", Page 29

My next experiment is now to capture a conversation around this topic through this blog post, lets see if it drives some attention, starting with my perspective:

I favour more Iterative over Incremental, although context matters

My software development/management experience  of ~15 years is largely biased by playing in only one domain: Software & Systems development for Digital TV products: Set Top Box software (Operating System & User Applications like the EPG), and Headend Server Side products like VOD-encryption servers, IP-Streaming systems. I have tinkered with new technologies and some open source projects. 

And in all those experiences, we focused some time and energy in upfront design (iterating with experimentation) and architecture, so much so, that we focused on high level design of the core, fundamental infrastructure that would stand the test of time, with at least a five year horizon. Of course there is a lot of experimentation in the early phases, especially with trying to reach the initial point of having the broad framework in place, the pipelines roughly sketched out, as in the first block: A figure of a lady (that eventually becomes the Mona Lisa) sketched out, provides the broad vision of where we're heading towards, and then we iterate bit-by-bit in development the functionality, slowly painting the more solid picture. We could also stop at any point and consider our part done, because the essence of the architecture, end-to-end was in place, core functionality was always available. 

That is, at the outset, you can tell what the outcome was going to be, "a sketch / painting of a lady". 

With STB (Set Top Box) software in particular, there are not only well known standards that must

Vision: Mile-Wide Inch Thick?

be implemented, the market is so mature that there is a lot of prior art out there, so when implementing new features for a STB, there is really no need for discovery, it is not as unknown as say, implementing some brand new technology or disruptive feature. 

If the feature is new to the STB, you can be pretty sure the feature may already exist in some other form like a PC, tablet or smartphone, or even a webapp. Much of the STB roadmap, big-hitting features, are not that groundbreaking, hence there is no need to reinvent the wheel. In such cases, the architecture and design can be pretty much outlined upfront, and then proceed with iterative development.

I've been in many projects as this, so much so, that this has become a default way of running such delivery projects, and that's why I wrote promoting up-front architecture and design in this post. It's a personal bias, I know, it's been the bulk of my experience operating in a systems engineering domain...

So yes, I am all for fleshing out the foundation design, architecture and skeleton framework in just enough detail so we can see where we'd like to head to, and then iteratively add functionality until at such point we can say we're done...

MVP?

Looking at the Incremental stream, imagine if the first starting block was a quarter and not half: we wouldn't really know where we're heading, so with incremental development, we need to do just enough up-to-a-point where we have some kind of idea of the outcome, enough to guide us mentally to maintain some coherent view at the end. In cases of extreme uncertainty, trial and error, where you're not sure if the idea is going to fly or not, sure you can take the incremental approach. 

This is especially valuable when the product offering is new, and you're looking for quick feedback, are you on the right track, do you need to change tact, etc? So you start with what usually is a Minimum Viable Product (MVP), do the bare minimum (but fully developed according to the MVP), release, get & measure feedback, learn, adapt, implement -- loops until the product takes shape. Going this route may result in something that is not coherent at all (from where you started), looks like an amorphous blob, but still valuable as a product, because you incrementally navigated through the feedback loops and come up with something that is actually going to be used... 

I've not had as much exposure to this incremental experience as I've had with iterative development, although there is also merit in doing so as well, as you can fail early, fail fast which is especially useful in chartering new terrain...

What has been the bulk of your experience? How/What have you learnt in your own journey? Please share by posting your thoughts directly in the comments...