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

Abstact

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

How LeanKit helps it’s teams make effective decisions

This week I attended an excellent talk by Jon Terry, the CEO of LeanKit, at a Software East event hosted at Redgate Towers. If you’re not familiar with them, LeanKit is a workflow visualization SaaS company based in Franklin, Tennessee. Jon talked about the approach LeanKit took to help their teams stay lean and make good decisions as they grew from a small start-up to a medium-sized enterprise.

Here’s part of the abstract for the talk:

Does this FizzGood? Improve velocity, predictability & agility by asking a simple question

LeanKit’s founding team had a strong Lean-Agile background from previous careers. So, in the early days of the company, we just instinctively did things in a Lean way with as few formal processes as any startup. But, like any growing company, we eventually did have to start clearly defining how we do things. And like anyone, we were tempted to become more bureaucratic – with lots of scheduling, coordination, meetings and estimates.

Instead, we developed our FSGD (Frequent Small Good Decoupled) approach. This LeanKit way of working has provided our teams with a simple yardstick for making effective decisions without a lot of cross team scheduling and coordination. It has simplified abstract Agile concepts into something everyone easily understands and cheerfully applies on a daily basis.

From: http://www.meetup.com/software-east/events/227959891/

So, FSGB (pronounced Fizz Good!) is simply a mnemonic everyone at LeanKit now uses to help them make decisions that align with the company direction and it’s lean principles. The concept was defined by the four co-founders of the organisation (not by an extended committee) and rolled out to all areas of the organisation (Development, Marketing, Sales, etc). It now forms part of their induction process for new hires and is referred to frequently throughout daily life at the company.

Giving teams and individuals autonomy to take decisions and providing the right-level of guidance so they can do so in a deliberate manner, consistent with the aims of a business is something I’m really keen to explore. So, here’s what I took away from Jon’s talk…

What does FSGB stand for, then?

FSGD-Words

Frequent, Small, Good and Decoupled – but that soda can looks waaaay too pleased with himself, if you ask me

Frequent

  • What? Deliver stuff frequently and at a deliberate pace – not annually, quarterly or sporadically.
  • Why? Basically, because it’s better! LeanKit is a SaaS business and Jon added “I have to resell to all my existing customers every single month”, so delivering new stuff frequently is paramount. It also reinforces all the agile goodness of continuous integration, continuous delivery, customer feedback, stress-free/low-risk releases, etc.
  • Anything else? Jon added that if you are in a high margin, fast-moving business, investing in speed of delivery will pay for itself very quickly; “it’s basically free”. If your team ask for money to get their cycle time down, you give it to them.

Small

  • What? Break work down into its smallest valuable components. Each small piece should be able to be delivered independently.
  • Why? Delivering work in small sections brings a load of benefits; reduced work in progress, increased opportunity for customer feedback, reduced risk for each individual release, etc. In fact, it’s this small batch size that really helps enables a lean workflow approach.
  • Anything else? By breaking everything down into small, valuable pieces teams may find that they are finished with a feature earlier than they expected. For instance, a development team wants to develop awesome feature, X. They spend time thinking about whether it can be broken-up into smaller units and realise that it comprises four distinct pieces of functionality. So, they put the four sub-features into a queue and begin work on the first piece – x1. They complete x1, ship it and start work on x2. This process continues until they have shipped sub-features x1, x2 and x3. However, before starting x4 they realise that feedback from their customers is telling them that they do not need it. In fact, x4 would make the user experience worse. As a result, the team decide they are done with feature X and move on to feature Y (which users are really desperate for!). The time required to do x4 has been saved and customers are happier, awesome.

Good

  • What? Things need to be good to be done, so we don’t ship garbage. At LeanKit, the definition of “good” includes something being tested, logged, documented and reviewed (known as TLDR – they love an acroynm).
  • Why? Well, shipping small stuff frequently should not be at the expense of quality. A Saas business needs to resell to their customers every month, remember? So, we can’t afford to deliver them garbage. On the other hand, “good” does not mean gold-plated. Gold plating is very unlikely to be more valuable that the next thing on your work queue.
  • Anything else? Jon is an advocate of Henrik Kniberg’s more nuanced version of the Minimum Viable Product idea. Henrik talks about the concept of a Minimum Testable Product, a Minimum Usable Product and a Minimum Lovable Product. He feels teams should go through each of these phases when building a product and not jump straight to a gold-plated, finished version. If you take this approach, good things happen (see image below or Henrik’s excellent post for more about this). This idea works all the way down to a feature level – teams should ask themselves what the minimum that would be good enough to test an idea, and make that first. They should certainly not hold onto something until (they think) it’s perfect.
mvp

Frequent, Small, Good and Decoupled – but that soda can looks waaaay too pleased with himself, if you ask me

Decoupled

  • What? Work should be independently valuable but it should also be isolated from all other work, so as not to spread risk to other areas.
  • Why? So that one piece of work does not put other pieces of work at risk. Jon added that if one small feature in a frequent release is garbage (and not “good”) it will only affect a small number of people and will not damage other things. This backs-up the drive for small, frequent releases.
  • Anything else? Keeping to this “do no harm” manta means that LeanKit can trust individuals and teams to act independently because they must ensure that their work will not damage another team or their work. This reduces the amount of cross-team co-ordination required and therefore reduces the number of coordinator-type roles in a business.

Can this be applied elsewhere?

Jon was keen to emphasise that the components that make up FSGD are not rocket science and were certainly not dreamt-up by LeanKit. However, there is a real strength in calling these principles out so explicitly in a business (growing, or otherwise), and asking the people to work there to use these idea to help them make effective decisions.

Distilling this philosophy down to a four letter mnemonic – FSGD – may seem imprecise or simplistic but it has ensured that the notion is small and clear enough for people to keep in the forefront of their minds. It sure beats capturing it in a hefty tome that no-one will ever read.

In my opinion, emphasising that things should be “frequent”, “small”, “good” and “decoupled” would be a valid thing to do at most software companies. I’m not sure the “Does this Fizz Good?” call to action or the cute soda can mascot that accompanies the concept is going to land in a (typically cynical) UK software company environment. However, being principled about how you are going to work in order to reduce bureaucracy and help individuals and teams make sound, consistent decisions certainly should.

If you want to discover more of the backstory to FSGD, there’s a related article on the LeanKit blog by Daniel Norton (LeanKit’s CTO) – Does This Fizz Good? A Thinking Tool for Faster Value Delivery.

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.

Encouraging convergence: Our project management working agreements

As I described in my previous post, the project managers in my division want to be deliberate about how we run and deliver projects. We decided to develop set of “working agreements” (or manifesto!) calling out best practices we have experienced (such as retrospective meetings) and the aspirational aims we have (such as delivering frequently) with a view to embedding these in all projects in our division and encouraging consistency.

A team's taskboard reflects their processes and practices, but how much of this stuff should be common across other projects and teams at the same company?

A team’s taskboard reflects their processes and practices, but how much of this stuff should be common across other projects and teams at the same company?

If you want to learn more about why we did this, see Encouraging convergence: Putting a framework around agile team autonomy.

Here are our project management working agreements:

Process

We will use the Scrum framework for projects.
We agreed to have:

  • One or two week “sprints”
  • Daily stand-ups
  • User stories to capture work 
  • A shared sprint review/demo
  • Frequent, regular retrospective meetings

We’ll share sprint cadence.
This means sprints on each project will be 1 or 2 weeks long and start & end on the same day across all Opportunities projects.

Each project team will be able to adapt their process and practices within this framework to suit their circumstance.
For instance, projects may have a differing level of certainty which may affect planning practices.

Purpose and goals

We will give our teams a clear purpose and good goals.
Where “good” means:

  • We will give our teams clear goals that they can directly influence.
  • We will give our teams goals that help them decide what to do and what not to do.
  • We will know if we have met the goals we set.
  • We will know if we are on target to meet the goals we set.

Teams will deliberately identify what they want to achieve in each sprint and release.

Roadmaps and themes

We will have a project roadmap for the next six months.
This should be a rolling 6 month window.
The immediate contents of the roadmap will be well-understood and certain.
The contents of the roadmap 3-6 months may be more uncertain and represent our ‘best guess’.

Project roadmaps will be broken into discrete, timeboxed themes.
These themes will be timeboxed according to the investment Opportunities is willing to make for the value.
These themes will help teams decide what to do and what not to do.

Themes will be broken down into small, independently valuable user stories.
This will be done before development begins on a theme (probably just-in-time).
The generation of themes and user stories will be owned by a product manager but, if necessary, facilitated by the project managers.

Delivery and planning

We will encourage our teams to release frequently (ideally, at least once a sprint).
We believe this is best practice and motivational.

We will adopt a deliberate, release cadence (for example, releasing every Wednesday).
We believe this is best practice; it builds predictability, keeps us honest and unlocks the release train approach.

We will use the release train technique to plan the delivery of each theme of work on the roadmap.
We use the “train” metaphor to communicate a few key concepts:

  • The train departs the station and arrives at the next destination on a reliable schedule (fixed cadence; standard velocity, predictable releases)
  • It delivers its cargo to customers (release)
  • If a team wants its “cargo” (code, documentation, etc.) to go, it has to put it there on time. The train will not come to them nor wait to get their content.

We believe using the release train will:

  • Engage the team in planning
  • Visualise the plan to deliver the current theme of work
  • Make the effects of scope changes and delays clear
  • Help us make better decisions around what we work on and what we don’t work on

We know when we expect to finish the current story and theme.
We accept that this may change as we learn more.

Continuous Improvement

Each project will have a mechanism to ‘Inspect and adapt’ each sprint.
We favour Retrospective meetings and believe running these every sprint is best practice.

We will share improvements and adaptations taken on each project with other project managers.
This can be achieved by a write-up of a Retrospective.

We will adopt good practices in other teams if there is a clear advantage or improvement to be had.
This should be reflected in this document.

We will regularly facilitate Retrospective meetings for other project managers.
This is so that project managers can participate in the meetings for their own projects.

Meetings

Meetings will have clear goals.

Meetings will be attended by the ‘right’ people.

All regular meetings will have an agenda that is shared with the attendees.

Practices

We will record decisions that have been taken over the course of the project.
We believe this will help us with consistency across the lifetime of the project and ensure all team members are aware of decisions taken in their absence.
We believe this will help new team members can be brought up-to-speed quickly.

We will encourage our teams to identify the relative priority of the tasks required complete a user story.
We believe asking teams to differentiating between ‘must have’, ‘should have’ and ‘could have’ helps us make sound decisions.

We will encourage team members to take time each sprint for personal development.
We favour doing this by using ‘gold cards’ to represent personal development tasks on team taskboards.

Cross-project Cooperation

We want the teams in the division to feel part of a larger development team.
This is so that:

  • Team members know who they can talk to in another team about a given problem
  • We are not blinkered by ‘team goals’
  • We avoid social barriers between teams
  • We are more easily able to move people between teams if a need or development opportunity arises

We want the teams to know what each other are doing and what they plan to do.
This is so that:

  • We know when work in one team will affect another team
  • We know when teams should work together to solve a problem
  • We spot opportunities to share skills and experience across projects
  • We are more easily able to move people between teams if a need or development opportunity arises

I’d be interested to hear what people think of these. Do you think they are useful, over zealous, anti-agile or just common sense?

Encouraging convergence: Putting a framework around agile team autonomy

The company I work for adopted an agile development approach in 2008. It was before my time here but, as I understand it, they trialled Scrum on a single, important project and then rolled the approach out to other teams when the benefits of an agile approach became clear.

As – rather awesomely – the company believes in pushing responsibility and ownership down to the team level and encouraging people to be undertake challenges as a group, each team became the owners of their agile process and practices by default. On the face of it, this sounds like a good thing, right? It was certainly one of the aspects that attracted me to the company; team ownership and autonomy.

Over the years, development teams have evolved, disbanded and been created. Most of the time, each team has been given full autonomy over how they work. Some successfully optimised their approach for the special characteristics and factors at play on their projects. Some were less successful.

Organically grown processes

Our organically grown processes and practices

Regardless of the success of these adaptations, what we have ended up with is a collection of teams with disparate approaches to the same mission – creating great software. This freedom has produced some really interesting innovations and we’ve been successful as a company. However, this divergence of approach has caused problems:

  • We make the same mistakes repeatedly. For instance, a single team may decide to drop retrospectives (without thinking about how to maintain a continuous improvement initiative) and that turns out to hurt the team down the line. That team learns a lesson and starts doing retrospectives again, but that lesson is unlikely to be passed-on, so inevitably another team repeats the mistake a few months later.
  • It takes a relatively long time to spin-up a new team. Each time we start a new project we go back to the drawing board to decide what our approach to software development should be. This takes time and does not necessarily build on best practice.
  • Considering we are one company, we find moving people between teams can be difficult, as each move requires people to learn about a new way of working. In management-speak, this harms team liquidity.
  • Best practices and good ideas that have worked are, in general, not shared as teams can be resistant to ideas from outside.
  • Comparing projects is pretty difficult, so it can be hard to determine if they are struggling and need help, or if they are on track. Measuring progress on each team requires an understanding of exactily how that team works.
  • We can find it difficult to collaborate across projects, because we are all different – we have different practices, different cadences and different traditions.

We could solve these problems with strict processes and low-level governance, but that would be a bad thing, right? Ideally, we’d like to avoid this stuff but allow teams the freedom to do what it takes to solve the special problems and issues that are tied to their circumstance – that is, to allow them to ‘inspect and adapt’. Our view is that we should be deliberate about how we run and deliver projects, but not dogmatic.

Therefore the project managers (who are effectively team leaders) in my division decided to develop a set of “working agreements” calling out best practices we have experienced (such as retrospective meetings) and the aims we have (such as delivering frequently) with a view to embedding these in all projects in the division and encouraging consistency.  We tried to identify the right things to do in the general case, to find universally useful practices that would be of benefit in most cases. We did not gather a superset of all the practices across our teams, with a view to homogenize every aspect of how we work.

The idea is that these working agreements form a framework for how we run projects in the division, so that new projects always have a solid starting point and the fundamentals of how we work remain broadly similar.

Our project management working agreements

Our project management working agreements

We have explicitly declared that projects can diverge from these agreements. Certain jobs will have special characteristics or other factors that suggest a different approach. For instance, an exploratory prototyping project is unlikely to require a 6 month roadmap! In these cases, we have agreed that divergences from the agreements should be discussed with our colleagues, so we all understand why they are happening and share new practices.

Furthermore, improvements and optimizations within this framework are encouraged for each project. Following a retrospective, the team may decide it would be advantageous to formally adopt TDD for their next feature. This kind of adaptation needs to be able to happen locally, without the need for consensus across the division’s development department. We want to reflect and embrace what we learn as software development evolves (e.g. the movement towards continuous delivery), so the agreements are a “living document”, open for negotiation and improvement, driven by local optimizations.

Our working agreements have served us well so far and we’ve still learnt new things to evolve our approach. In fact, we’ve recently gone through a review of our agreements and have made some changes to reflect what we now think is best practice for projects in our division. For instance, we have agreed to use a release train technique for continuous delivery planning.

The project managers got together to review our working agreements and bring them up-to-date

The project managers got together to review our working agreements and bring them up-to-date

I’ve shared our working agreements in my next post. Please take a look, if you are interested.

Down with the annual appraisal!

Applying agile to people management

As we near the end of the year, people managers across the world will be aware of the looming, ominous shadow of a well-known nemesis – the annual appraisal process. In a vain attempt to avoid identification, this sinister entity also goes by the name ‘end of year review’. In either case, tackling this foe is a thankless task, requiring managers to succinctly sum-up the performance of their line reports while simultaneously developing, motivating and realigning their people. Worst of all, this has to be delivered via a single formal meeting and/or tightly regulated document. Joy.

At Red Gate (my employer), we don’t do annual appraisals. As far as I’m concerned this is a good thing for two main reasons:

1. Annual appraisals don’t work. Certainly as far as them being an effective method of developing people, recognising good performance and identifying opportunities for improvement. They are destined to fail for many of the same reasons that Waterfall software development projects are destined to fail:

  • They involve up-front requirements specification (a.k.a. annual objectives) which fail to respond to the changes that happen throughout the year and don’t encourage people to take advantage of any unforeseen opportunities that may arise.
  • All parties/functions involved in the process work separately on the same project and pass documentation to each other as a means of communication. This leads to misinterpretation and misalignment.
  • They are Big Bang; involving a single, high-value release (appraisal document) that is often unsatisfactory to both parties and contains unexpected content.

2. Annual appraisals are a massive overhead; they take an age to put together. Everyone involved struggles to remember anything beyond the last few months. Additionally, setting meaningful objectives for the whole year is nigh on impossible and time-consuming.

So, at Red Gate we don’t do Annual appraisals, because they’re clearly broken. Instead, we take a more agile approach.

Agile people management

At least once a month, each employee has a “one-to-one” session with their line manager; just the two of them, catching-up, for 30 minutes to an hour. Each monthly meeting is treated like a mini-review, with the employee leading the discussion on what has gone well and what hasn’t gone well in the last few weeks (amongst other things). At the end of the session the two participants agree short term goals, changes and actions for the next month. They’ll review these at the next monthly meeting.

For the line manager, these meetings tend to require a coaching approach rather than a directive one. In any case, regular one-to-ones are an opportunity to recognise great work and give constructive feedback much closer to the actual event than a yearly appraisal allows. Problems don’t get time to grow and fester. New opportunities can be quickly taken advantage of.

Monthly one-to-one sessions work for many of the reasons agile software development works:

  • They focus on repeated, short time periods that can easily fit in your head and be reasonably planned. These iterations can be chained together to deliver a larger  changes.
  • Everyone involved works together on the task, sharing insights and quickly surfacing disagreements.
  • Work is delivered regularly, progress is clear and information is fed back into the process to improve work over the next time period.

Whilst many software development organisations encourage regular one-on-one sessions between managers and their direct reports, they still keep the annual appraisal process as a method of officially measuring performance and developing people. I’d argue they are missing a trick and should start applying the agile techniques they have honed on software projects to their people management processes too.

In a future post, I’ll write in a bit more detail about exactly how I run one-to-ones with my team.

How to deal with a dissenting voice in the team

As leaders of experienced, skilled and knowledgeable staff, we want team members to be able to speak up and disagree with something they don’t think is right. We want people to highlight the problem that no-one else has thought of.

Swimming against the tide

Swimming against the tide

However, a dissenting voice can be very disruptive when it goes against the goals, direction or well-being of a team. It’s especially destructive when this disagreement comes down to personal preference or an individual putting their own goals above those of the team. Some team members can be repeat offenders when it comes to disagreeing with an overriding team decision. If you are a team leader and those characters exist in your team, then you know who they are.

A disagreement can be about something as benign as whether or not to fix a low-priority bug, or as caustic as whether retrospective meetings are a valuable use of their time. Team leaders can sometimes feel unable or ill-equipped to challenge a strong individual’s dissenting opinion. They may be tempted to sit-back and hope that they quieten down or that the team’s consensus wins out. However, that kind of procrastination can lead to problems snowballing, a lowering of team morale and divisions forming within the team.

For the good of the team dissenting opinions should be noted and addressed as soon as possible. It can be tempting to make the incident less personal by bringing-up the disagreement in a team context like a sprint retrospective meeting – “I understand some of us think that this is a bad idea”. I think this is less effective, as the individual you are ultimately trying to reach can metaphorically opt-out of team discussions and decisions.

Instead, as soon as you notice a dissenting voice that has the potential to derail the team, I’d recommend taking the individual aside as soon as is feasible and having a private conversation. I’d probably structure the discussion something like this:

  • Explain the situation; that the team have reached a consensus, or are tackling agreed goals, and you’ve noticed that (s)he disagrees.
  • Reiterate why the team are doing what they are doing. Be open.
  • Ask the individual to help you understand why they disagree.
  • Discuss the impact this disagreement could have on the team and its success.
  • Ask the individual what they can do to move forward. Can they agree to get behind the decision of the team or team leader? Perhaps they can raise their ideas more constructively?

Asking the dissenter what they can ‘do’ about the problem is a vital part of the conversation but can often best missed. By asking, you put the onus on the individual to improve the situation and make it quite clear that there needs to be a change. This isn’t always a comfortable discussion, which is why it is tempting to avoid it. However, by tackling the problem head-on leaders can nip team dysfunction in the bud and protect goals and morale.