India
India
I am one of the organisers for the upcoming Agile India 2005 conference (http://agileindia.org). This is the first such event in India and hopefully the start of a new tradition of local conferences on Agile in the style of the London XP Day (http://xpday.org). We are targeting about 250 attendees, but from the way things are looking with registration, we could easily have more. We have 2 tracks worth of sessions planned stretching over 2 days (check out the tentative programme plan for details). Bret Pettichord is coming over from the US to be one of our keynotes.
So, if you are in the general vicinity of Bangalore and are remotely interested in Agile (which I assume you are otherwise you probably wouldn't be reading my blog) then come along for the conference. Online registration is now open and will be open until Feb 25th (or unless we get too many registerees).
Here in Bangalore, I am staying in one of the three-bedroom apartments arranged by my company. The deal of my tenancy is that the other rooms may be required by people coming in from one of our other offices globally or from other parts of India. So far I've had an assortment of temporary roommates, each of which has presented a new learning experience.
My current roommate has a hearing impairment. I have never spent time with a person who needs to rely on lip-reading to hear. It certainly teaches you a lot about the way we interact and the things that we take for granted. Some of the things I’ve learned so far are:
-
you can’t shout at someone who’s in another room
-
it is hard to talk while going up or down stairs
-
you can’t speak in the dark
-
phones don’t work so well if you can’t hear
-
accents are not just audible, they also involve different lip movements
-
group conversations are hard to follow without auditory cues
-
how lazy I am about how I enunciate words.
These things may seem obvious in retrospect, but it certainly has an impact when you realise that you need to adjust your behaviour to be understood. Concurrently, I’m also struck by how quickly, subconsciously, we adapt to this new form of communication.
The other day, I came into the living room and my roommate was watching TV. At first I didn’t notice anything strange – it was only after a few minutes that I realised that he was watching TV with the volume off. Makes perfect sense, but I’d never thought of that before.
Lately we've been having a number of conversations about the Myers-Briggs personality indicator around the office. I'm still trying to decide if I'm an introspective extrovert or an extrospective introvert.
I attended the
Linux Bangalore conference last week and sat in on a session on Wiki dynamics. The speaker cited some study on the Myers-Briggs indicators of common Wiki contributors. Apparently INTPs and INTJs make up the vast majority of Wiki contributions -- unfortunately I didn't catch the reference. He then went on to castigate all ENTPs as either politicians or liars. Ouch! Typical judger :P.
Last night I was catching up on some of my blog reading and I read Rachel Davies'
post on MBTI. She references an
interesting article on the subject of personality tests by Malcolm Gladwell. I forwarded the article to
Rajesh who, of course, had already read it.
Lately, I've been conducting a set of feedback workshops here in the India office. Feedback has been a hot topic here for reasons ranging from performance reviews to candidate feedback to the formation of self-organising teams. I don't purport to know a lot about feedback, but I had this crazy idea for a workshop and people here have been kind enough to humour me and participate. The purpose of the workshop is to provide participants with a safe environment to practice giving and receiving feedback, and to teach a few feedback patterns and practices along the way.
The workshop is called Art Critic. It derives from some thoughts (a dream actually) that I had based on the Art Gallery retrospective exercise. Participants are asked to draw a picture of a common theme or concept. The pictures are then collected, exchanged and participants are asked to give feedback based on the picture that they have received. I've written up a complete description of the workshop, which I won't post here. If you might be interested in facilitating it, drop me a line and I'll sent it out to you.
This past week, I've been conducting a series of coding katas, here in the India office. I wanted to organise something to give people the opportunity to hone their development skills on tasks that are not project-related. I also wanted to provide an environment whereby people could explore new programming languages, for which the kata exercises are proving to be perfect.
The sessions run for 2 hours each morning from 9-11 (in Bangalore, most projects are late starters to maximise the overlap with clients in Europe or North America). Participants spend the first 1.5 hours writing code and then gather for the last half hour while one or two people volunteer to share their solutions. So far, the katas have been challenging and fun, and a great learning experience.
As for me, I've decided to try and teach myself IronPython. I know, I know... everyone these days is learning Ruby. But it doesn't look like Ruby will be ported to .NET anytime soon and I really need a scripting language that will work under .NET (Smallscript seems to have stalled). Plus, I can leverage my understanding of the .NET Framework instead of having to learn a slew of custom class libraries.
The problem with proxy customers (business analysts assigned to work with a distributed team) is that they serve as a layer of abstraction between the developers and the customer. While this seems like a statement on the obvious, the implications are not necessarily so. The primary concern with the use of customer proxies is that they may misinterpret the customer's requirements so that the development team ends up building the wrong thing. However, with highly iterative Agile development, this is unlikely to happen because the real customer has the opportunity (and responsibility) to regularly review what's been developed thus far. If the development team is off track, they tend to find out pretty quickly.
The main concerns that I have with customer proxies is that they tend to be too good at shielding the development team from direct interaction with the customer. As I see it, this creates two main challenges:
- developers are less likely to learn the language of the domain. As proxy customers are generally more technically-inclined than real customers, it is easier for the devs and the proxies to communicate using the language of the system rather than the language of the domain. This eliminates part of the compulsion to build a common understanding of the domain (the Ubiquitous Language that Eric Evans describes in Domain Driven Design) and, when developers actually have to try to explain the system to real customers and users during presentations or training, it becomes very hard for developers to get their ideas across.
- developers lose visibility in the eyes of the customer. This is especially dangerous as it can become easy to dehumanise the developers and be less tolerant of any mistakes they might make (especially in an offshore engagement where there is an implicit backdrop racial prejudice).
That said, customer proxies are essential to distributed projects. If developers need business questions answered and the real client is time zones away, the immediate feedback that a customer proxy can give is invaluable. However, what is important is to establish a process that ensures that the developers have the opportunity to regularly engage with the customer directly.
I'm back in India again after a 10-day trip to Europe for XP2004. It feels weird coming back -- everything feels familiar and strange at the same time. Being back in the West, I recognised some of the things that I miss being out here (like peace, quiet, and easy access to nature). Oh well, I guess you can't have it both ways.
The conference itself was great. It was wonderful to reconnect with many of the people that I met at last year's conference. The location was scenic and unlike last year, there was a central venue for everyone to meet and socialise. I presented my "Scaling Continuous Integration" paper which seemed to go over quite well. It did provoke a fair bit of debate and excitment after the session. I tried a bit of a different presentation approach by using a sequence of System Thinking Effects Diagrams to illustrate my ideas. I think everyone was sick of text-filled slides by this point, so this approach was a welcome alternative.
Trevor Mather, ThoughtWorks' CEO, was over visiting us in India last week. While crossing the busy road that our office is situated on and dodging through the mass of autorickshaws, motorbikes and buses, he remarked that crossing the road in India is a lot like playing Frogger. I couldn't agree more...
i find it odd that all most all indian cars have one of those devices that play music when the car is reversing. day or night, you can hear the electronic strains of titanic or sting or whatever, blaring out of the tinny speakers at the car's rear-end. this safety consciousness in reverse seems very much in contrast to the general road sense (or lack thereof) of the typical indian driver.
2 months in India and i've contracted my first intestinal parasiste*. whee! ciplox and electral for dinner for me.
*: since arriving here. i've already had gastroenteritisis, ameobosis, and dengue while living in the philippines.
cause my right hand smells like curry.