Archive for the ‘Agile’ Category
Although the majority of the teams that I’ve worked on over the past few years have been relatively small in size I have worked on a few where the team size has been pretty big and perhaps inevitably the productivity has felt much lower.
I think this is somewhat inevitable since although the overall throughput of these teams may be higher than on smaller teams, due to problems such as having difficulty parallelising work, not every pair is working at maximum productivity.
This tends to mean that you’ll end up with some pairs who have development work to do for only part of the iteration and will then be unable to pick up a new story because there are dependencies on other stories which are currently in progress.
As a result the people in this position will get extremely bored and eventually they’ll start to distract the other people on the team which means that their productivity goes down as well.
Another side effect of knowing that there isn’t anything else for you to pick up is that you subconsciously won’t finish the story you’re working on as quickly as you otherwise might be able to.
One suggestion I’ve heard is that people should pick up technical debt when they find themselves in this situation but from what I’ve noticed unless you were the one who noticed the technical debt there is both context and motivation lacking.
Another possibility in this type of situation is for the developers to try and help out elsewhere perhaps by doing some technical analysis on upcoming stories or helping out testers with their work.
The former seems to work reasonably well but the problem when doing this offshore is that you can often only get up to a certain point at which you need some help from guys onshore.
As a result technical analysis often isn’t enough to keep a pair occupied for that long.
I’ve previously seen the latter work reasonably well whereby a tester would help the developer to work out which unhappy path scenarios needed to be automated and the developer could then write the automation code.
I haven’t seen that work particularly well on my current team and I think the reason is probably down to the fact that we keep separate sets of ‘dev’ and ‘QA’ functional tests.
I can’t currently think of a good solution to this problem other than matching the amount of work and the number of pairs more carefully so that everyone is occupied for the majority of the time.
I was recently reading an article about how to write meaningful user stories and towards the end of it the author mentioned the INVEST acronym which suggests that stories should be:
From what I’ve seen the most difficult one to achieve in a distributed context is that stories should be ‘negotiable’, in particular when it comes to negotiating the way that the UX of a bit of functionality should work.
On most of the projects that I’ve worked on the people designing the UX tend to work slightly detached from the development team and then send their designs over as wire frames.
It’s not the most ideal setup even if you’re working onshore but it becomes even more challenging when you’re working offshore.
Typically onshore if a particular user flow was very difficult to implement then one of the developers might go and talk with the UX guys and then explain the problem and give another potential solution.
The trade off between the cost of implementation and the user experience that the UX person has suggested is clearly outlined in these conversations.
When that feedback comes from offshore it has much less impact and I think it comes across much more as a criticism of someone’s work rather than an attempt to be pragmatic in helping the client to deliver a product within a time frame.
One possible solution to this problem if you have some onshore colleagues is to have them go and talk about the problem but we’ve found it difficult to do that because we try to split onshore/offshore stories so that we’re working on different parts of the code base.
Therefore it is pretty difficult for an onshore developer to go and discuss it for you.
To add to the problem we tend to realise the difficult of implementing a certain UX during the middle of our day which means we need to wait half a day to see if we can get it changed.
Given that time lag we often just end up designing it the way that’s been specified so that we don’t ‘waste’ time.
It’s clearly not an idea situation so I’d be keen to hear if anyone has come up with ideas to get around this.
One of the more interesting differences between Indian culture and my own is that in India there appears to be more adherence to a hierarchy than I’ve experienced before.
ThoughtWorks tries to keep a reasonably flat hierarchy so I think the idea of hierarchy would be much more obvious if I was working at one of the big Indian services organisations.
Between peers conversations don’t seem to play out any differently but someone in a position of authority is more likely to be able to get their opinion across and accepted with less resistance than they might experience without that authority.
On several occasions it’s been only me and maybe a couple of others involved in discussions if someone in an authority position expresses an opinion assertively.
I asked several colleagues why this was and they pointed out that when they’d previously expressed an opinion in that type of situation it didn’t have any impact so they’d stopped doing so.
I can’t decide whether or not it really matters – the situations where authority has any influence are relatively infrequent – but it would be cool if all opinions were assessed just on merit.
Of course these are just my observations so it’d be interesting to hear others’ experiences.
For the majority of the time that I’ve spent in Pune so far language hasn’t been a big deal at all but there are a couple of differences that I didn’t initially anticipate.
The local language
While the official office language is English my colleagues seem more comfortable talking to each other in Hindi so quite frequently the conversation will move into Hindi if someone isn’t directly speaking to me.
I initially found it tremendously frustrating that I couldn’t understand what was going on in group discussions and while I did point it out people don’t realise when they’re switching into Hindi so it’s a difficult problem to fix.
My brain now seems to zone out when people stop speaking in English so I don’t even notice that it’s happened unless I observe myself becoming much more aware of my surroundings because I’ve tuned out and started looking around the room.
An interesting side effect is that I don’t pick up as much information from osmotic communication as I have done when working in the UK/Australia because conversations between my colleagues have a 50/50 chance of being in Hindi.
I guess the easiest way for me to fix the problem would be to take lessons in Hindi but I’ve never got around to that.
Another interesting thing to note is that it’s not only me who doesn’t understand Hindi but also people from the Chennai office.
Swearing in India is a bit of a taboo which is quite strange for me because in the UK/Australia there’s not really any stigma attached to the majority of words.
There are a few people who are more easily offended so you have to be a bit more careful about word selection when speaking with them.
Having said that, with the majority of people that I’ve worked with the language that I use makes no difference at all.
A couple of months ago I briefly touched on the very stretched days I’ve experienced while working in India.
This is in contrast to what I’ve experienced in the UK and Australia where the day was much more time boxed and tended to go from 9am to 6pm.
At the moment we also have a call with colleagues in Chicago at 9pm for about 30-45 minutes so the day has now stretched out until nearly 10pm. We start with our standup at 10am.
We’re certainly not working all of that time but you’re never really done for the day until the call has finished.
With or without the call I’ve found it a much more difficult environment to work in than anything I’ve experienced before.
I frequently get to the end of the day and can’t really determine whether I’ve actually achieved anything because I’ve started and stopping working so many times.
I find I get distracted really easily working in our Pune office so I need my pair to be quite vocal about keeping focus!
One disadvantage of the stretched work day which I’ve only noticed recently is that you can become less reflective about the code because you don’t get as much time where you’re awake but not directly working with the code.
I frequently came up with possible ways to improve code bases on previous projects while playing around with something else or watching a presentation or similar.
I find that I play around with stuff outside the project less than I have previously partly because I’ve lost the 4 to 5 hour stretch that I used to have each evening.
On the positive side you get to know the people you’re working with pretty well because you’re with them for a lot more hours per day.
Not every project in the office has hours as stretched as mine but it certainly seems to be more common in India than elsewhere.
For the last two weeks we’ve had a ThoughtWorks colleague from the onshore team working with us in Pune and it’s been really cool having someone who has been working on ‘the other side’.
In my time in India there seem to have been many more people going from offshore to onshore than the other way around but based on this experience I don’t think that should necessarily be the case.
The typical argument in favour of someone from offshore going on site is that they’re able to interact with the client and onshore people and pick up any required context which they’ll then be able to share with their colleagues offshore.
The impact of those trips is perceived to be higher than what would be achieved by having someone do the reverse trip.
Having seen the interactions my US colleague was able to have with people has made me realise that perhaps that perception isn’t as true as it seems.
A big part of the success of distributed projects seems to be about the ability for the two sides to communicate effectively and having someone who interacts daily with people that we only know by phone/email is very helpful.
My colleague was able to provide context about our client and what they’re trying to do in a way that I don’t think someone going onshore for a couple of weeks would be able to do.
Sometimes it’s felt like we’re just building something because we were told to do so and my colleague has been able to explain the underlying thinking and what we’re trying to do with the system.
I think he’s also found it a pretty useful experience in terms of learning about the strengths and weaknesses of the team and what the real pain points are.
Everyone offshore now knows one person onshore personally which should be useful for any future interactions.
Some colleagues have been asking me recently what cultural differences I’ve noticed working in India compared to my experiences in the UK and Australia and one of the biggest differences by far is the amount of tolerance and patience people here have compared to me.
These attributes seem to show themselves in roughly two situations:
With respect to the environment
We’ve had some building work done in the Pune office recently which has meant that there’s been extremely high volume drilling being done to the extent that you can barely hear someone who’s sitting a couple of metres away.
I was quite amazed to watch colleagues continuing with their conversations as if nothing had happened – I was totally distracted and had to go and sit in a meeting room away from the noise.
I’ve talked to a few colleagues about this and they pointed out that they’re pretty used to the environment not being perfect from previous experiences at school or just in general life situations so it’s not such a big deal.
I find it interesting to see how influential the environment (as far as I can see) can be on some fairly fundamental personality traits.
People here seem to give others the benefit of the doubt much more frequently than I’ve seen elsewhere.
I’ve noticed this especially when communicating with people in remote locations.
I worked on a project distributed between two cities a couple of years ago and the distrust between the two locations was fairly evident in all methods of communication.
I haven’t noticed the same thing here as much and the majority of the time people don’t react at all to something which I would consider to be inflammatory.
There’s also much more tolerance for repetition of information than I’ve noticed elsewhere.
I get very frustrated if I hear the same thing repeated multiple times but the majority of people here don’t seem too bothered by that and take it in their stride.
It’s a strength not a weakness
I think that people here sometimes don’t recognise that their tolerance/patience is a strength rather than a weakness and I’ve frequently heard conversations where what I consider being tolerant is seen to be ‘rolling over’.
I don’t necessarily think the ‘western’ style of presenting an argument very assertively/confidently is the only way to go and I’ve seen colleagues successfully communicate while using their own style.
Of course these are massive generalisations based on my observations so it’d be interesting to see what other people who’ve had the chance to work in both cultures/environments think.
Earlier this year I wrote about some of the problems that we can run into when we have implicit assumptions in stories and another problematic approach I’ve seen around this area is where we end up with stories that are very heavily focused on technical implementation.
Initially this seems like it will work out pretty well since all the developer then needs to do is follow the steps that have been outlined for them but from my experience it seems to create more problems than it solves.
The first problem is that it seems to create a non thinking mindset and the more detail there is the less it feels like you need to think.
This isn’t a great position to end up in since there are frequently multiple ways to solve any problem and we will probably exclude those from our thinking if we’re just following instructions.
As a developer part of the skill-set is knowing how to implement a solution but an equally important part is being able to suggest alternative approaches which may be more appropriate in a given context.
Technically heavy stories only encourage the former as the developer may now assume that any other options have somehow already been considered.
In addition to this it tends to take a lot of time to explain these types of stories which presumably also means that it takes longer to write them up as well.
I’ve also found that it’s more difficult to understand these types of stories since it’s not initially obvious why you need to implement the technical approach that has been described.
Another thing which I hadn’t appreciated until quite recently is that it’s very boring/demotivating to implement stories if all the problems have already been ‘solved’ before you even start.
Given that it’s somewhat inevitable that we may end up with a story that is shaped like this the key seems to be not to get frustrated by the story but rather to try and find out what the underlying intent of the requirement actually is.
Some of the difficulties of working in an offshore environment were clear to me before I even came to India but I’ve come across a few others lately which I either didn’t think about before or didn’t realise how annoying they were!
Getting data from the client’s network
For several of the stories that we’ve been working on lately we needed to make use of huge amounts of reference data residing on the client’s network.
If we were working in the same building then it would be very quick to download that and use it for whatever we needed.
Working offshore we’ve been downloading those dumps via scp which can take around 5 hours for a 300 MB file.
I don’t know a lot about networks but I’m told that it would be possible to create a direct VPN between our office and the client’s which would allow the transfer of this type of data to be much quicker.
Dealing with internal IP addresses
Since we’re working on a different network any IP addresses for test environments of external systems aren’t directly accessible.
We have a box setup in our office connected via a VPN to the client’s network which forwards requests we make to local IP addresses to the equivalent IPs on the client’s network.
There have been several occasions when there have been internal IP addresses hard coded in our configuration files and we’ve completely forgotten that we need to create an equivalent local address.
It’s not a big time waster but it’s something you wouldn’t have to think about if working in the client’s office.
Slowness of the feedback cycle
It’s obvious that if the client is in a different country to you that there will be less face to face communication but I didn’t realise how frustrating that would be.
If you have an observation about a piece of functionality and the offshore BAs don’t have the answer then you’ll most likely have to wait 5/6 hours to speak to someone onshore about it or write your thoughts in an email.
While both of those are viable options I find my motivation to express my opinion is much lower if I can’t get feedback straight away.
As a result of this communication lag I think that we spend more time building functionality which doesn’t necessarily add a lot of value.
One of the trickiest things to do when working in bigger teams is ensuring that it is possible to parallelise the work we have across the number of pairs that we have available.
From my experience this problem happens much less frequently in smaller teams. Perhaps inevitably it’s much easier to find 2 or 3 things that can be worked on in parallel than it is to find 6 or 7 or more.
As a result we can sometimes end up with the situation where 2 stories are played in parallel with a slight dependency between them.
It may be possible to start those two stories at the same time but one may rely on an implementation of the other in order for it to be considered complete.
It’s not an ideal situation but it still seems doable if we ensure that the two pairs work closely together both metaphorically and in terms of their physical proximity.
I think a more useful strategy is to look at how many things can be worked on in parallel and then deciding the team size rather than choosing the team size and then trying to find a way to make the way the stories are written/played fit around this decision.
This is rarely what happens since budgets/need to get to market quickly often take precedence so we end up working in a sub optimal way.
While this is a trade off that the business may be happy to make I still think it’s useful to identify the risk we’re assuming by taking this approach as well as recognising that the amount of work we can flow through the system is limited by how much we can process in parallel.