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

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?

When the going gets tough, don’t cancel the Retro

If times are tough on an agile project, whatever you do, don’t cancel the Retrospective meeting.

Let’s be clear, cancelling that meeting is removing an opportunity for the team to inspect the way they have been working, and adapt how they do things so they can improve.

Stop Start Continue

That’s an opinion I’ve held ever since I started working on agile projects back in 2008. It just seems logical to me. I had a conversation this week that reinforced that position.

I was chatting to a couple of members of a development team over lunch about their project.  They couldn’t really stop themselves from complaining about some difficulties their team had been experiencing over the last few months. They highlighted a few issues that they felt could be improved and discussed how they’d like to change aspects of how they work together. My overall observation was – they seemed pretty fed-up.

When I asked if they felt they could discuss these worries in their next sprint retrospective meeting, one of them told me how those meetings had not really helped solve their problems in the past. In any case, their team felt they spent too much time in meetings in general, so they had decided to change their process and only have retrospectives at the end of every other sprint. As a result, they had a retrospective meeting once a month.

I recommended that they have a retrospective as often as possible, given their description of the project. One of the team members stopped me and said, quite matter-of-factly and without a drop of irony, “Some of us, Chris, have a more pragmatic approach”, he shrugged apologetically, “we just prefer action over meetings”.

He looked at me somewhat condescendingly, eyes filled with pity as he considered my misplaced faith in a meeting. How could a group of people coming together to talk about stuff be preferable to actually ‘doing things’?

Somehow I managed to stop myself from slamming my forehead into the table in disbelief. I also avoided making the suggestion that the pragmatist’s preferred action seemed to be complaining about the problems they had, rather than trying to resolve them. I did, however, embark on a robust cross-examination of what was meant by the term “pragmatic”.

My recommendation to the two colleagues (who are good guys, by the way) was to not give up on retrospectives but to talk to their manager/scrummaster/facilitator to see if they can design a meeting together that would help them tackle their problems. And they should definitely have a retrospective every sprint.

I described the kind of retrospective activities that might help surface and explore the issues they were experiencing. A teamwork satisfaction poll, perhaps? Or a Mad/Sad/Glad activity? This seemed to gain some traction with the other team member, who went away to talk to the facilitator earmarked for their next retro.

Teams can label the time they spend in retrospectives as worthless and futile. Often, this is because they’ve experienced some poorly run or structured meetings that have failed to produce valuable, insightful actions. In these cases, I’d plead with a team not to give-up on retros and suggest reading Agile Retrospectives by Derby & Larsen to give their meetings a better chance of success.

Teams have been know to cancel retrospectives if they feel like they are under too much time pressure and are forever racing to reach difficult deadlines. For me, taking time away from your desks to reflect on what is going on when a project feels like it is in a perpetual race against time, is invaluable. To be honest, if you think that having the team in a meeting room for one hour every two weeks is going to make your project fail, then it’s going to fail anyway.

So, if you are on a difficult project and are considering cancelling or reducing the frequency of your retrospectives, ask yourself what the root cause of that drive is. Then consider whether that root cause is something that would actually benefit from a regular, frequent opportunity to inspect and adapt.

Laying the track as we go: New product development and the Agile Release Train

The ‘Agile Release Train’ has been popularised as part of the Scaled Agile Framework – a set of guidelines aimed to bring agile software development to the enterprise and programme delivery. In the framework, the train metaphor is used to describe a series of iterative releases set to a strict schedule that multiple teams must abide by in order to synchronise and ship their work.

Laying the track as you go

Laying the track as you go

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) or is used for internal evaluation and proof of incremental system robustness and quality (PSI/Release).
  • If an Agile 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.

From http://scaledagileframework.com/agile-release-train/

I’m fortunate enough to work at Redgate – a software house based in Cambridge, UK. At the moment we don’t have a need for the Scaled Agile Framework and all it’s rigourous, and potentially overbearing, process and procedure. I predominantly work with a small software development team (5 to 10 people) focused on a single product, with relatively little need to share work across multiple teams (certainly when compared to a large enterprise-y development programme). This could well change in the future, as we’ll be pushing to synchronise efforts across teams much more regularly. But at the moment, scaling agile is not something on our todo list.

Release Wednesdays

In the last few years, the teams I’ve lead have decided they like to to release their products every week. Every Wednesday, to be precise. Why? Well, I’m a bit torn on how to answer that. The project manager part of me says it’s because we believe in releasing frequently to give our users valuable enhancements as quickly as possible and to get timely feedback on the direction we are taking the product. The developer part of me says its because we get a kick out of putting the stuff we’ve created into the hands of people who’ll enjoy using it as soon and as often as we can.

In any case, by releasing every Wednesday we’ve proved that releasing frequently is best practice, as we extoll the virtues of keeping the delta between releases small and the risk associated with an individual release low. We’ve also found that practice makes (almost) perfect and that the more often we release the easier and less distressing it has become.

We choo-choose the Release Train

Although, I’d used the term ‘Release Train’ with the team for most of the time Release Wednesdays has been a thing, it’s only in the last few months that I have explicitly used the concept to help the team plan, visualise and track their work. I don’t think it’s an exaggeration to say that doing this has been transformational.

The SQL Lighthouse Beta Release Train

The SQL Lighthouse Beta Release Train

The catalyst for a more formal adoption of a Release Train was a realisation that my current project, SQL Lighthouse, had a significant deadline looming that we had no clear plan for how to meet. To be more specific – the team, as a group, realised that for SQL Lighthouse to be a success this year, it was paramount that we had a public beta of the tool ready for a Redgate’s annual London conference.

Once the target was agreed, the team set about deciding what needed to be delivered in order for this to be achieved. We decided on a single, valuable use case we would support with the Beta release and broke the required functionality down into the smallest possible chunks (we used User Stories for this). We then looked to our weekly release cadence to help us decide if this was, in fact, an impossible task.

We wrote up the dates of the 6 weekly releases that would happen before the deadline and placed cards detailing each chunk of functionality under those dates. We were then able to quickly arrange, prioritise, and re-arrange the chunks into a reasonable plan. The entire team gathered around the wall discussing, pontificating and worrying about the plan for the upcoming work – it was the most engaging planning activity I’ve experienced.

Although we’d managed to get each chunk of work down to a small, reasonably independent unit, it was clear that they wouldn’t all take a week or less to complete. We didn’t spend too much time worrying about an exact (or even relative) size, as a group we took a guess at when it could be shipped and moved on. So, if the team believed it would probably take two weeks to complete a particular chunk, it was quickly assigned to the subsequent release. A key point here is that the team realised they were making a informal guess and trusted ‘management’ not to hold them to their hunches.

In the end, we fashioned a release plan made up of 6 weekly, iterative releases. Vital functionality was front-loaded into the early releases and nice-to-haves had settled at the end. As each release was scheduled for a Wednesday, and any functionality that was not ready for that day would have to wait for the following Wednesday – we had an Agile Release Train (see below, cut-out train and carriage wheels were an optional but metaphor anchoring extra).

The SQL Lighthouse Beta Release Train

“Plans are useless, but planning is indispensable”, Dwight D. Eisenhower

Of course, as soon as we’d drawn up the plan it was out of date. If Agile has taught us nothing else, it’s taught us to expect change. So, during the next six weeks we kept the Release Train up-to-date and relevant. It reflected functionality we had shipped, the proposed contents of the next release and any realisations that we just couldn’t get something done for when we’d hoped we would.

Importantly, the whole team took part in analysing the knock-on effects when a piece of functionality (or cargo, to keep with the analogy) missed a release we had earmarked it for. This prompted releases (carriages) to be re-arranged, functionality (cargo) to be juggled and scope-creep (baggage) to be jettisoned. We were all engaged in the process of project planning.

As I detailed in a previous post, the plan and the planning worked – the team met their goal of releasing by the important trade show and in the process transformed the product from a proof-of-concept alpha into a genuinely useful tool. As a direct result of that success, the Release Train was here to stay; we’ve applied the metaphor to every step we’ve taken with SQL Lighthouse since.

The next Release Train: Get 250 users onto the Beta

More than just a release plan

As I reflect on how we do software development on the SQL Lighthouse team now, it’s interesting to note the side-benefits that the Release Train has brought; including small user stories, #NoEstimates, collaborative planning and implicit scope management. This has turned into a long post, so I’ll cover those in my next one – 5 benefits of the Agile Release Train for a single team.

Hello, SQL Lighthouse: Meaningful deadlines FTW

SQL Lighthouse

Last week, my team released a beta version of the product we have been working on for the last six months – SQL Lighthouse.

This week, everyone on the team has been reminded how motivating it is to see an idea you’ve been working on start to gather recognition and, more importantly for us, users. At the time of writing (October 28th), we’ve seen our ‘active users’ figure (installations of the product that have seen some actual usage) surpass our usage target for the end of November by 160%. The product and the team have a long way to go, but we certainly feel we’ve proved that we are on the right track.

What does SQL Lighthouse do?

We built SQL Lighthouse to allow DBAs and database developers to identify and respond to damaging ‘database drift’. Database drift is where the state of a database has moved away from its expected or desired state over time, and it’s usually a bad thing. SQL Lighthouse will track database schemas, continually looking out for changes. It will then notify users of any change and give them valuable information about it. Users will be able to get to the bottom of any unexpected schema change and start making things right.

For more information, please visit the SQL Lighthouse product pages: http://www.red-gate.com/products/dlm/sql-lighthouse/

The story of the beta release

The run-up to the release of SQL Lighthouse’s beta version was probably the smoothest, most focussed and least stressful significant release phase I’ve experienced in my 15 years in software development. The primary reason for this was the talented team working on the project – no question. However, I’ve worked with great teams before and ‘big’ releases have seldom been delivered in such a controlled way.

The SQL Lighthouse Beta Release Train

The SQL Lighthouse Beta Release Train

The day after the release I spent a little time considering what I thought the success of the release was down to. I decided that three things had made a significant contribution:

1) Our weekly deployment cadence (which I’ve written about before, in relation to my last project) – meant that we could measure our progress in ‘stuff delivered’ and were never far from a shippable build

2) Our ‘release train plan’ – gave us a clear, visible illustration of what we had to deliver each week to meet our goal (image above and a subject I explored further in this post)

3) The team’s belief in the meaningful deadline we had set for ourselves – meant the entire team engaged in scope management and release planning on a daily basis

I find the third point particularly interesting because I’ve generally tried to shield my teams from project deadlines by which they MUST finish their work. The pressure of a deadline can make teams do inexplicable things – like cut corners with quality, ignore risks, work into the night and discard their principles. Plus, deadlines lead to estimates, and estimates are of the Dark Side.

However, today I sat in a retrospective meeting with my team as we considered what we learnt during the beta development phase. We spent time considering what aspects of the way we worked during that period should be kept and what should be jettisoned. Interestingly, the clear consensus in the room was that the three initiatives I called out above should stay. Yes, the team literally asked for deadlines.

Was this turkeys voting for Christmas? I don’t think so think.

The difference between the deadlines the team want, and the deadlines often handed down from ‘senior management’ at employers more domineering than our own, is that they should be meaningful and real. That is, meeting a deadline must clearly be tied to the success of the group and their endeavour. That way the deadline can be adopted by the group, rather than applied from outside the group in an oblique attempt in increase productivity.

You see, six weeks before the eventual beta release date, the team had set themselves the challenging target of releasing a public beta in time for Red Gate’s annual conference in London – SQL in the City. Why? We did this because, as a group we realised that for SQL Lighthouse to be a success this year, it was paramount that we had a public beta of the tool ready for hundreds of Red Gate users to see on the display booths and then go back to their office to download and try for themselves.

Furthermore, for the release to be compelling we needed to add three major features (audit, email alerts and set-up validation) and overhaul the look and feel of the entire application.  We discussed the relative priority of these changes, scheduled them to the cadence of our weekly releases, accepted the plan was achievable but tight and went for it. But above all, we all believed that meeting this deadline was vital to our success.

Stay on target

To their great credit, the team met the goal of releasing by SQL in the City and transformed the product from a proof-of-concept alpha into a genuinely useful tool. Before you ask: they didn’t work crazy hours, they didn’t hack code in and they didn’t abandon their principles. They continued to ship a release every week during this period, which helped garner feedback from our alpha users on the new features, gradually improve performance and iron-out issues.

If you want to know more about SQL Lighthouse’s journey from product idea to beta release, read Alex Yates’ (SQL Lighthouse team member and technical sales guy) excellent post The Story Behind SQL Lighthouse.

The success of weekly releases

Back in August last year my team and decided to release our product on Wednesdays.

In fact, I said we were going to release every Wednesday.

At the time, our deployment processes were already automated, we were breaking our work down into small valuable chunks and our automated test suite was comprehensive, trustworthy and performant. However, we were keen to get away from the ‘opportunist’ release process we had fallen into, where we released whenever an opportunity arose. This resulted in an irregular deployment cadence and had the side-effect that we were continually agonizing over whether ‘now’ was a good time to ship. ‘Release Wednesdays’, our initiative to release every Wednesday and only on Wednesdays, was intended to fix that while ensuring the product code was in a constantly shippable state and we didn’t swamp our uses in new version notifications.

So, what happened? Well, since the inception of Release Wednesdays six months ago, we’ve released our product 23 times and have settled into a really solid, comfortable deployment cadence.

Weekly Releases

When discussing our frequent, regular releases I find myself using the metaphor or a train running to a timetable. It helps to communicate a few key concepts of our approach:

  • Releases happen on a deliberate schedule
  • A release delivers cargo (features, bug fixes, enhancements) to a destination (the users)
  • The team needs to get its cargo ready in time for the next scheduled release. If they miss that, then the release will not wait for them and the cargo has to wait for the next scheduled release.

As an aside, this model is often used in a multiple team environment, where a number of development streams need to be synchronised in order to get a release out of the door.

Release Wednesdays are a success!

We’ve found that there are many benefits of our weekly release cadence:

  • Users get valuable new functionality sooner – if we feel that users will get value from a partially complete feature (where the ‘complete’ part has been fully tested), a bug fix or a usability enhancement, then we ship it on the following Wednesday.
  • We don’t need to do ‘special’ builds – because our next release is on average only 3.5 days away, we never need to do special (a.k.a. private) build to help individual users get around a problem.
  • We are better at releasing – we’ve practiced, we trust our automated tests and we’ve streamlined our process.
  • We don’t ship broken releases – even though we release much more often than we used to, we have not shipped a release we have had to recall since we started Release Wednesdays. That’s because we’ve kept the delta between releases small and the risk associated with an individual release low.
  • We don’t spend time worrying about when we should release – if it is not a Wednesday, we don’t start the release process.
  • We are always releasable – we’ve had to organise our development environment so that we are always ready to release. That means using the likes of feature branches, tiered automated tests and continuous deployment into a test environment.

Our Release Wednesdays initiative has been a great success and it’s something the team are pretty proud of.

However… last week we did not release on Wednesday

This was because our new ‘cargo’ was not ready to deliver to our users. This was not unexpected, because we had estimated that the feature we are working on – the automated clear-up of old deployments on agents – would take two weeks to complete.

It’s quite normal for us to be tackling a feature that takes longer than a week to develop. In the past, in parallel with this feature development, we have also worked on bug fixes or usability tweaks that, when complete, are valuable cargo in themselves. Some features we work on give the user a valuable new capability even if they are only partially complete. So, we ship that cargo on our weekly release schedule.

What has changed over the last few weeks is that the team have become concerned that this parallel development is slowing down the delivery of important features we’d like to give users as soon as possible. This issue came up at our most recent fortnightly retrospective meeting; the team were disappointed that we had not delivered what we had wanted to in the previous sprint. We decided that this was because, between all team members, we had worked on four or five discrete pieces of work at the same time. To tackle this issue, we decided to reduce the work the team is allowed to undertake in parallel to be two work items (stories, bugs or enhancements).

This experiment has had the desired effect, as progress on our current feature has been excellent. We’ve ‘swarmed’ on that one thing – meaning the entire team has worked on developing a single feature. You can see that from the picture below showing the team’s faces on the whiteboard, representing what people are working on. The team members’ avatars (cheesy pictures) are close together (all three rows are for the same feature, btw). In addition, everyone understands the feature at a technical and functional level, and it truly feels like the team’s work.

Swarming on a story

However, another result of this focus is that because the feature, a two-week sized piece of cargo, was not ready for delivery on Release Wednesday. As we hadn’t worked on anything else, there was no new valuable capability for us to put into the hands of our users.

David, one of the development team, summed this up really well:

“I see it as being a trade-off…

On the one hand we want to progress a number of different things so we have lots of small, valuable stuff to give to users every week. On the other hand we want to finish the most important functionality sooner, getting everyone swarming on the same feature and feeling like a true team.

Because we think about continuous improvement, we’ve decided to change the balance in favour of finishing features, right now. However, we’ll look at what happens and may decide that we want to shift the balance back, or that what we actually want to do is break our features into smaller, valuable parts”

In summary: the team are still committed to Release Wednesdays, we’ve just decided to focus on adding one new feature at a time. Users will get the first one of those features this week. On Wednesday.

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).

Swarming

Swarming

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.

Epilogue

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.