During the recent Maxwell Bond Webinar (kindly organised by Riana Butler) on “Agile Project Delivery” I sat as a panellist.

There was an impressive turnout and some outstanding questions posed by the attendees. One of the queries revolved around any “gotchas” for setting up agile teams remotely.

This piqued my interested as agile and remote working do capture the current delivery zeitgeist.

Having been lucky enough to deliver Enterprise projects for the likes of ITV, Aldermore Bank, and Maccabi Tel Aviv FC (Israel) with teams in situ and from diverse a location as Swansea and Minsk it did get me thinking about my own experiences in setting agile teams up…

When my project team and I rolled out an agile delivery method for a large Trinity Mirror Plc owned agency, we did encounter issues, and these five tips should help make the transition smooth be it remotely or in situ. 

1. Get Buy-in

This is something we discussed in the webinar and the starting point for any change in the delivery process. Without support from the team (at all levels) rolling out a new way of working (agile or other) you’ll be fighting inertia – as change does come with risk and this makes people nervous. 

Ignore this at your peril.

Some of the most useful allies are going to be team heads. They are invariably already aware of programmatic / process ways to make the teams output better, and they are probably going to be glad to have someone to help support any improvement in the day to day delivery of projects.

The best way to get buy-in from any team is to explain in their language how the approach will benefit them. 

This can even be how it serves their team – for example, if a team lead has members of their squad complaining the Prince 2 specs are a pain to write, not being read and taking too much time, the prospect of working software over comprehensive documentation (e.g. using user stories) is going to be great news to them.

Explain why, and how it helps the team. You’ll need to change the tone and message for each group of people you’re addressing this to. Financial controllers will need to know figures; Project Managers will need to know you’ve got their back with training and support, and marketeers will probably want a blog post from you about it.

There WILL be people who’ll resist and go through the Kubler-Ross change curve, and this is entirely normal do not take it personally. 

Changing a process may cause them more work in the short term, and asking them to take this on the chin won’t reflect well on you as a manager.

Show understanding and share the bigger picture of how an agile approach is likely to make their life easier in the long run. Get them involved in the process, so they feel like they’ve got some control and try to minimise any additional work they need to pick up by spreading the load to other less busy team members who have already bought into the process. 

Remember one of the principles of the agile manifesto is “Responding to change over following a plan” so anyone who has signed up to the new approach should be more than happy to help. 

A buy-in pitfall I’ve seen is not including as many teams as possible. An excellent example of this is the commercial (sales) team who often get left out usually because they’re not part of the delivery team, or simply because they are sat on a different floor from everyone else. 

It’s likely that they won’t necessarily have an understanding of the new approach, and yet they may have been saying the company is agile in sales pitches already. Hold their hands and guide them – not only did I offer to get involved and engage with potential clients on the new approach (fielding questions in pitch meetings is great fun), but I also provided some bullet points for the pitch and tender documents.

This helps the commercial team by taking some of the onus off them; it also means you’re vetting the information going out to clients – an agile approach isn’t a magic bullet and the benefits (and responsibilities) need to be explained carefully to get the maximum from the framework. 

2. Start Small 

The very nature of agile is the iteration – small, manageable chunks of work which can be completed and reviewed in a set time.

This is an excellent way to introduce an agile way of working too. Pick a suitable team (e.g. one who’s bought in and is mature enough to be able to take the extra responsibility) and get to work. 

Run a few sprints and see how the culture of the company copes with a new way of working.

If there are any blinding issues, you’ll be able to deal with them in the one place rather than having to pick up a company-wide problem. Problems are also likely to surface pretty quickly. They may revolve around tools which are being used and reporting – this is especially true when a new team is working on a new project, and they are not sitting together.

3. Facilitate

There is a wealth of paid and free to use software out there. Do not get overwhelmed by the sheer number of systems you can use.

One error I’ve seen is an over-reliance on too many software solutions. It can create noise and form a natural barrier to people picking up. You might save a few pounds on licence fees, but you will waste a lot more in non-billable hours. It is likely to be the biggest hurdle in getting buy-in from the people doing the work if they have too many places to consult before even starting their tasks.

We kept it simple – JIRA for user stories/time recording and Confluence for documentation. Teams could link out to Google Docs or drop in PDFs, but the single source of truth was the twin pillars of JIRA/ Confluence. 

This made outputting reports (to show progress – see below) easy and we could open the system up to internal and external stakeholders for full transparency without having to worry about permissions on old drive systems or accidentally sharing the wrong Google folder.

Remember, one of the principles of the Agile manifesto is “Individuals and interactions over processes and tools”. Be flexible in your approach, and if something isn’t working, or there’s rational resistance to something you’ve introduced, listen to the team, embrace change and let them offer an alternative solution.  

It will be your responsibility to review and control these, so note the use of the word “rational”. 

A principle of XP (Extreme Programming) is co-located clients and teams. Sitting together when setting up a remote Agile team isn’t going to happen. 

Although software tackles the “work” aspect of this (access to information to do the work) one of the advantages of being in the same room is natural rapport begins to form. 

The team will get coffees together, pick up on each others mood (good and bad) and find common ground as friendships start to form. As a manager, it’s way easier to foster a positive culture or nip an issue in the bud when located with the team.

Working remotely can hinder this affinity, and as a project lead, you’ll need to cultivate ways to create this rapport. Not all people want to do quizzes, enjoy socialising or get involved in banter. Invite people who might not want to get involved with ‘the usual’ to suggest something they’d like to do. Chances are the others will follow.

Be empathetic to the individual’s needs and work extra hard to ensure the team members are contributing to standups and are engaging in sprint reviews. Sometimes those with the most useful points might be the ones holding back for fear of ridicule or lack of confidence in groups. 

Running remote sessions is a lot like fossicking, there can be a lot of grit to get through and then out of nowhere a nugget of gold appears. When it does make sure, there is credit where credit is due as this will help build trust.

One pitfall is making sure you fill all roles if you’re using a specific process. Technology cannot fill this for you. A common mistake is missing out a Product Owner in Scrum (or the Product Owner not engaging). This is like having a ship with no navigation, sooner or later you’re going to hit rocks.

It’s your job to do the hard work and let the team as a whole benefit from the contributions. 

4. Show Progress to ALL Levels

It’s not just the team working at the coal face who need to be kept up to date. Ensure that everyone is aware of the situation, what is working and what is not. 

This can be an opportunity to use some of the software in the “facilitation” note above along with agile principles. 

It was illustrated nicely by Tom Reynolds during my CSM training in the form of a Kanban Board as we went through the training. The group could see where we were up to and what was happening next as a visual flow.

Importantly here be aware of pitching progress in the appropriate way for the audience. KPI’s will work well for some (e.g. number of teams working in Agile or projects complete) others may like more detail.

Involving Team Heads and empowering them to update their teams on progress not only takes some of the work load off you, but it also helps with the original point of getting “buy-in”.

5. Lead by Example

This is the most important tip out of the five as it will assist in the success of each one.

When I advocated the agile method, I moved into an Umbraco team and picked up the projects which needed to be delivered in a new way with my tech team lead. 

I loved getting my hands dirty, and it showed the other teams that I was following the same rules as I had laid out. As a manager, I have always talked the talk and then walked the walk. 

Sure it’s hard, and you’ll hit issues along the way, but this is where you can shine and use those skills. 

Make sure you’re always early and at the very least on time for the standups. Keep them (and other ceremonies) consistent in terms of the dial-in details and agenda (especially crucial for new people joining). 

I’d often give the team any minor updates (such as when I was away or polite reminder on bank holidays) at the start of the standup to ease them in, and let the tech lead have the last word. Bookending in this way adds to the consistency, especially when you’ve got a team which might be spooling up and down with different members as the project progresses.

If there are blockers, make sure they’re removed. In retrospectives keep the team up to date on what you’ve done to help them, even if something is not fixed (sometimes bulldozing blockers takes a while) they’ll respect you for it. 

If anything making sure you’re on top of these meetings and documents is even more critical when you’re working remotely as you’ll not be able to have that conversation in the kitchen over a coffee. Team members can log into Confluence and have a look at what has been done, having detailed notes in there shows them you’re on top of it.

Final Thoughts

Agile isn’t for every project; it embraces change (and expects it). If you’re regularly delivering projects which are less than three sprints (e.g. four weeks) and are repetitive (i.e. you do the same thing), then it might not be worth looking at agile.

My experience was moving from waterfall to agile the teams went from a group of people working on a project to a team delivering a common goal. 

Working this way remotely will take a little extra effort (especially if you’ve not worked this way before), but the result will be well worth it.

Some useful links to have a look when you’re ready to make the leap:

Scrum Guide

https://www.scrumguides.org/scrum-guide.html

Scrum Manifesto

https://agilemanifesto.org/

JIRA / Confluence

http://atlassian.com/