January 2011

The only way to learn to manage is to do it;
and the only way to do it, is to do in front of people;
and the only way to do it front of people, is make a bunch of mistakes in a very public forum;
and the only saving grace is that, as an inexperienced manager, it’s really not clear quite how many mistakes are being made.

Me, ranting, in a pub, in West London

This, of course, is of small consolation to the manager’s team.

So the question is, how do we train people for team management without causing pain and suffering to the team? I don’t think there’s a simple answer, but it definitely helped me to have a chance to learn something outside of my professional life.

Back in the days when I had silly hair and green shoes, I used to play guitar in a band. Much like software teams, the problems a band faces are as much social as they are technical. A band needs someone to draw the group together, drive things forward and turn a bunch of dreamy-eyed losers into a bunch of dreamy-eyed losers who, you know, might get a gig. I’d love to think that I was in the band for my guitar excellence, but in truth my job was to keep things together. Sadly the Lonely Crowd never quite made it beyond the indie dives of London town, but it taught me a huge amount that I would later apply in managing teams of software developers.

Trust is key

Without trust it’s not possible for the group to work effectively. I’m not talking about trusting someone with a winning lottery ticket, more that I know I can rely on that person in the context of the project. Once the trust is gone the band is gone, it’s not coming back. Similarly, as a manager, my effectiveness is directly related to the trust within the team.

No need to motivate, just don’t demotivate

Generally, people who form bands are motivated passionate people, no-ones’s getting paid to be there, and even those more interested in impressing girls/boys than music, need to make sure the band is as good as it can be. The easier it is for the group to concentrate on turning ideas into songs and turning songs into set lists, the more satisfying the whole thing will be. So don’t worry about motivation, focus on removing obstacles and dealing with cranky promoters.

Provide a vision

Often the line between creative spark and creative fleurgh is very thin. Someone has to provide a vision for the group to work towards. In my case this meant coming to the band with rough song ideas, I’d bleed over these things in my bedroom, secretly very proud of my work, only for the rest of the guys to mutate it into something excellent. The point is that without that first step nothing would have happened. Remember that the aim is not to be the best musician, it’s to make the best musicians better.

Roles and responsibilities

A band has distinct roles, when people talk about the Beatles they rarely start with George Harrison, but his considered rhythm guitar parts made it possible for Lennon and McCartney to steal the show, similarly Bill and Ted were never going to get anywhere on their own. The point is that everyone needs to understand where they fit and exactly what they bring to the group, if the drummer is thinking like a lead guitarist, the band will sound awful no matter what.

Feedback

Without good feedback the music will suffer, either through a lack of innovation or through a lack of quality control. The key is finding a way to express your thoughts, good or bad, without it being taken personally. Thinking managerially, the aim should be that the whole group can provide good feedback. Doing so effectively requires a high level of trust within the group as well as a sense of when to intervene if the criticism becomes destructive.

Limit work in progress

Getting a song to a performable state is massive step. It brings the group together and feels like progress. It’s better to have three presentable songs than nine nearly finished ‘things’, not least because it then provides a means for feedback from outside of the group.

Manage internal tensions

Where passionate people collaborate there will always be differences in opinion. Impassioned debate is healthy and a sign that band mates care about the project, but sometimes things get out of hand and it’s necessary for a third party to mediate. Generally it comes down to a breakdown in communication and trust, problems are often best fixed away from the rehearsal room and after the event once all concerned have had a chance to calm down.

So what are you saying Neil, before a new manager starts out they should spend three years in Spinal Tap? Hardly, but training for people management is a tricky subject. At some point it’s necessary to dive in with a real team, accept that mistakes will be made and aim to learn very quickly indeed. The thing is there are plenty of opportunities to gain an introduction outside of work, for me it was guitar wrangling, I’d love to hear what other people have found helpful.

In the previous post, Technical Debt is Different, I talked about the need to treat management of technical debt as a separate class of problem to that of feature requests generated outside of the team.

As with any project above a certain size, team collaboration is key, and that means having a reliable method of prioritising technical debt that the whole team can buy into. This post will describe a method that I have been using over the past year that satisfies this need.

Identify

I was new to my current the project and wanted to get an idea from the team of the sorts of things that needed attention. I mentioned this just before lunch one day and by the time I got back from my sandwich I had an etherpad with over 100 hundred items. By the end of the afternoon, I discovered that etherpad really doesn’t deal with documents above a certain size.

It was clear that we needed to a way to reference and store these ideas, I had two main requirements.

It was easy to visualise the work items
An easy, non-contentious way to assign priority

The first step was to go through the list and group items into similar themes, this helped identify duplicate or overlapping items. At this stage some items were rewritten to ensure that they were suitably specific and well-bounded.

Prioritise

Now that we had a grouped list of tasks it was time to attempt to prioritise. As discussed in the previous post, prioritising refactoring tasks can be challenging and passions are likely to run high. I felt that rather than simply stack ranking all items, it was better to categorise them against a set of orthogonal metrics. This led to a much more reasoned (though no less committed) debate of the relative merits of different tasks.

Every item was classified according to:-

Size
Timeliness
Value

Size

The simplest metric, this is a very high level estimate of what sort of size the item was likely to be. Estimating the size helped highlight any differences in perceived scope, and in some cases items were broken down further at this point. Size estimation works best when estimates for tasks are relative to one another, however to seed the process we adopted the following rough convention.

Small – A week
Medium – 2 weeks
Large – 3 weeks for 2 people

Timeliness

Timeliness speaks of how the team feels about the task in terms of willingness to throw themselves into it. Items were assigned a timeliness value from four options.

ASAP – There is no reason not to do this task right now. Typical examples include obvious items that the team were all highly in favour of, or items that the team had been aware of for some time and feel that enough is enough.
Opportunity – An item that lends itself to being worked on while the team is already working in the area.
Medium term – An item that is thought of as a ‘wouldn’t it be nice some day’. The items are typically riskier than ASAP or Opportunity and the team need to really commit to it’s execution before embarking on the item.
Long term – Similar to medium and generally populated by reviewing the medium section and selecting items that are imposing or risky enough to postpone behind other medium tasks.

Value

How much will the team benefit from the change? Is it an area of the code base that it touched often? Perhaps it will noticeably speed development of certain types of features. It could be argued that Value is the only metric that matters, however Value needs to be considered in the context of risk (addressed through timeliness) and effort (addressed through size).

All items for a given Timeliness are measured relatively and given a score of ‘High’, ‘Medium’, ‘Low’. Low value items are rarely tackled, and even then, only if they happen to be in the Opportunity category.

Visualise

Once all items had been classified, it is time to visualise the work items. To do this we transferred the items to cards and stuck them to a pin board, with timeliness on the horizontal axis and value on the vertical axis (each card contained a reference to the task size). Now it was possible to view all items at once, and from this starting point much easier to make decisions over which items to take next.

Since the whole team had contributed to the process it was clear to individuals why, even though their own proposals were important, that there was greater value in working on other items first. Crucially, we also had a process to ensure that these mid-priority items were not going to be forgotten and trust that they would be attended to in due course.

When a task is completed, we place a red tick against it to demonstrate progress, this helps build trust within the team that we really are working off our technical debt. Sometimes a specific piece of work, as a side effect, will lead to the team indirectly making progress against a technical debt item. When this happens we add a half tick, indicating that this card should be prioritised over other similarly important items so that we get it finished off completely.

Tiny Tasks

This system is effective in reducing the stress that comes with managing technical debt and provided a means for all the team to have a say in where the team spent their effort. However, one area where it is weak is in managing very small, relatively low value tasks that can be completed in an hour or so. Examples might include removing unused code, reducing visibility on public fields, renaming confusingly named classes – in essence, things that you might expect to happen as part of general refactoring were you already working in the area.

To manage these small easy wins, the team maintains an etherpad of ‘Tiny Tasks’ and reviews new additions to the list on a weekly basis. The rule is that if anyone considers a task to be anything other than trivial it is thrown out and considered as part of the process above. These tasks are then picked up by the developer acting as the maintainer during the week.

So what does it all mean?

Generally it is easier if an individual has final say of the prioritisation of tasks, in the case of technical debt this is harder since the whole team should be involved. Therefore, a trusted method of highlighting and prioritising technical debt tasks is needed. By breaking down the prioritisation process into separate ‘Size’, ‘Timeliness’ and ‘Value’, it was possible to have more reasoned discussion over the relative merits of items. Visualising the items together at the end of the categorisation process enables the team to make better decisions over what to work on next and builds trust that items will not be simply forgotten. Very small items can still be prioritised if the team agrees that they really are trivial.

What being in a band taught me about management