Remote Agility: Distributed Development Teams Today
Hundreds of thousands of words have been written about agile software development, and many of those have been written by actual software developers. My interest in the subject is about the teams doing the work, and the way that the principles of agility parallel the values and approaches we observe in successful flexible and self-organising teams in the remote space, across all industries.
The original Agile Manifesto is inherently simple and flexible, and very easy to relate to the remote teams we’re used to working with. It’s short enough, in fact, to be quoted in full here:
We are uncovering better ways of developing software by doing it and helping others do it.
Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.
It is interesting to see how brief and non-prescriptive it is, and to be reminded of the way the manifesto specifically avoids mandating - or even recommending - any kind of methods, rules and processes.
Distributed Agile Teams
So why do the authors of “From Chaos to Successful Distributed Agile Teams”, Johanna Rothman and Mark Kilby, indicate that, “distributed teams have a terrible reputation. They don’t deliver ‘on time’ and too often, they don’t deliver what the customer needs”?
The resistance to digitising the workspace that we occasionally experience in some of the teams we work with surely cannot apply to developers, who are by definition going to be at ease with online tools. So it’s difficult to see where this strength of feeling has arisen from, and why so many agilists are apparently opposed to remote work.
Perhaps it stems originally from the Principles behind the Agile Manifesto’s statement that “The most efficient and effective method of conveying information to and within a development team is face-to-face conversation,” a trope interpreted very literally by many within the industry, that may have become a self-fulfilling prophecy. It was this reputation that Rothman and Kilby collaborated - remotely, incidentally! - to tackle head-on with peer reviewed research and learning for their book, as they told us in a recent podcast (episode 197).
It is understandable that a range of methodologies have arisen to interpret and apply the Agile Manifesto and its related Principles, and create from it the actual rules of engagement that teams use all over the world today to create all kinds of things together.
Agile Methodologies
Perhaps because of the very fluid and value-driven principle list compared with the complexity of the projects such teams work on, some of these methodologies are themselves highly structured and complicated, with specific elements that can feel quite rigid.
These methods were not developed for use with remote teams, and can feel challenging to apply successfully there. Scrum, for example, mandates a range of activities such as daily standup meetings, and a highly structured review processes. And Extreme Programming (XP) focuses strongly on the perceived energy generated by very close collaboration and connection, stating, “you can add vital communication paths to your team by just taking down the barriers that divide people” - which could surely be interpreted metaphorically rather than literally, in workspace design terms.
Of course these methods were originated for teams sharing a physical pace, looking over one another’s shoulders to programme in pairs and groups, and sharing a big analogue whiteboard and sticky notes. But that doesn’t mean these elements of the work cannot transfer to the online space, and indeed specific tools have arisen to facilitate exactly that, such as Retrium built by agilists to improve the practice of retrospective meetings generally, not just for remote teams, but as a purpose-built online tool to make this particular kind of meeting more effective and productive. (To find out more about Retrium, check out the conversation with co-founder David Horowitz in podcast episode 129.)
It’s a case of how you manage the process, just as with any other work experiencing the transition to ‘office optional’ ways of working. It might mean undertaking training to update skills, such as Mark Kilby’s talk on facilitating agile teams. After all, the Scrum Guide says nothing about colocation, and does indicate that “development Teams are structured and empowered by the organization to organize and manage their own work” - so as the context of that work continues to evolve, so will the leadership skillset required.
Indeed as Rothman and Kilby’s findings and ideas indicate, agile approaches, even quite structured ones like Scrum, can work very well for some distributed teams. They acknowledge that while there can be productivity trade-offs in terms of longer cycles when teams do not overlap much in timezones, the upsides of remote working outweigh these costs. Others, such as Disciplined Agile, propose that, if managed well, global teams can in fact be a productivity boon - reducing time to market with a ‘follow the sun’ approach which makes the most of carefully planned handoffs to enable round the clock working - while recognising that the very act of handing-off would not be considered agile by all.
The needs of today’s workforce and hirers
Because however people feel about it, the software development industry needs the flexibility that remote working brings to its activities.
As products become more complex and the skills required - perhaps involving larger teams brought together for fixed contract periods - become ever-more niche and specialised, hiring becomes a challenge.
Combine this with the fact that many tech companies are headquartered in parts of the world where living costs are escalating and recruitment is extremely competitive, and it might not be possible to hire enough of the diversely and deeply skilled people you need, if you decide they must work in a fixed location. Even if you can find them, they’ll be expensive to lure away from other offers, compared with the salary arbitrage potentially available when hiring globally.
Some of the literature available about remote agile teams can combine remote with off-shoring, which obviously maximises the staffing costs, but leads to other issues. Disciplined Agile and others warn about measuring the total cost of the work in these cases, taking account not just of salaries and hourly programming costs, but also factoring in the real effects of cultural communication issues and indirect handovers (creating more documentation as a result). More upfront planning and expectation-setting at the outset of each sprint is critical for managing the ways you will communicate and collaborate effectively, but it’s also important that negative experiences of trying to save money on developer costs by salary arbitrage doesn’t get confused with the spectrum that remote working encompasses.
Making the work visible
Visible teamwork and creating a highly visible workflow can definitely help to make agile methods work across distances, regardless of whether that distance is across town or across continents. For example, overcommunicating by default to avoid any misunderstandings, ensuring an exceptionally clear ‘why’ around which to align the work, and very clear expectations and definitions.
And it’s important to bear in mind the degree of distribution and the many forms it can take. Indeed Mark Kilby described on episode 175 of our podcast ; the difference between ‘satellite’ teams with a clear central hub to revolve around, ‘clusters’ of colocated sub-groups, and truly dispersed ‘nebulae’.
Within agile teams it might be important to consider where specific roles are located and treat that as the ‘centre’ in terms of planning the cadence of meetings, even if this contradicts the idea of suiting the majority. For example if a pivotal decision-making role rests with a single individual such as the Product Owner in a Scrum team, then things might need to revolve around them - even if the centre of gravity is apparently elsewhere in terms of team numbers, to extend Mark’s astronomical analogy. Designing the workflow around potential bottlenecks makes sense in any scenario.
In this event the impact on other team members working intensely in a sprint should not be overlooked, however. Another of our podcasting and blog contributing friends, Teresa Douglas, found that working on a team with even a one-hour offset had its frustrations: “Generally it's working, but the daily stand up, retrospectives and sprint planning sessions all happen during the time formerly referred to as my lunch break”.
Back to first principles, to embrace the future
Going back to basics and reviewing the Agile principles, it’s good to be reminded that, “the best architectures, requirements, and designs emerge from self-organizing teams,” and also that agilists should “build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.”
This reads to me like a great alignment with the intrinsic motivation and commitment which the right people bring to working in a remote team. Agile approaches call for continual improvement, for fluidity and responsiveness to unexpected outcomes in complex situations, and the willingness to respond effectively to technical, demographic and social shifts in the global workplace is a good example of this.
Combining sensitive planning, the right tools, and most importantly a truly agile mindset, will surely create the right approach for successful distributed working in software development teams - enabling truly motivated and effective skilled individuals to collaborate effectively in a way which satisfies every stakeholder.
And if you enjoyed this post, for more inspiration on leading remote teams, and a set of questions to help you reflect on the different chapters, check out our book Thinking Remote, in ebook, paperback and audio formats.