Mark Needham

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.

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.

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:

Time keeping

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.

Participating

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.

In summary

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.

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.

Facilitator participating

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!

Collecting/Analysing information

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.

In Agile Retrospectives the authors suggest that we ensure our actions are S.M.A.R.T which I think is a reasonably good idea although I’m not a fan of management acronyms!

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.

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.

Proactiveness

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.

I recently came across quite an interesting post written by Steve Garnett where he discusses the difference between constraints and impediments inside organisations.

He comes to the following conclusion:

For me, the difference between an impediment and a constraint is whether the individual, team, organisation, enterprise, or industry considers the obstacle as removable.

If whoever is working with the obstacle believes it can be removed then it is considered an impediment, if the same person doesn’t not believe it can be removed, or doesn’t wish to work towards it’s removal, it’s considered a constraint.

Over the last few years of working in various different organisations my experience is that there will always be some sort of obstacles and while I think Steve’s distinction is useful, it’s also helpful to consider whether we want to commit our time and energy to removing particular obstacles.

My former colleague Dan Bodart referred to this as ‘choosing your battles‘ and as well as saving energy and enthusiasm by choosing to live with some obstacles it also has the benefit that people who can help us remove obstacles will be more receptive to us if we’re selective in the battles we choose to fight.

The other thing that I’ve noticed is that people in the same team have different opinions on what they consider a constraint or impediment.

For example, I wrote last year about the benefit we can get from introducing new people with fresh perspective into a situation.

I found it interesting to notice the different perspectives of the new people compared to those of people who had been there a while.

Quite frequently something which the people who’d been there a while would consider to be a constraint would be seen as an impediment by the newer guys.

Another thing that we learnt from this situation is that sometimes waiting for a while can be a useful tactic before trying to remove an obstacle.

By this time we’ll have hopefully built a bit more credibility and trust within the system that we’re trying to change.

Something which can often happen with agile software development teams is that in the desire to take everyone’s opinion into account for every decision we end up having a lot of meetings.

Toni wrote about this a while ago and described a situation where he’d managed to get rid of a meeting and just have a discussion after the stand up with the necessary people.

While this is a good idea I still think there are occasions where it’s not necessary to discuss every problem down to the minute details with the whole team.

For example, this week we needed to make changes to some migration files to deal with the fact that we’d removed a gem which a migration previously relied on.

3 solutions were suggested and each had good and bad parts to it so any discussion amongst a group of people was likely to result in a split opinion on what the best approach to take was.

In that situation I think it makes much more sense for one pair to take the problem, work out what they think is the best solution and then just do it.

If it turns out that wasn’t the best solution then we can change it in the future.

It can be quite difficult to persuade people that it’s not necessary to have meetings because the meetings are usually are about things which affect the team so it seems to make sense to involve everyone.

On the other hand I like to think of what people could be doing instead of attending that meeting.

If what they could be doing would be more valuable then perhaps they shouldn’t be in that meeting.

On the majority of the projects that I’ve worked on at ThoughtWorks we’ve held a showcase at the end of each iteration to show our client what we’ve been working on and finished over the previous one or two weeks.

The format of these showcases has been fairly similar each time but the people who attended has tended to vary depending on the situation.

As part of the project being worked on at ThoughtWorks University we’ve run a showcase at the end of each week which the whole team have been attending.

Toby pointed out that having everyone there didn’t seem to be the best use of people’s time since the majority of the developers in the room didn’t actually have any input during the showcase.

I’ve often felt the same in that situation although we used a similar approach on a project I worked on last year and it seemed to be quite useful for addressing the human aspect of the project.

The client was able to meet all the people on the team and equally the developers were able to gain some insight into the types of conversations that the analysts were having with the client.

In that particular example we had around 10-15 developers so there was quite a big gathering but on the other projects where we’ve had the whole team at the showcase there’s only been 3 or 4 of us.

On the last project I worked on we took it in turns to go to the showcase. I think it’s quite useful to have at least one technical person in a showcase as they’re able to give instant feedback on implementation details such as how difficult it will be to change the way a certain piece of functionality works.

A lot of the time we didn’t have any input but it was interesting that quite often we’d come out of those showcases with more understanding of what the client was trying to achieve with a specific feature.

If we don’t have all the developers in every showcase we do tend to have them all there for the first showcase at least as that tends to be the one where the most stakeholders will be present.

Overall though it’s a call to make depending on the situation and the difficulty in judging the value of attending the showcase seems to come about because a lot of the benefits of attending are indirect whereas staying at our desk and coding has a direct benefit to the project.