Archive for the ‘Agile’ Category
Despite being part of numerous retrospectives over the past few years I don’t remember actually facilitating one until my current team’s last week.
I’ve gradually come to appreciate the skill involved in facilitating this type of meeting having originally been of the opinion that there wasn’t much to it.
I recently read Agile Retrospectives which has loads of different ideas for activities beyond just creating ‘went well’ and ‘could improve’ columns and then filling those in as a group.
In the best retrospective I’ve attended recently the facilitator had us work together in small groups while coming up with ideas to fill in on the retrospective starfish.
I really like the idea of working in small groups because I think it encourages more participation in the discussion of problems on the team.
My general observation is that a sizeable percentage of people are more comfortable taking part in discussions in smaller groups than with the whole team (~ 25 people).
We split into groups of 4 or 5 and then populated a time line of the project since the last iteration before going across the board and discussing the most prominent topics.
These were some of the main areas that I had thoughts about during and after facilitating this retro:
Perhaps somewhat ironically given the amount I’ve been hassling my team mates to keep meetings short this one over ran by about 25 – 30 minutes, taking around 90 minutes instead of 60.
I had a rough idea of how quickly we needed to move across the board in order to finish on time but it got thrown completely off track by one point which resulted in a much longer discussion than I had expected.
I tried to move across the rest of the items a bit more quickly to make up for that but it didn’t really work.
I’d be interested to hear what a more experienced facilitator would have done in this situation as I’m sure it’s very common.
I’ve written previously about the dangers of giving your opinion when facilitating a retrospective so I tried to make sure that I kept out of any discussions that happened and allowed others to talk.
On a couple of occasions I was asked to give my opinion on certain things so I had to step out of my facilitating role temporarily, join the discussion and then step back in.
I think this worked reasonably well but I can see how it would be difficult to keep quiet if you had really strong opinions on a topic being discussed!
Summarising the discussion
I see part of the role of the facilitator being to try and summarise what is being discussed so that it can be written up afterwards and distributed to the team.
I didn’t realise how difficult this is, especially if the discussion drifts slightly away from its original direction.
I found it quite tricky to follow what was going on at times but luckily one of my colleagues was able to help me out when I didn’t quite get it right.
Overall it was an interesting experience and I hope I’ll get another chance to try this role again soon although for now we’re trying to rotate it around the team to give everyone an opportunity to facilitate.
A fairly common trend on nearly every project I’ve worked on is that at some stage the client will ask for more people to be added to the team in order to ‘improve’ the velocity.
Some of the most common arguments against doing so are that it will initially slow down the team’s velocity as the new members learn the domain, code base and get to know the other members of the team.
My colleague Frank Trindade wrote a blog post about 18 months ago where he described his observations of the above happening on a team he’d been working on.
Frank also identifies the following consequence of increasing a team’s size which I think is perhaps even more important:
the decrease of communication levels brought by the addition of new nodes
The majority of teams that I’ve worked on have had 15 or less people but there have been a couple of exceptions including my current team.
We currently have somewhere around 25 people working in Pune and then perhaps another 10 in Chicago so it’s the biggest team that I’ve worked on. Having said that I do recognise that it’s quite small in size compared to some of the other projects in India.
The following are some of the consequences with respect to communication that I’ve noticed. These are applicable as we increase team size and also just generally when having larger teams.
Standup takes longer
This is somewhat inevitable since there are more people taking part. It’s therefore much easier to lose focus on what other people are saying.
We’ve managed to reduce the time to something more reasonable by not having any discussions in the stand up, instead taking them offline.
Other meetings are much more difficult to control with more people in and I think it requires quite a skilful facilitator to allow everyone to take part and still ensure that the meeting doesn’t overrun.
Technical decision consensus
Getting consensus on any technical approach is much more difficult than when there are just a few developers on the team.
Technical discussions seem to take way longer than I’m used to because we try to ensure that everyone gets to express their opinion.
There are also more people available to then disagree with that opinion which tends to mean that we go around in circles more frequently.
I’ve found that there are rarely more than 3 or 4 ways to solve any problem so a lot of the time people are expressing similar opinions in a slightly different way.
When the team gets this big I don’t think it makes sense to include everyone in all technical decisions. My current thinking is that having a group of 3 or 4 people involved in each one is more than enough.
Greater distance between team members
I think the optimal setup for a software team is to have all the team members working on a single table – this means we can have around 12 members per team.
That way everyone is within talking distance of each other and communication remains smooth.
Once we have more people than that we need another table which means that there are 2 rows of people in between people on the far side of each table.
In The Organisation and Architecture of Innovation the authors include the following diagram which I think is quite revealing:
Although the authors are talking about bigger distances, I think the amount of communication is less if we are separated even by this little amount of space.
You now need to take into account the number of people that you might be disrupting by shouting across the tables which was less of an issue before.
Adding people to a team may increase the velocity but it’s unlikely to lead to an improvement which is directly proportional to the number of people added.
From my experience it might make more sense to take a bit longer building the product or application rather than aiming at a strict time deadline with more people.
These are just surface observations – I’m sure others who have worked for longer in big teams would be able to point out a whole range of other consequences.
Although we mostly split the work on my project so that there aren’t too many dependencies between the teams in Chicago and Pune, there have still been some times when we’ve designed major parts of the code base in Pune and have needed to communicate that to our Chicago colleagues.
I’ve never seen this situation so it’s been interesting to see which approaches work in trying to do this effectively and allowing the people in the other location to have input as well.
Explanation on specific email threads
While it’s useful to communicate the approach being taken by email we’ve found that it makes more sense to have a specific email thread for that conversation rather than tagging it onto something else.
It’s surprisingly easy for emails to get lost amongst the hundreds of others that people receive each day but at least if the important messages are all under an email with a clear title then it’s much easier to deal with.
While discussing this with Saager, he suggested that an effective approach he’s used previously is to include details of design decisions taken in commit messages and then point people towards those particular commits.
Of course however skilful we may be in communicating via email it does help to talk on a conference call as well – that medium seems to work better for explaining the reasoning behind decisions, especially if there’s a disagreement in the approach.
As much as we can explain design decisions in emails or conference calls it’s still not as useful for people as seeing the actual code which is something we didn’t totally appreciate until recently.
We’re now trying to ensure that we check in more incrementally when making big design changes.
This should help to tighten the feedback loop and ensure that we get the benefit of the design skills of people onshore as well as offshore.
Something which I initially considered as a disadvantage with checking in incrementally is that you will most likely get suggestions/criticism about what you’ve done even if you had already planned to address some of those areas anyway.
As a colleague correctly pointed out, the intention is generally good and it’s not the end of the world if someone suggests something you could have done better anyway.
These types of things seem obvious looking back at them now but I guess it isn’t so obvious to me because you never have to think about them at all when anyone interested in the code is sitting in the same room as you as it’s been for me when working onshore.
I’d be interested to hear any other approaches that have worked well for others working in a distributed fashion.
Continuing with my series of observations on what it’s like working in a distributed agile team, another thing that I’ve noticed is that it’s useful to try and ensure that there is communication between as many people as possible in the two cities.
This means that we want to ensure that we don’t have an over reliance on one person to handle any communication.
We have a call once a day between developers in Pune and Chicago and the Chicago guys have been able to achieve this by rotating the person attending the call.
In Pune we’ve typically had half the developers attending the call but perhaps only one or two actually speaking.
I originally didn’t think of this as being a problem because those two guys were really good at communicating and in other teams I’ve worked on we’d typically have the tech lead and maybe one other communicating with other teams.
In this case we are communicating with people in the same team and by chance a few weeks ago both of the main communicators from Pune were away at the same time so we had to have the Chicago call without them.
Perhaps unsurprisingly others were able to fill the gap that had been left and as an added benefit the guys in Chicago had now had the opportunity to interact directly with more people from Pune.
A interesting and positive side effect I’ve noticed is that the people who had now started communicating directly with team members in Chicago seemed to become more involved in the project as a whole and are now also more likely to communicate via email than they may have been previously.
Our challenge now that both the original guys are back is to ensure that the whole team still remains involved in communication with Chicago and don’t delegate back to those two every time.
Following on from my blog post about some observations about the actions that we create in retrospectives I’ve also noticed some general ways that retrospectives might not end up being as useful as we’d hope.
Having a manager facilitating
While having the manager of the team facilitating the retrospective isn’t a problem in itself I think it’s useful to remember that in this context they aren’t in that role anymore.
I’ve noticed that there can be a tendency for people to direct any comments they make during the retrospective towards the manager, thereby excluding others from the conversation.
Having the facilitator call out their role at the beginning of the retrospective and encourage participants to address any comments to the group can help to counter this situation.
Another closely related pattern is that of the facilitator participating in the retrospective and it’s easy to see why it happens since if the facilitator is part of the team then they probably have some opinions that they want to share as well.
Unfortunately what I’ve noticed happen is that they end up giving their opinion on the points made by others and if they have an opposing opinion to someone then it can easily discourage that person from participating any more.
One way to get around this problem is to have an external facilitator and the other is for the facilitator to realise that their role in this meeting is to facilitate and keep their opinion to themself!
Another common problem I’ve seen is the attempt to try and combine the collecting and analysing of data for the iteration.
I find that the problem with doing this is that we can easily end up belittling people’s observations if they get analysed and dismissed without being written up on the whiteboard.
Collecting all the data as one activity and then working through it after everyone’s had a chance to make their contribution is a much more effective way to do it.
Focusing on things out of the team’s control
While it’s useful to identify things that are going wrong which are out of our control it can quickly get very boring for everyone if those things get brought up repeatedly.
Quite often we don’t have the ability to address some things straight away but once we’ve gained a bit more trust we might get the chance to in future.
We’ve sometimes had retrospectives where you were only allowed to bring up things which could be addressed by the people in the room and this worked reasonably well.
It is still useful to remember which things we want to try and chance but can’t at the moment so that we can try again in a couple of months time.
My colleague Ashwin Raghav wrote a blog post earlier in the week in which he noted some patterns that he’s noticed in retrospectives in his time working in ThoughtWorks.
In it he talks quite generally about things he’s noticed but in my experience one of the areas in which teams typically struggle is when it comes to action items.
Too many action items
I think this is probably the number one mistake that we make in retrospectives and it’s really easy to make.
We find so many things that we can improve in our team and we want to try and do all of them straight away.
This sounds a little similar to what Dan North has been talking about in his Agile Architecture talk at QCon in San Francisco:
Often you’ll find tens and tens of things to improve, accept the fact that you probably can only change three of them, and focus on that.
Having any more than 2 or 3 action items probably means that the majority of them aren’t going to happen so we need to prioritise and make sure only the action items we really care about are recorded.
Action items that noone is passionate about
Even if we do manage to reduce the number of actions that we list it’s often the case that we’ll get to the next retrospective and nothing will have been done about many of them.
I think this stems partly from the fact that it’s really easy to suggest that something be added to the action items without considering whether or not there is someone in the team that is really passionate about making sure that it happens.
This often happens when we volunteer ‘owners’ for actions rather than someone being enthusiastic enough that they just want to go and fix it.
My current thinking is that if noone really wants to drive forward an action then we should just cross it off the list rather than fool ourselves into thinking it will get done.
Group ownership of actions
We recently came up with an action that was applicable to all developers on the team – around recording technical debt while working on stories -and I didn’t see the value of assigning an ‘owner’ to that action.
A colleague pointed out that if we had group ownership for that action then it would mean that nothing would happen because collective responsibility typically means no responsibility.
He added that it would be useful to have one or two developers paying particular attention to that item until the approach was engrained in the team’s mentality and everyone just did it by default.
Action items that are difficult to measure
Another common mistake is to come up with action items which are very difficult to measure i.e. we can’t tell whether or not we succeeded in executing the action or not.
I prefer to just check that with each action we’ll be able to know by the next retrospective whether or not we’ve managed to do it and if what we did worked.
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.
I’d always heard that communication when you’re working offshore was much more difficult than in a co-located team but it’s quite difficult to imagine exactly what the difficulties are until you see them for yourself.
These are some of my latest observations in this area so far.
I’m a very visual learner and the majority of the time any communication between people in two different locations will be done through words either via email or on a conference call.
Of course it is possible to do remote white boarding but that increases the overhead of the calls and sometimes participants in these calls only have their phone available and don’t have access to their computer or the internet.
I tend to find myself sketching out conference call conversations on a white board so that I can follow what people are talking about.
You lose the instant feedback that you get when doing this with someone else but I find it easier to understand diagrams than paragraphs of text or dialogue describing something.
Duplication of discussion
Due to the fact that we can’t just grab everyone in the team and go into a room for 20 minutes to discuss a design approach because half of the team is in another city.
We often end up having a meeting in Pune and then a similar one later in the day over the phone with people onshore and a parallel conversation going on over email at the same time.
It’s been significantly more difficult to get consensus on any decision with this style of communication than it would be if everyone was in the room.
In that environment you can easily read body language and see if someone doesn’t quite buy into what is being suggested.
Thinking how to phrase it
I think this is just generally a skill which requires more skill in non face to face communication and the conversations tend to be much more sugar coated to avoid offending people.
I don’t think this is a bad thing but I find that face to face conversations can often be more direct without someone getting offended or spending time trying to work out if there was a hidden message in the other person’s communication.
The risk here is that we can end up spending a lot of time working out how to word our communication and lose the point that we were actually trying to make in the process.
Working with outside teams
If working with other people on the same team in a different country is tricky it becomes even more difficult when communicating with outside teams in the remote location.
For example we often have to interact with a client’s operations team and in a co-located situation someone on the team would probably have met people on that team personally.
In a distributed situation you don’t have that so if you have a request for them then you tend to communicate via email.
Since they only know you by your name on the email I’ve noticed that it takes significantly longer for things to get done than if you could just go and speak with them.
These are just some of the things I’ve noticed and I do admire my colleagues here for learning how to work effectively with these constraints because it’s been amazingly frustrating for me so far.
I wrote earlier in the week about the benefits of having a physical story wall on a distributed team and in the process of getting one in place on the project we learnt a few things that I’d previously taken for granted.
All the work in one place
We initially started off by having stories on one part of the wall, bugs on another part and any technical tasks stored in Mingle somewhere.
The problem with this approach was that it wasn’t easy to glance at the wall from wherever you were sitting and be able to quickly gauge the state of the project at any given time.
We needed to look at one side of the wall to check what stories were being worked on and then check the other side of the wall to see who was working on bugs.
A couple of times we’d forget that the bugs were being tracked on the other side of the wall and two pairs would look at the same bug before realising that it had already been picked up.
We’re now in a place where we have stories, bugs to be fixed in this iteration and technical tasks all in the same lane on the wall.
Doing this means that everyone can quickly gain visibility into what can be worked on and then they can easily work out what the next thing to pick up is.
I hadn’t realised the value of having upcoming stories visible on the wall in the ‘ready for dev’ column until I saw it not being done.
The proactivity of the team seemed much less than in previous teams I’d worked on because people were unaware what they could pick up once they’d finished working on a story.
As a result of this there tended to be a lot of time where developers were waiting around looking for something to do.
A bottleneck had been created where they would need to wait for an analyst to tell them what could be picked up.
Now a pair can what the next highest priority thing for them and pick it up or at least work out roughly what they need to do before running through it with an analyst.
When I started working on my current project there was no physical story wall, instead the whole project was being tracked on Mingle.
The current state of the Mingle story wall was sometimes visible on a shared monitor and sometimes wasn’t, depending on whether or not the monitor had been turned off.
There was also a small wall used to track which stories were in development but after that there was no physical visibility of the status of anything.
The advantage of this approach was that there was no need to have the overhead of having to maintain a physical story wall and an electronic one.
The disadvantage was that it was quite difficult to see what people were working on and there was a very definite split between development and testing.
Mingle and similar tools are useful in distributed teams but they are information refrigerators in the sense that you have to put in some effort in order to get information from them – it’s not immediately available to you.
The physical story wall on the other hand is an information radiator which is what we want!
In the case that we get around that problem by using a projector to beam the web page onto a wall I still don’t think it’s as effective because it’s less human to deal with a projection than a real card wall.
I find it’s much more effective for people to be able to move cards around with their hands and then move people in between those cards depending on what pairings make sense at any given time.
The collaboration on my team seems to have increased quite dramatically since we made the card wall physical and I’d be surprised if the overhead of updating Mingle and the story wall was more than 5 minutes per day.