Mark Needham

Thoughts on Software Development

Distributed Agile: Context

with 8 comments

From my last couple of months working for ThoughtWorks in Pune I think the most common subject that I’ve heard discussed is how to ensure that the team offshore is receiving all the context about the decisions and direction being taken onshore.

What I’ve found most interesting is that I think out of all the teams that I’ve worked on in the last four years my current team has by far the most context about what the client wants to do and the approaches they want to take over the next few months.

I think the main danger of trying to provide this level of context is that it almost inevitably leads to over communication.

Three of my colleagues from Pune recently went to Chicago for a few weeks and having returned to Pune want to share the context they got in Chicago with us.

I’m a fan of pulling information when you actually need it so my preferred approach was to discuss each of the functional areas closer to the time that we’d actually be working on it rather than having the guys effectively do a brain dump on everything they’ve learnt right now.

My reasoning is that I find that I struggle the most to learn when someone gives me a whole load of information which I can’t really connect to anything – i.e. information out of context.

The new design of ThoughtWorks University provides an example of how learning in context can be very effective.

Interestingly I was significantly outnumbered by my colleagues when we voted on which approach to take. They preferred to receive the context up front rather than later on.

I decided to go to a few of the sessions anyway and while the context has been well presented, I am finding that I forget the specifics of those sessions pretty quickly since I don’t have anything to link the concepts to nor am I using the information I’ve learnt right now.

I’ve also noticed less and less people attending these sessions for similar reasons.

My opinion on this type of thing is that as long as I know where I can get the data from when I need it then that’s enough. I don’t need to have all the details up front.

I’m not sure if this observation has anything to do with the team being offshore, if it’s a cultural thing or none of the above.

It’d be interesting to hear about others’ experiences.

Be Sociable, Share!

Written by Mark Needham

October 31st, 2010 at 6:27 pm

Posted in Distributed Agile

Tagged with

  • Devdas Bhagat

    IME, the problem with pulling context (as opposed to details of the context) is that you do not know that such context exists to be pulled.

    The important thing is knowing that such context exists, and the broad details of the context. This helps when making decisions which may potentially impact the other team(s) and you can pull details in at that time.

  • Sonali

    I think *context* is important, but I also agree with the fact that not *all* context is important up-front. If it’s captured well in the stories/ in the form of notes to certain user stories maybe it will not be lost by the time it is actually needed. I have found myself lost at the end of a long context sharing session. A broad overview is great.!

  • Praful

    Hi Mark,

    If I were on the team, I would have certainly been in your camp. I totally agree with whatever you have said like pulling in context when you need it.

    I believe in an offshore situation it might be hard to find the people who have the necessary context. As long as you have people who can provide you with the context when you need it, you are good.

    I enjoy reading your posts.

    Cheers,
    Praful

  • Venkatesh

    I have to totally agree with you on this.
    Even If I look back on my career, every inch of knowledge I acquired is only on a need by need basis. Eventually it got accumulated as a huge k.base that I could use in various situations.
    Its the same goes with the client requirements. Acquiring information out of context not only leads to over communication, longer boring sessions but also might lead to more wastage of time/effort as client requirements are bound to change often. Sometime ago, I read some where that “Walking on water and developing software from a specification(what client needs in next few months) are easy if both are frozen”.
    I wonder if this observation is anything to do with working offshore/culture. At least I can relate myself as working/coming from the similar background and I was never tempted to know everything more than what was required.
    But there is one thing always I did irrespective of any place/time. I bunked all these kind of boring sessions for sure.

  • @Praful – yep I understand the problem with not knowing who you can get context from. In this scenario luckily we do know who we can get the context from and they’re also on the same table 😀

    @Venkatesh – I like the walking on water when it’s frozen analogy, neat!

    Yeh the reason I was doubting it was an offshore/culture thing is that there are people who don’t want to know more than is required who have always worked offshore. Only some people do.

  • Pingback: Listening to feedback mechanisms at Mark Needham()

  • Pingback: While in India: Osmotic communication at Mark Needham()

  • Pingback: TWU: Session Design – Measurable goals at Mark Needham()