Session idea: You are the Team Leader

Here’s a session idea that has been rattling around in my brain for a while; how to better prepare team leaders for the awkward people-related challenges that will crop-up in their future. I’ve tried, but been ultimately unsuccessful, to submit the session to my local agile conference, so thought I would post the idea here to see if anyone has any ideas to help me improve it. So, here it is…

Session Title: You are the Team Leader


You are a newly appointed leader of a software development team. On your first day in the role, a team member tells you in private that they think that one of the inexperienced developers in the team is a “waste of space”. What do you do?

Team leaders are faced with awkward situations and difficult challenges every day. Peopleware, a seminal book about leading project teams by Tom DeMarco and Tim Lister, states that “the major problems of our work are not so much technological as sociological in nature”. This rings true; we are comfortable solving technical problems, but we struggle to cope with the unpredictable issues that crop up when people work together.

Furthermore, in difficult moments when we are put on the spot, we can react hastily and respond to situations in ways that do not reflect our principles. If given space and time to think about these challenges, we would probably handle things differently and be more consistent with our values. Often we handle awkward situations as best we can when they first come up and then, hopefully, we have the experience to better handle them in the future. Hopefully. But perhaps we could prepare ourselves better in the first place?

In this workshop we will deliberately practice leading a software development team. Attendees will tackle a series of awkward leadership challenges, pooling their ideas and experiences in order to decide what they would do in each situation. There will not be any right answers, but we’ll discover new perspectives, evaluate options and better prepare ourselves for the awkward situations and difficult challenges to come.

More information about the session

In this session, we’ll be focusing on the team interaction and people challenges team leaders face every day, rather than technical or process problems. We’ll take some time to talk about the leadership principles we’d each like to personify and will then use that as a framework for the rest of the session.

We’ll employ a number of facilitation activities to explore each challenge to help sub-groups think creatively. At the end, we’ll ask groups to share their proposed course of action and their reasons for that decision.

The workshop takes inspiration from Paul Trevillion’s cult You Are the Ref comic strips, which feature a series of awkward football referring challenges (see below). If I’m lucky enough to be selected for a conference, I’m hoping to produce some (significantly less well drawn) comic strips to help capture each challenge and bring the scenarios to life. We’ll see…

You are The Ref

Making time for Personal Development: Gold Cards

At the beginning of 2015 I got the development teams in my corner of Redgate together to explore the results of an annual company health survey. Amongst the feedback we’d received in the survey was a clear consensus that team members found it difficult to make time for person development activities.

That was especially true of activities that people wanted to do to further their skills/experience in an area that did not align with the project they were currently assigned to. So, an engineer working full-time on a desktop application wanting to increase their web development skills. This kind of activity, together with reading a book on coaching or mentoring someone on testing strategies, were falling by the wayside.

Making Personal Development visibleIt wasn’t all bad news. Some team members were managing to eke out time to do personal development activities alongside core project work through timetabled extra-curricular activities that happen at Redgate, like Coding Katas, community of practice get-togethers or Coaching Dojos. However, most people were not able to find the time to focus on self-improvement naturally or simply felt too guilty to step away from project work. They saw this prioritization of personal-focussed work as somehow letting their team down.

Redgate have always been supportive of spending time on personal development (a.k.a. learning and development) tasks. In 2013 we rolled-out an entirely new approach to facilitating and building personal development plans and we’ve spent a lot of time honing role-specific Skills Maps to help people measure where they are and decide where they want to improve. Despite these efforts, the survey told us that Redgaters were still struggling to feel like their personal growth was being given enough focus.

In response to this discovery, we decided to experiment with a concept called “Gold Cards” – an idea we were introduced to by Rachel Davies of Unruly. Here’s Rachel’s post on the use of these personal development artifacts at Unruly – Gold Cards and Viking Helmet.

What are Gold Cards?

Gold Cards make it explicit that everyone can spend up to half a day a week (or one day every 2-week sprint) working on stuff associated with their personal development. For our teams, these half day personal development blocks and can be used for:

  • Anything on their personal development plan
  • Katas and dojos
  • Training
  • Product innovation (where innovating aligns with an individual’s personal development)

The only qualification for this work is that people describe what they will be spending their time on to their team at that day’s stand-up meeting.

Gold Cards on our taskboardTo represent these two half days of personal development, each team member is issued with gold-coloured cards that they can place on their team taskboard to indicate when they are working on personal development. They can use their Gold Cards at any time you choose during the week. Or if they work in two-week sprints, they can use two Gold Cards per sprint, if that makes more sense. Unused Gold Cards do not roll-over to the next time period. Use ’em or lose ’em.

We hoped Gold Cards would make it overtly ‘ok’ for everyone in development up to spend half a day a week (or one day every 2-week sprint) focusing on learning and development. Basically, we’re consenting to people spending 10% of their time on personal development. This isn’t necessarily a change in policy, we were always very open to people doing personal development activities. We just wanted to make that sentiment explicit.

Where we are now

My division of Redgate have been using Gold Cards for 6 months now and they have been a success, garnering positive feedback from team members and having little or no discernible impact on project productivity.

Here’s some of the feedback we’ve had about Gold Cards from our teams:

  • They have encouraged people to think about and undertake personal-development related tasks (hurrah!)
  • They ensure it is called-out when people are spending time away from the project and why
  • It can be difficult to know when’s the best time to use your Gold Cards, but the teams have successfully self-regulated this
  • They highlight, and implicitly promote, personal development activities that were already happening (like Coding Katas)
  • They highlight the need for people to think about personal development, to have a ‘plan’ and to actively manage it
  • Making the use of Gold Cards ‘mandatory’ didn’t really work (especially in a sprint with a big deadline)
  • People think quite hard about how many hours a Gold Card is ‘worth’ and worry about only spending half a card (i.e. only using 2 of the allotted 4 hours)

Interestingly, it seems a side-effect of adopting Gold Cards has been that personal development stuff that was already happening, like attending Coding Katas, is now called-out and visualized on team boards. This has reinforced to other team members that spending time on these personal development activities is acceptable and, as a result, they are more likely to get involved themselves.

All-in-all Gold Cards have definitely helped us move in the right direction, but we’ve got more to do with personal development – especially with regard to development areas not aligning with current project work. We hope that the Spotify Guild model may help us in that regard.

However, based on this success, we are now planning to spread Gold Cards to the rest of the development teams at Redgate.

How to build a great agile team

The group of talented engineers I currently lead have formed into a great team over the last year. Recently, I’ve been considering what I thought that was down to (as it would be quite useful to know!). Was it simply the somewhat fortunate mix of personalities who were allocated to the project? Was it blind luck? I didn’t think so, and after some deliberation here’s what I’ve distilled my thoughts down to: The six things a team leader should do to build a great agile team…

Six things a team leader should do to build a great agile team

1. Gather the right people

This will seem trite, but the single most important factor in building a great agile team is to gather the right people. Thrusting a random selection of “resources” together is almost certain to fail.

When carefully assembling this group of people, it is not enough to look at the ideals of a Scrum team – that is, it is not enough for the team to be cross-functional, co-located and have their time dedicated to the project. It is also not enough to identify team members by looking at their technical skills or specialisations. Some of those aspects are far, far less important than the attitude, motivation and potential of the people that come together to form a really great team.

The right people

The right mix

Let me Put it this way, I’d rather have a new graduate engineer with a team-centric attitude and a drive to improve in my team, than an experienced developer with vast expertise in specific technical disciplines but who
does not play well with others. I’ve occasionally had to make the call between experience and attitude when assembling teams in the past, and I have never regretted choosing someone with the right attitude.

That certainly isn’t to say that you should populate the team entirely with new graduates who possess a can-do attitude. On the contrary, what you are looking for is the right blend. A mix of skills and experience levels. A mix of introverts and extroverts. A mix of heads-down-thinkers and just-get-it-doners. Overall, you want a group of people who are happy to collaborate and want the team to succeed. What every team member of a great agile team needs is an ability, when push comes to shove, to put team goals above personal goals.

There’s so much more to say about gathering the right people. Mike Cohn talks about “Getting the Right People on the Team” in his book Succeeding With Agile, so I’d recommend grabbing a copy of that. My headline for a team leader or project manager is – think carefully about the balance of the team.

2. Set a clear direction

Go about setting some clear, realistic goals as soon as you can at the start of a new project or the inception of a new team. Including all team members in that process will give those goals a better chance of actually being adopted as a measure of success by the group.

Set direction

Set a clear direction

The team may well come up with technical goals, such as “No manually testing will be required to release”. Embrace these targets but be sure to highlight the targets that have been set by the business too. If the project needs to achieve something for it to been seen as a success for the company, this has to be highlighted.

Business goals can co-exist with technical and process goals, but they must be defined in a way that the team and it’s individual members can identify with and get behind. For instance, a usage goal – increase active users of the product by 1,000 – may well be more powerful than a revenue goal – make $100k in Q3. The former focuses on the people actually using the features/stories/fixes that the team work on, rather than the company’s profitability. Profitability for a company is vital, but is not something directly controllable by the team. The team need to feel that their goals are something they can directly achieve through their efforts and influence.

Encourage the team and the business to define goals that are incremental and measurable. Goals should not be a on/off switch, you should be able to gauge and celebrate progress.

3. Call-out your shared values

Help the team be explicit about the values they share or want to aspire toward. As a result of establishing those values, you can generate a collection of effective behaviours that can act as team touchstones, encouraging team members to keep true to their ambitions and vision. Get everyone on the team to agree to ‘sign-up’ to these values. If there are objections, try to reach a consensus or compromise, if you can’t – move on and return to that proposed value at another time. The whole team needs to agree to these values up-front.

These set of values are often called a team’s working agreements. However, they need to go beyond the prosaic “We have stand-up meetings every day at 10am”. They should encourage behaviours that the team would otherwise not undertake. For instance, the team may decide they believe in reducing Technical Debt, so an agreement to adopt the Boy Scout Rule could be a catalyst to achieving this and a constant reminder of their shared attitude towards problem legacy code.

A team member of a great team should be able to highlight when a shared value has been ignored or forgotten. They should be able to do so without fear of reprisals or of causing hurt. So in my example, if during a code review a developer notices that their colleague has neglected to tidy-up anything in the legacy code they altered, the reviewer should be able to call-out that the Boy Scout Rule has been ignored and fail the review. Doing this may not always feel comfortable, but the team made a pact to keep to their shared values. As Patrick Lencioi writes in his fantastic book The Five Dysfunctions of a Team, team members need to trust each other, engage in healthy conflict and hold each other accountable. If you are in the business of leading teams and have not read that book, you should definitely do so (there’s even a graphic novel version!).

4. Get the team to work together

Encourage the team to ‘swarm’ on as few pieces of work as possible. If there are four developers in the team, don’t work on four distinct features if you want to build a great team. Work on a single feature. That feature will be better understood across the team, better architected, more likely to actually work and will be ready to deliver to users more quickly (as the team will have one thing finished rather than four things in progress).



Working together will reinforce the team’s shared values and behaviours. More importantly, it will mean that everyone has skin in the same game. One person’s blocking problem is everyone’s blocking problem. Similarly, one person’s success is everyone’s success. Contrast this to when numerous pieces of work are underway simultaneously – one person in the team can be struggling with a difficult feature when the rest of the group are happily making progress. That approach fosters divisions within the team and great teams don’t have divisions.

Team leaders can encourage the team to work together on stuff by selling the above benefits. They can then implement a small work in progress limit which will force team members to join-in with work already in progress once that limit has been reached. To some members of the team, this will feel like an inefficient way to work. Acknowledge that argument (even if you disagree with it) and challenge the team to try it. They might need to think hard about how to make work parallelizable but after a few sprints of pairing, learning and finishing stuff, ask the team to reflect on whether this new approach was beneficial overall.

5. Continuously improve

As I’ve written before, I believe the drive to inspect and adapt is the most important concept to have been popularized by the agile software development movement. This essence of this idea is that “we will always know more about the project in the future than we do right now”. The responsible response to that is to build in regular, frequent feedback mechanisms to our development process to be able to take stock of, and respond to, our improved understanding.

Taking time to reflect on what has happened on a project and making things better is also a key part of building a great team. Team members need to be able to highlight problems that have impeded, disrupted or upset them. They then need to be given the opportunity and the permission to resolve problems or take steps to avoid issues arising again. The team is self-repairing, which leads to a proactive attitude.

In my view, the best way to ensure that a team takes the time to continuously improve is to have regular, frequent and engaging retrospective meetings. If you want to do that, I’d recommend reading Esther Derby and Diana Larsen’s Agile Retrospectives book.

6. Celebrate success

Chirayu wins the Best Code Improvement Award

Chirayu wins the Best Code Improvement Award

Being in a great agile team should not be a thankless task. When things are going well, reflect on this with the team and take the time to enjoy it. When team members pull-out all the stops to do great work but receive no recognition, their motivation can be eroded and their commitment to the team’s cause may waiver.

Regular, frequent retrospectives meetings should include time to highlight team and individual achievements. Review (aka Show & Tell) meetings should emphasize good results and happy customer feedback.

Celebrating good work that has been achieved together, helps to reinforce the feeling that you are part of a great team. If you feel part of a great team, then you probably are.


In the above article, I tried to define what a team leader should consider in order to increase the likelihood of building a great agile team. I was trying to keep each point concise but each section could easily be a sizable article on its own and I’ve probably been a bit more verbose than I planned to be. However, I think if you give some concerted thought to those six aspects when you are assembling a team you’ll give yourself a good chance of building a great agile team.

What do you think? Did I miss anything or include something you totally disagree with? Add a comment and let me know.