Distributed 'Agile'... The art of doing amazing things together, whilst thousands of miles apart

I’ve written previously of experiences of working in a complex, distributed agile environment. It challenged us to reconsider what we do, and how we do it. The blog highlighted the importance in the definition of (and commitment to) rehearsed delivery processes - which are right for the team, and breaking deliverables down to drive flow.

Getting 'Agile'... across Continents and Time zones

This blog considers the importance of transparency in delivery, use of the right tools at the right time, and the importance of effective communication.

Turn the opaque into the transparent - but only when it’s ‘done’.

Velocity, and the ability to track, monitor and forecast agile team capability is a central tenet of Agile. Whilst ‘sprinting’ sharpens short term delivery focus, project governance naturally requires a level of management information regarding the ‘roadmap’ plans.

Known (validated) velocity, when combined with techniques such as relative estimation, offer simple signposting of where a team is expected to be, by when, based on actual performance. Within commercial context, understanding of forecast delivery is critical.

But there’s a not insignificant precursor to tracking velocity - the team commitment to the definition of ‘done’. Is something ‘done’ when man hours or story points are ‘burnt’ against a given user story? Or when a user story is development and test complete? Or when a user story has been through PO review and been ‘accepted’? Or when a production release has been completed and new features / enhancements released?

In the absence of a known ‘done’ state, flow, velocity and forecasting is ambiguous. Whilst the definition can and will differ between agile teams, getting buy in to a single teams definition is paramount. Within our distributed environment, we found that product owner review / acceptance forms ‘done’. Despite all the moving parts and the multiple delivery entities, the user facing platform delivers what it needs - for the user. We tick that box, and we can chalk it up as being complete - or ‘done’.

Whilst in sprint, delivery into ‘done’ state drives the team burn down. This is reliant not only on the definition of done, but on frequent product owner reviews. The product owner is not on the periphery of the team, they’re very much a part of it. PO review of developed and tested functionality enables the team to incrementally deliver sprint commitments. Achieving a ‘stepped’ burn down can motivate a team, giving daily validation that the delivery processes are working. A burndown which is flat lining drives focus that the team is running, but with inefficiencies. Having difficult conversations and making corrective adjustments, behaviourally or technically, is key to driving continuous improvement in team performance.

Within a distributed environment, transparency, both in sprint and roadmap, is critical. Which means the tooling supporting delivery has to work for the team.

Get Tooled Up! (In the right way)

Statement one of the Agile Manifesto states; ‘Individuals and interactions over processes and tools’. So why am I suggesting getting tooled up? Control, early sight, quality and process scalability. The manifesto isn’t saying ‘don’t use tools’, it’s simply reinforcing the importance of team behaviours.

In distributed environments the right tooling and processes increase in importance.

Delivery inefficiencies can quickly lead to missing sprint objectives. Failing to deliver what we commit to can be enormously demotivating, particularly if it becomes repetitive. In our distributed environment we focussed on a number of key areas:

  1. Configuration management: Drive development efficiencies through agreed (and tested) branching and build pipeline strategies. Ensure developers are managing merges and conflicts as quickly as possible.
  2. Test automation: incorporated in the build process. Implement and maintain standards for the creation of automated (unit and integrated) tests, ensuring each feature can be tested in isolation. Focus on behavioural change, and the adoption of ‘3 amigos’ processes, improving both quality and throughput
  3. Code quality tooling: Define coding standards (reasonable / fit for purpose) and configure code quality tooling to enforce them. Build confidence in the quality of the code base. Ensuring new and existing code is readable, follows agreed coding standards, and reflects agreed unit (and integration) test coverage improves the development efficiencies.
  4. Delivery cadence / velocity tracking: Complexity in tracking both current (sprint) and forecast (roadmap) positions increases relative to the number of developers and geographical spread. Team commitment to populating and maintaining collaborative tracking tooling is key to data integrity. As standard, we utilise Atlassian’s JIRA. Labelling and tagging strategies should be established to prevent developers becoming overwhelmed by the number of stories and issues listed. Utilising JIRA reporting plug in, EazyBI, the overall delivery roadmap could be tracked through the use of both high level epic estimates and lower level story estimates. The use of dashboards and summary screens was critical in improving transparency to stakeholders, ensuring that they understand where the project is and have visiblity of any issues quickly
  5. Working documentation: Collaboration and shared resources are critical in distributed environments. All members of the team need a ‘single version’ of the truth. In conjunction with JIRA, the ability to document and link technical design artefacts with user stories and technical tasks was key to ensuring developers had the resources they required to maintain development throughput.

It’s good to talk!

Free flowing communication and team interaction expedites developing relationships, and the speed of decision making and problem solving. Indeed whilst we operate in the digital age, there are few more effective tools than whiteboards, markers and post-it notes. All great when co-located. Distributed teams clearly bring an added complexity, requiring an understanding of individuals, the environment, and the culture. It requires constant reflection and adjustment. It’s certainly not a ‘one size fits all’ approach.

Recognizing the need to understand and break down the barriers to communication, we actively focussed on;

  1. Ensure meetings add value: Sitting through meetings which deliver no perceived value to the participants is a sure fire way to breed disengagement. Meetings held remotely need to address a specific purpose. Those involved in the sessions should be active participants. Meetings should drive an outcome. If the value is questionable, so is the very meeting.
  2. Self-organisation & Kanban Workflow: Accept that the each hand off in workflow step has a potentially adverse effect on communication. Introduction of lightweight, mandated touch point sessions. We looked at both ‘3 amigos’ (often 4!) and exit interviews, with specific intent of smoothing passage into and out from development.
  3. Reduce communication latency. Embrace real time communication: Slack was our tool of choice. The ‘general’ and ‘random’ channels are just as important as those channels setup for technical discussion. Establishing and nurturing supportive relationships is key. Equally, direct and immediate technical discussions can remedy issues / remove ambiguities piecemeal, further mitigating the need for extended collective sessions.
  4. Explore non-verbal communication: Asking people to express feelings is difficult, particularly where cultural differences exist. One simple means by which we encouraged honest feedback was through a ‘thumbs up’ game. A simple collective presentation of thumbs, either upward, downward or sideways pointing, created a beautifully simple barometer to check the team atmosphere.
  5. No substitute for face to face: Video conferencing became a core element of our process. Bridging the gap between distributed members of the team is critical to building relationships and trust. It certainly isn’t without its challenges. Meetings are dependent upon people becoming comfortable with communicating via video, and the broadband needs to be capable of preventing meetings becoming full of ‘can you see me? I can see you?’ Get the culture and infrastructure right, and real benefits can be seen.

What is abundantly clear is that there isn’t a ‘silver bullet’ / ‘one size fits all’ approach to delivering Agile projects, either in co-located or distributed environments. Agility isn’t simply about incremental software delivery. It’s about incremental, even constant reflection and adjustment. Culture, and the ethos of ‘team’ are not ‘givens’. They have to be nurtured.

About the Author...

Rich heads Answer Digital Retail, delivering world class solutions to clients including Costcutter Supermarkets Group, FCUK, Arcadia and Ramsden International. Richard has a passion for retail and the transformational impact technology is having on customer experiences.