What being in a band taught me about management

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.

Kanban in practice

My team has been using a Kanban board to manage our day to day work flow for the past few months having switched from time boxed iterations, what follows is a description of how we use the board in practice. This post concerns itself only with day to day development and does not cover high level planning.

First some context. The team is made up of four developers, a technical lead and myself as project manager. We are responsible for the ongoing development, deployment, support and maintenance of six hosted products that are expected to run continuously. We would expect to release new functionality to the live environment a ‘few’ times a week.

The Board

Our is board is positioned in clear view of the team and we conduct stand ups in front of it.

Example Kanban Board

The board contains 5 sections

  • Not Started – Stories we have committed to completing and that can be started at any time.
  • In progress – Stories where development and verification are underway
  • Ready to deploy – Stories that are ready to be deployed into the live environment
  • Done – Stories deployed live
  • Blocked – A place to track stories that have become blocked by parties outside of the team as project manager it is generally my responsibility to unblock these stories.

We limit work in progress in two places, currently we assign roughly a week’s work for ‘Not Started’ and a further week’s work for the combined total of ‘In Progress’ and ‘Ready to Deploy’.

We do not consider these limits to be ‘hard’ and will from time to time exceed them, however in doing so we will have had a conversation to ensure that we are happy to be exceeding the limit temporarily.

Stories

Stories are represented by post it notes, in addition to a brief description of the story each card is presented in a standard form like so:-

Post It Example

Size

Many lean practitioners view estimation to be a form of waste and therefore something to eliminate. Estimating is still valuable to us as it provides a means to build consensus over what the story entails, this is especially useful for less experienced members of the team who may not have considered all aspects of the story fully.

Project

While each story is a deployable artefact they generally form part of a larger set. By grouping projects in this way the story description can be simpler since the project itself provides context.

Dates

We record the date a story entered the ‘Not Started’ state, the date we began work on it and the date the story was deployed into the live environment. Doing so allows me to answer questions like ‘if we were to start a three point story right now, how long would it take to get it live?’, this in turn allows me to justify spending a fortnight on improving our deployment process as the positive impact is there for all to see.

Description

We try to keep the description as brief as possible, by ensuring that lead time is minimised to a few days it is practical to communicate decisions verbally. For complicated stories we can provide more specific details via a wiki or a tool like agilefant.

Pink Notes

In addition to planned project work we will receive a certain level of support and maintenance requests, that we represent by pink post its. These tasks are large enough to add up, but each one will typically take no more than half a day. Anyone within the team can create a pink note and we ensure that our board has enough slack to accommodate these new tasks.

New pink notes are discussed at stand up, after which there are three outcomes:-

  • The task has been prioritised and someone is already working on it (this is rare and occurrences should be minimised)
  • The task is added to our standard work flow and does not receive special prioritisation – we work on the assumption that our lead time is sufficiently low to respond quickly.
  • The task is removed and ignored. We explicitly do not use bug tracking software reasoning that tasks we choose to ignore when they are fresh in our minds are unlikely to be returned to.

The volume of pink notes is monitored so that more realistic estimates can be made for project completion as well as tracking gradual increases and decreases over time.

Maintenance

Smaller day to day maintenance tasks like reviewing error logs and looking into monitoring alerts/trends are handled by a designated maintainer. One off tasks that will take more than a few hours to complete can be added to the board as a pink note. The role of maintainer switches on a weekly basis amongst the developers and the aim is that the non maintaining developers can focus on project work and/or pink notes.

Performance Tracking

We attempt to track team performance over time so that we provide estimates for project work with greater confidence. It also means that we can track the impact of changes to the team e.g. what is the impact of moving a developer on loan to another team?

To do this we use two different methods. The first draws on Aslak Hellesøy’s work, and measures standard lean metrics such as lead time and WIP. The second provides some supplementary metrics such as finer granularity over what types of work were delivered on a weekly basis and finer granularity of lead time between phases. Aslak’s sheet generates a number of graphics, one being a cumulative flow chart which neatly visualises our recent Christmas change freeze.

A second sheet of my own making produces a chart for velocity, this is an agile rather than a lean metric, but I find it useful to track where we are spending our effort. The yellow ‘Total Velocity’ line saw tooths at about ~ 14 points, suggesting that we work to a fortnightly rather than weekly cadence. It also shows that during late Nov early Dec we spent more time on unplanned pink notes than we did on project work. Much of the pink note load will have come from outside of the team so it’s important that we have a way to make the impact visible.