Take the agility test

Michael Hugos has come up with an agility test for the IT executive.

Take it. Get your clients and colleagues to take it. Compare notes. Learnt anything new ?


Pairing and productivity

Just been through a blog reading trail starting from Kathy Sierra’s “The Asymptiotic Twitter Curve” to Jason Fried’s “How to shut up and get to work” to Joel Sposky’s “The value of alone time” which all talks about individual productivity. The gist of those blogs is that we feel compelled to repetitively keep checking our email, IMing, answering phone calls, checking our blog stats etc without realising that it breaks our concentration and prevents us from going into a “zone”.

This led me to think about how Agile addresses the productivity issue. It was interesting to see that Agile considers colacated teams to contribute towards the overall productivty of the team. On the other hand, advocates of agile defend the loss of productivity when 2 people work on the same problem by offering reasons such as continuous code review, design brainstorming, risk mitigation against siloed knowledge etc. Based on the logic in those posts, productivity is actually helped through pairing and adversely affected by colocation.

One advantage of pair programming that my ex-colleague Ivan Moore mentioned to me was that out of politeness and respect for your pair,one would be less tempted to check for their emails or answer any phone calls or browse generally. The pairs keep each other honest and focussed on the task, and can crack on faster. Thus, what is lost in terms of having 2 people working on 1 problem is compensated by the increased and sustained focus on the task.

Agile advocates co-located team sitting in proximity for free flow of communication about project matters . Under such arrangement, a team member can potentially disturb another pair to ask about a problem that they might have tackled earlier. The benefit is that one does not have to solve the problem from scratch if other had done something similar earlier.

However, Joel observes that about 15 minutes of respondent’s time is wasted when they are interrupted in their work as they will now need to spend that time to get their concentration back. Joel’s observation is based on the fact that individual programmers have to juggle a lot of small details in a short memory and one loses that thread when they are interrupted. The process of re-organizing the data takes an investment of 15 minutes.

Now when I have been explaining a concept to someone and disturbed, I too have lost my thread and have had to repeat some of the things I may have already covered. However, if someone was listening keenly, they might be able to get me back on track again quicker without the need to repeat things.

Given this, my theory is that pairing would allow for all small details about the program to be jointly understood by each half of the pair and even if they get disturbed, they can make a faster recovery to get back on track and achieve their focus again. Thus, it might take only 7.5 minutes to get back to the problem for a pair who were interrupted as opposed to 15 minutes for an individual.

Has anyone got any empirical observations to back this up ?

Technical Debt Part 2

Following PierG‘s comments, I had further discussions with my colleagues and realised that he and I may be speaking about slightly different things. Technical debt can be generated by either of these

1. Technical debt generated from having poor safeguards such as bad testing, insufficient code reviews, no refactoring etc is bad (See Thomas Looy’s post )

2. Technical debt generated from having made a conscious decision about achieving short term fix that includes things like having stuff in a configuration file, static html page, manual workarounds etc.

One is a clear compromise on principles of working whereas other is a conscious well thought out short term fix. I suspect PierG had the former in mind when he talks about taking on technical debt as wrong.