Distributed Agile – just an agile team working from home?

For the last few years, your organisation has adopted Agile – you were scoping projects, talking about T-shirt sizing and assigning product owners.  It was bedding in nicely. 

Then Covid-19 come along. You quickly moved to remote-working, and it has worked reasonably well… in fact, you implemented a Distributed Agile approach.  

Now, as we slowly exit lockdown restrictions, your organisation is likely to move to some form of hybrid working.  What impact will this have on your Agile or Distributed Agile approach? Is there a risk of getting stuck in the middle?   

Theory vs Reality: “Better to meet in person” vs “I am not in the office (or the country) that day.”

Many senior leaders pronounce that ‘our people and teams are more productive when they’re together in the office’.  But is this not ignoring reality?  Technology, geography and work preferences are making it highly unlikely that even mid-size teams are all in one room at the same time.  Instead of making compromises in pursuing the theoretically best solution – “John and Eva will just call in, the other four on the team will be in meeting room 2” – you should optimize the best practical solution: Distributed Agile.

Making Distributed Agile work for you; our lessons

For 10 years we have been running Distributed Agile, defined as team members and 3^rd party resources split between multiple office and geographies. At psKINETIC we support clients implementing intelligent automation solutions.  We use low-code technologies and implement at speed; we want go-live within 90 days and then fast iterations for future releases.

In this blog, we try to answer the key questions and lessons learned in regard to Distributed Agile and consider how you can implement it to achieve a permanent, effective approach whilst ensuring your teams remain high-performing.

Does it require a different Team Structure?

No, you can use the same team structure, but we have added more rigor in defining the roles & responsibilities upfront.  When mobilizing a new team there is always the initial friction cost for that team to bed in.  In a distributed model, you do need to invest more upfront and spend time to ensure you kick off on the right note.

Should we have any in-person meetings?

Normally, we would bring some members of the offshore team together with the with onshore team to build relationships.  Do we still need to do that?

In our opinion, this has never been required.  The challenges with onboarding technical resources are typically defining business objectives and gathering feedback directly from end-users.  Bringing a group of onshore and offshore developers together will not solve these.  Given that businesses are increasingly dispersed (whether home working or across geographies), you need to find smart digital ways.  We find a combination of video calls, recording of meetings and individual screen sharing can work better than being on-site. 

What changes to the sprint cycle/team management?

Our sprint cycle and steps have not changed, but we do focus more energy on making sure processes are bedded in, consistently.  Overall, more process discipline is required e.g. one team thought a feature was 5 story points, another team thought it was 13 points. We actively worked and talked across teams to get the benchmarks and consistency right. 

How to ensure coaching and feedback?

This is the part that has taken the most thinking. Great teams are led by great managers. Tech or team leads are successful based on their relationship with, and coaching of, team members.  Leading a remote team is very different, you can’t read body language as easily or have the 10-minute corridor conversation.  We have invested in additional training for our managers, so they build the skills to lead remote teams.

Changes to reporting?

Reporting is critical to the successful delivery of a Distributed Agile model.  We set clear internal metrics for teams based on story points per hour & defects. We look at these at an individual developer level, monthly, and are not afraid of putting names against results. Based on that basic principle of if you measure it, report it, then you can manage it.

This individual developer reporting is crucial in uncovering coaching needs or technically focused training.  Without it, developers cannot reach their full potential.  

Respecting personal & cultural differences?

Think about it and talk about it!  Here is an example from a project: Daily stand-ups were at 9am UK-time, which wasn’t great for the India team as they took lunch then, as a team…but they didn’t want to say anything or cause trouble.  Now, as part of project mobilization, teams talk about cultural differences and working practices and agree on what works best for all team members. Small fix, big positive impact!

Right work in the right location

We have the mindset that all developers are equal irrespective of location, so on that basis, we should push all work to the most cost-effective geography.  We have found that does not deliver the best outcome; so, we profile the work – how much stakeholder interaction, collaboration between teams / geographies, UI / UX needs, etc. These are bigger factors in determining which resources we allocate to projects. Of course, we also take GDPR considerations, or particular client security requirements, into account.

Rule: Everyone in the room or everyone on video

You know the typical ‘meeting’ with 4 or 5 people around a conference table, plus 2 or 3 people calling in.  This format is seldom very productive (certainly not for the 2 or 3 calling in).  Although some things are easier done in-person – activities such as complex design or troubleshooting an issue are theoretically better when people are together around the whiteboard…but given logistics, this rarely happens. 

We follow a strict rule of ‘either everyone in the room or everyone on video’.  In our hybrid model, we do bring the team into the office (subject to the everyone in the room rule) for activities such as sprint planning, design and retros.

Rule:  Cameras always on

It is a meeting!  You would not hide your face from colleagues in a meeting.  Keep cameras on, it is critical for engagement and supports the building of relationships.  A video meeting is not as good as meeting in person but with practice, it is becoming surprisingly effective.

You have to go further to encourage participation, you have to be more deliberate in ‘going around the room’ and gently encourage everyone to participate.  In a funny way, people are more polite and less likely to barge in during a video call. 

Make sure you use the right technology.  For size of calls with 6 or fewer, we use Teams (if you have more attendees, you can’t see everyone on the screen); for bigger meetings we use Zoom.

Summary:  Distributed Agile…you may have initially been forced into it…but it is the future

In a perfect world, teams would come together in person maybe twice a week and work remotely for the rest of the time.  But the world is not perfect; the bigger and more complicated your organisation, the less likely the huddle in the office becomes.

In the real world, Distributed Agile can be the most effective and most rewarding model of working.   We have been running it for 10 years.  It delivers better outcomes for people and organizations.  

Give us a call if you would like to hear how we support clients setting up or fine-tuning Distributed Agile Methodology to deliver automation projects in 90 Days.  It is the (only?) future.

David Landi – Head of Asset Management
E: David.landi@pskinetic.com
www.linkedin.com/in/david-landi/