I too have realised that I am guilty of Yak Shaving, having set out to create a video game I decided that none of the middleware that was available was sufficiently streamlined to boost my productivity by the order of magnitude that I required to be able to complete the game’s development in a matter of a few years. Without tools that were designed to harmonise with the way I chose to conceive my “worlds” I would take decades to realise my vision. Yet, the development of these tools would be made much more rapid through the use of a bespoke programming language – after all, none existed at that time that precisely fit my stringent criteria. I didn’t know myself quite what the specification of my language should be, at first… soon realising that I needed to engage in some Research in order to better perfect its Design. I read about the merits of separate compilation, Eiffel’s melting-ice technology and later on about live-programming. I read about functional programming, referential transparency, term-graph rewriting systems, symbolic programming and constraints. I thought a lot about how an incremental integrated development environment could allow me to build the language/API/system/tools around myself and given how similar this was to Smalltalk that a reevaluation of the GUI was not “off-topic” if its perfection accelerated my future productivity. Every detour could be justified this way and without any imposed deadlines on my hobby project I continued in this pattern, not even blinking as I spent two whole years redesigning my keyboard layout. I was having fun.

However, there was a darker side… having begun in 1991 it didn’t escape my attention a decade ago that my estimates were, how shall we say, a little “off”. I had become so absorbed in the immediate problem and so fascinated by learning about and integrating new technologies into my design that the original objective of writing a game within a few years having spent a majority of those years building productivity enhancing tools so that the game could be completed painlessly in half of the remaining time which would be a tenth of the time it would otherwise have taken had obviously failed. Numbers did not add up. I had taken too long and wasn’t even past the design phase. Yet, I couldn’t stop what I had been doing… I had to see it through without compromise. I had to strive for perfection as falling short of that lofty goal would determine the limits of my ability. How good could I be? I had to know.

And then there was the fear. The niggling doubt that festered at the back of my mind that cutting any corner now, avoiding any detours in a blind sprint to the finish, would inevitably welcome disaster as I would likely find my future self using my completed middleware unable to do some overlooked thing because I had “rushed it into production”. The longer I spent on it, the stronger this dread became.

Don’t shave your Yak.

At this point, twenty years in, I find it easier to keep shaving. Although, as I have shaved one end of my personal Yak (so to speak) and moved on to the other end, it has started to regrow its coat. Since I began there are new languages, paradigms and architectures to research, digest, assess, reject and/or incorporate. Is the task finite? Well, I am confident that I am finally ahead of the curve… new things remind me of old things, aspects connect and reduce, dissenting opinions are resolved with greater wisdom… does anyone need to stuff a mattress?

Great video I uploaded it to my scrum community if thats ok come join us would be great to have you onboard?

Cheers
Ciaran
Founder Scrum Ireland

Your video was very thought provoking – Your commitment to Agile really shows!

My experience is a little different than yours, so please factor that into your take on my comments. I am a year from retirement after 40 years of factory management and materals product engineering – most all electrical materials – but right now we’re inventing better forms of mechanical strength elements for utility windblades. Most of this time I was trying to invent Agile all on my own, in part guided by my grad school seminar experiences, in part by sucessfull sports teams.

Yesterday I asked a remote scrum that I am product owner of not to send me initial samples of a product in an unmarked envelope, but to mark that sample using the journalistic 5 questions: who made it, who sent it/when was it made/what is it and what is it supposed to represent / where- what machine did it come from and what factory / How was it tested or analyzed or looked at?

So when I read the title of your video, at first I didn’t understand that it assumed there was a lot of documentation and you had the relative luxury of eliminating the unneeded portion. I am interested in how you go about initiating minimal documentation when there is none and maybe no one seems to care. I am looking for “Agile Documentation – What is needed?”

So I am asking – what do I need to send to the customers to whet their appitite, what do we need to keep to document our progress to the board of directors, make it easier for product diversification in the future, get accounting to report on us accurately and pay our bills, and tie into operational systems…. like that.

Unfortunately I have found that if you go to every department and try to negotiate what they want then THAT activity can become the project.

So perhaps the subtitle to your training video should be “…you don’t always get what you want,…”

Keep ‘em coming – well done!

Joel Gruhn
VP – Product Engineering
NEPTCO Inc.

Tamara

[...]some people we employed with together are as follows. They are amazing designers and take credit in their[...]…