My friend, Johanna Rothman, gave me a copy of her new book (with Mark Kilby), From Chaos to Successful Distributed Agile Teams, as we share a lot of ideas on how people work together. As advertised, it is a fairly quick read, loaded with guidance and recommendations for teams that aren’t co-located apply the Agile Software Development principles.
Admission on my part: While I have read a number of books, articles and blogs that talk about Agile Software Development, I am not a regular practitioner of these methods in the context of software development. This book is a great guide, and it opened my eyes to how the agile mindset comes to life in organization. Of course, the underlying principles behind agile are all about creating flow-to-value, and FLOW is something I reference nearly every day. Most of the work I do of late is in helping teams and organizations drive value to the customers - to create value for their own organizations. I am always looking for ideas and concepts the will improve this service. And it comes out loud and clear in the book. The design of an agile team has to be to support flow.
I liked how the authors kept coming back to the Agile principles as they discussed various aspects of team dynamics when teams are not sitting in the same physical space together. No matter how the team is constructed, they need to have these elements (only the first one is REALLY associated with being in different locations) - these are the authors’ interpretations of the Values and 12 Principles in the Manifesto for Agile Software Development:
Acceptable hours of overlap
Transparency at all levels
Culture of continuous improvement
Pervasive communication
Assume good intention
Create a project rhythm
Culture of resilience
Default to collaborative work
The authors apply these principles to the team (the bulk of the book), but also the organizational culture, the hiring process, and the managers and leaders who will guide the teams. It’s the principles over the specific practices.
One of the biggest elements of the book and the recommendations is that for a team to be able to successfully collaborate, they must share working hours. The clear statement in the book is that if the team members overlap by less than four hours, they cannot operate as a collaborative agile team. They will more likely operate as a collection of individuals, all working on their own thing.
And this leads to one of the “ah-hah” moments of the book for me. This kind of team is very different from a typical business or project team. And yet, there are so many of the comments and ideas in the book that apply to any group of people who are working together toward a common goal - transparency, collaboration, continuous improvement, (appropriate) habits, etc etc. These are needed everywhere.
Some additional highlights as I read:
Experimentation and double-loop learning are key elements. I bet a lot of people think there is a “fixed” way of doing their work, so experimentation doesn’t apply. But experiments can be used in many ways - the work, the process, the deliverables, the WAY of these things along with the what and the how. In fact, I may be one who is hesitant to experiment. I have what I have. I “know” how to do things. It works okay... [uncomfortable silence]
“If you are starting or restarting a non-collocated team, the cheapest thing you can do is to bring the team together for a week or two.” They discuss the blockers that organizations put up to do this, but getting people to understand and share a common context around their project/product is so critical. And having face time creates opportunities for understanding and resolving questions that can take months to resolve - and yet spending the money for a week or two is “too expensive.”
“Simplicity—the art of maximizing the amount of work not done—is essential.”
I really like the principle of “assume good intention.” When people act in a way that doesn’t make sense, the response isn’t that they are “bad” (or “dumb”) it is that there is something we don’t see on the surface. “What needs to be true for that result to appear?”
Collaboration and communication: “The more delay before people ask questions, the more questions they have, and the more the delay cost looks like a hockey stick.”
Collaboration: “We like to think about team collaboration this way: Do the people treat each other in a way that enhances the team’s collaboration? Does every person on the team participate in team-based experiments? Does everyone on the team have equal opportunity to contribute to team conversations?”
We all love the quote that “email is where knowledge goes to die.” It is also where collaboration and communication go to die. Long email chains are indication of some unresolved conflict - that would be much better served in a synchronous conversation. (And that can happen only when the team members share working time.)
“The more information the team shares with each other on a regular basis, the more likely the team will work together as a team.”
“It’s very easy to assign blame to people at distance. Instead, practice empathy.”