Buy @ Amazon

Search This Blog

December 20, 2013

Talk Kata - Repeating Conference Talks

In the hard business of engaging the audience..

There are many kind of katas in the software world that I've been trying and practicing over the last 4 and odd years. Towards the end of last year, 2012,  I've started applying the concept of Katas in Public Speaking domain and I call it "Talk Katas".

Talk Kata is all about sharing your thoughts by way of talks to different set of groups, again and again and learn the art of public speaking in the process. It is with deliberate practise of public speaking can one hone the art of communication.

Attendees enjoying the talk
"When Agile becomes Fragile" is a topic I've been talking about in all of the recent conferences. It only gets better and better with every talk based on personal conversations, feedback etc. I've with the attendees after my talk.

Come year 2014, I'll again be talking about this in PMI Chennai edition as part of their invited talk series.

For the curious minds, the presentation deck evolution with each conference or invited talk is below:

An invited talk at Honeywell Technologies Solutions Lab, Bangalore India in October 2013. [1.5 hours talk incl. QnA]

A talk at Dev Day SriLanka, in November 2013 [1 hour talk incl. QnA]

A talk at Agile Kerala, in November 2013 [45 minute talk incl. QnA]

I've brought in subtle changes in the order and content in my presentations and was experimenting with different things to see what rings the bell in the minds of attendees to my talk. Learning is continuous and is indeed fun!

And guess what, I tried this with my other talk as well. See the subtle changes of presentation deck in slide-share on the topic of "Standup: Why I hate it and how I started to enjoy it?"

Bottom line: Talk repetition is just fine so long as you've the passion to deliver and the audience group is different and are enjoying your talk.

Moral of the blog post:  Deliberate practice maketh a person better and better in what (s)he does.

Side note: Every speaker has his/her style. I have mine (and you identify yours). I experiment a great deal with tons of zeal in a quest to learn more and more on what aids community learning. For the interested, I'll share some of my base-line techniques in public speaking in an other blog post. There is so much to learn and I'll share as I learn my lessons. Keep visiting..

Some feedback of my talk on this topic are below:

More can be found below:

Recursive chmod settings based on file or directory

I recently had to do this and below are the commands that I ran to get things done.
$ find ./my-folder -type d -exec chmod 755 {} \;
$ find ./my-folder -type f -exec chmod 644 {} \;
where the pattern is:
$ find [search-path] -type [d | f] -exec chmod [access-rights] {} \;
-type d => files of type directory
-type f => file of type "file", a non-directory
{} => replaces every file path found at the find command
\; => is to escape the semi-colon. And semi-colon is required to denote the end of command.
 If not escaped, the shell interprets it instead of find command.
755 => make a file readable/executable by everyone and writable by the owner only.
644 => make a file readable by anyone and writable by the owner only.

And as I was doing this, I tried reading a discussion in stack-overflow on this and found an even simpler command:
$ chmod -R a+rX ./my-folder
where the pattern is:
$ chmod -R a+rX [directory-name]
-R => recursively change permission
+ => add permission settings on the given role. Use - to remove permission settings against a role.
a => a implies all roles. Others being u for user, g for group, o for others
r => r implies read permission. Others being w for write permission and x for execute permission.

Note: I used X (capital) and not x (lower case). What does it mean? The capital X implies that if the file to be operated on is a directory then make it executable, else leave its executable permission bit untouched. It is also interesting to learn that this permission symbol makes sense for "+" operations and are ignored in other cases.

Further reading and references:

December 15, 2013

Work around to file protocol in browsers

There are times when you're dabbling with Front-end technology like EmberJS, AngularJS, etc.

You'd wish to load the just crafted web-pages of yours in a browser to see the work in progress state.

What do you do? First attempt is to load the page in the browser with the hardcoded local-disk location. It would be something like file://usr/kartz/frontend_apps/fake_app/test.html

This attempt might most likely fail in many modern browsers, especially if you have included any local javascript, css and similar assets. Are you here and wondering why?

This is due to browser security constraints. The work around to this is to serve this/these kind of files from web server so that the protocol becomes http.

But you don't want to get into the overhead of starting/managing a web server for this. You don't want to copy your file into the web-server  or work in the web-server's app directory.

You want your project source in your own chosen location and wish for some light-weight browser that you can start from your very own working directory of your project and load the files in the browser via http protocol.

If you've python installed in your OS (FYI - Mac comes with python packages), your life becomes easy. Python thankfully has a SimpleHTTPServer module that you can kickstart and get going with your real learning.

Below is the command to start this server:

usr/kartz/frontend_apps/fake_app$ python -m SimpleHTTPServer 8888
-m : run named library module as a script (terminates option list)
8888 : is a port that you want to this HTTP server to listen to

Update: In Python 3.x, this module SimpleHTTPServer, is merged with http.server, thus the above command becomes:
usr/kartz/frontend_apps/fake_app$ python -m http.server 8888 --bind

Happy learning!

July 27, 2013

Book Review - Domain Driven Design

A must read book for every developer aspiring to build great products

I strongly recommend reading this book, if you're an enthusiastic software craftsman.

Read -> Code -> Practise -> Understand -> Appreciate -> Apply -> Evangelise!

Think not, get your copy from Amazon now.

May 19, 2013

Stand-up: Party Meter

Party meter has many other names to it like Ice-cream meter, Sandwich meter, Snacks meter etc. It is a dashboard that displays the team members names in the first-column. And the number of times each member has defaulted or has broken the ground rules for stand-up, is logged as bars against their name in the second-column.

This defaulting count is logged for a specific duration of time (say, a sprint or two), or for a specific total count of defaulting bars (say, 10,20,25, etc). Once the specific time duration or total count is reached, the team celebrates with a party - call it a team outing or get-together for snacks/ice-creams/beer/whatever. The resulting expenses is shared by the defaulters in proportion to the number of bars against their name.

This is yet another gaming technique of bringing in discipline or order in the team.


A sample of how the ground rules for Party-Meter looks like can be read below:

  • Not being punctual to stand-up, invites a bar.
  • Absenting oneself from stand-up without sufficient and reasonable prior notice, invites a bar.
  • Forgetting to mention or wrongly mention the pair's name with whom the person worked invites a bar.
  • Deviating from the consensual update template, invites a bar.
  • Forgetting to mention a done task, invites a bar.
  • Forgetting to update the physical story wall and/or Project Management Tool, before the stand-up begins, invites a bar. For instance, if I've played a story and completed it, but have missed moving the story-card from one lane to another, say from Development-In-Progress lane to Development_Complete lane, and this is caught during the stand-up, then I and my pair with whom I worked would get a bar against each of our name in the pairing meter.

Note: Each of the above ground-rule should be set in consensus with every team member, that way every-one becomes accountable and committed.


Some common concerns

1. Its a costly affair, right?
It depends on what the team accepts on the party to be like. The key is not to punish anyone here, but still make them face a little penalty for defaulting. Let the team decide on the items that they can purchase, say, at the end of each sprint? Do the math to see how the cost will turn out to be, and decide on the items accordingly. The key is it should not be too costly or too cheap and mostly the team agrees to  it ;)

2. Who'll take responsibility to log the defaulters?
Do not impose it on one person as much as possible. Understand that this is a game, and play it as a game. Let one of the team members at random, do the service of logging the defaulters at the end of the stand-up. That should do good.

Okay, so let the party begin... ;)

Stand-up: Consensual Update-Template

   It is indeed an arduous task to listen to every team member giving status update in their own style or format. Practically, it is known that the attention span of an individual to listen is very less. Getting the most out of it is indeed important. For this reason, it would be a good practice for every team member to adopt a status update template that all agrees to. Now for different status update template/format, its pros and cons, can be read in inimitably lucid style at Martin Fowler's Bliki post.

   In continuation to this topic, I wish to put forth my favorite template below:

Yesterday I was pairing with ___________,
playing the story ______________,
in which we completed the tasks ____________.
We intend to work on __________ today.
We had a blocker issue which I'd discuss in the developer huddle, after the stand-up.

In essence the above template answers the following three questions:

  1. What did we as pair accomplish yesterday?
  2. What we intend to work on today?
  3. What obstacles we are facing in our progress?

Final words. Having/following a template like the one above helps the team in the following way:

  • Eases mental preparation before stand-up
  • Improves better communication between team members
  • Betters attention to stand-up updates

Stand-up: License to speak

It is a sight for the onlookers when more than one person speaks at a time or when a team engages in endless discussions. Outsiders (non-team members) would start labeling such teams with tags like "indisciplined", "very political", etc. Sure enough, it is not the subjected team's desire to end up in such a state and even worse that such state becomes more or less a routine thing during stand-up.

In my experience and observation, it takes a lot of courage, discipline and mentoring to have one conversation at a time in a meeting. In order to restore this discipline of "one conversation at a time", play the license to speak game. Yes, you read it right, I called it GAME. It is more a fun to gamify the thing called DISCIPLINE.

So what is this game all about? Well, this game is all about the eligibility of a person to speak in a meeting. One who holds the 'declared token', has the license to speak and after his/her turn, the token is passed to the next person in the team, who then gets the license to speak/update.

How I started to enjoy the ceremonial daily stand-up?

NOTE: If you're to land in this post directly, without having read the post, Why I hate the ceremonial daily stand-up?, please do read it before reading further. Its worth your time.
This post details the golden advices that helped me and my team enjoy the ceremonial daily stand-up. Try it, and so should you.
  • Always do stand-up meetings in open space even if the team is distributed. If it hurts your distributed team meetings badly and for genuine reasons, then you may think of considering to have stand-ups in a conference room.
  • It is always a good practice for the stand-up meeting to happen near the physical card-wall.
  • Stick to the stand-up time after having decided it on team consensus. For no reason can the stand-up time be shifted temporarily - it kicks in laxity.
  • The speaker in the stand-up meeting should have the license to speak.
  • Every team member should adopt the consensual update template.
  • Introduce the party meter for the fun and energy it can magically bring in the team.

Why I hate the ceremonial daily stand-up?

Ceremonial: a system of ceremonies, rites, or formalities prescribed for or observed on any particular occasion; a rite.
Ceremonies, in my humble observation, are mostly followed blindly and hence poorly - such is the order of the day. Whom do we blame for it? I would blame both the institution of practice for not thinking of methods to aid understanding the purpose of the ritual and the materialistic folks who take the easy route of not experimenting/practicising the ritual with an open mind and find/seek reasoning.
This pattern is observed in the work places too. People take the convenient route to idleness, and devil's workshop. No matter what methodology of practice is prescribed, people always have the tendency to find fault rather than value in it; Agile is no exception to it. Take the case of every-day stand-ups, I have seen it becoming dysfunctional in teams, sooner or later.
In this post, I'm intending to jotting down my observations that I made over the years, on the institutionalized practice of every-day stand-ups.
Lack of preparation
    You can witness team members quoting something like, "I'm hating our stand-up because it really isn't organized. Somebody interrupts me when I'm giving my update, to mention some damn forgotton thing. ##ck can't he come prepared for the stand-up". One other recurring pattern is, "Why does she always come to the stand-up and thinks of her update just when its her turn? Man, this is so so silly."        
Poor communication
    This is especially common in a team of diverse people coming from different backgrounds. Good news is, of all the problems, this one is execusable for some period of time, because it has got nothing to do with attitude but with ones ability and adaptability. Classical example is when a team comprises of multi-cultural people where each individual attempts to give its update in a common language that everyone understands but in their own native accent. This is sheer fun to watch from outside, and a great experience from inside, to both learn and adapt. But, until that point of learning and adaption, it is a pain.    
    Every-time a person gives a detailed update, it sets the others off from listening not just to his update but to other subsequent updates as well. This one is truly a weed, that crops up anytime during the lifetime of a project, and if unattended, it drains the energy out of the team members.   
    When internal politics in the team is unckecked, it reaches a point where people wait for an occasion to settle scores, and stand-up becomes one avenue for it.    
    A lack of conscious discipline to stick to the purpose of the meeting results in people deviating by cracking light jokes, passing intermittent comments quite often, or doing anything that is irrelevant to the agenda of the stand-up.   
Lack of Punctuality
    It is not uncommon to see people checking into the stand-up just when it started or in the middle of it, citing traffic, or any other lame reason.
    This is the manifestation of extreme lack of discipline/commitment/interest/motivation with-in the team/person. Again, it need not be the absentee who is to be blamed, it could well be the team's way of functioning that is to be introspected for corrective measures.
Building upon this post as basis, I'll soon post ways to get over these maladies.
Update: As a sequence to this post, I have put up a post titled, "How I started to enjoy the daily ceremonial stand-up?". Read on...