The perfect agile team

The members of the team are not concerned with boundaries of job titles, who they work for, labels or permission. They recognise and value experience much more than authority. In addition, they are cross-functional, T-shaped (not in a “full-stack” manner). This way, they can mitigate skill gaps and bottlenecks in their process and increase the diversity of their opinions.

Although they do not carry the labels themselves, their skills include traditional engineering categorisations of front-end, back-end, database, ops, or QA. As well as BA’s, researchers and designers. When they discover they lack a skill, they learn it where practical or seek the direct support of a subject matter expert to bring into the team for a while. Understanding the consequence of dependencies, they push themselves to eliminate any they encounter.

Their work is meaningful

The perfect team cares about their work being meaningful and beneficial to those who use it. The team members are connected directly to their users and customers, with continuous research and feedback cycles. They don’t design up front, they design just-in-time and they don’t stop designing, ever. The team understands that perfect is the enemy of goodand make pragmatic and probabilistic decisions based on the best information they have. Sometimes they make the wrong decision, and that’s OK. They value those learning opportunities, knowing what they do can be undone just as quickly. In addition, they understand that the unexpected can happen, and they embrace disruption as an opportunity for improved resilience and recovery.

They are self-organising

The perfect team is self-organising; it is not managed, it does not wait for instruction or assignment. They have short outcome-missions to achieve, trusted and empowered to achieve them as they see fit. They select their goals themselves from an opportunity tree they develop (and communicated outward on their roadmap). On the basis of what will create the greatest impact the soonest, they pull work to themselves, informed by the data they have, where the impact will be of direct value or experimental learning to inform future customer value. The ultimate goal is always to serve the customer's need.

Their goals are small, immediate, and valuable. They discuss the goal as a collective, using BDD (behavior-driven development) processes to create just enough requirements to confirm their shared understanding of the scope of the problem. The team uses the conversation to identify and eliminate that which isn’t necessary now, articulating the problem in a shared present business language.

They understand and measure value

The perfect team collaborates as opposed to cooperates, working on a single problem at a time. This reduces context-switching, the distraction of false commitments or anchoring on an inventory of shifting futures. It allows them to maintain a shared laser-focussed alignment to their goal. They have learned from XP to turn up the good and they understand that in an emergent context like software development, typing speed isn’t a constraint.

Therefore, mobbing and pairing are employed every day. With many eyes, and more importantly many minds working in unison, there’s no need for asynchronous code reviews. Therefore, decision-slowing pull requests and gitflow are replaced with trunk-dev.

They understand their own value and cost. The team seeks open source, off-the-shelf, Saas and Faas solutions so they avoid reinventing component products and commodities.

They strive to automate anything they will do more than once. They innovate with tooling perhaps to wire their BDD acceptance criteria directly into their build pipeline which they can then visualise in dashboards, accessible to all, openly sharing their progress to all. From their BDD mindset, tests come first, not last, and their continuous integration executes those tests continuously. One-hundred percent test coverage isn’t an abstract mythical ideal for them. Besides, they eagerly explore new directions of resilience such as chaos engineering and mutation testing.

They deploy continuously

Their goals are rarely more than a few days long, and they deploy continuously. Therefore, they create new value all the time and they have no need of estimating. Deploying on a Friday doesn’t raise any eyebrows. They understand their operational performance in terms of risk, flow, and value through a small and objective set of metrics they own. They utilise tools like SonarQube, Monte-Carlo models, and North Stars - but definitely not velocity. They’re also serious about their emotional maturity and the stresses they place on themselves, so they regularly pause to check morale.

The perfect team understands that shipping a feature to production isn’t the end of the feature; regardless of how quickly it ships. The feedback loop is neither feedback nor a loop without observing the impact of the feature. Therefore, they monitor operational quality of service, check the new user experience with the actual users, and look for the unintended consequences and behaviour shifts. The perfect team is aware they are just one actor in a complex adaptive system, and that the system and its context evolve constantly.

They are imperfect

A perfect team is also imperfect. It understands that there is always something to improve, something to learn, something that changes as contexts change and time moves on. In addition, it understands sometimes it needs to be pioneers and sometimes town planners. It is wary of self-satisfaction and inactivity, looking outwards for fresh input to other teams and peers also willing to share. It is a model of a learning culture, and a fractal image of the wider organisation as a whole.

Worth, and our clients, have been operating like this since the beginning of the year (and we’re getting better as we learn). It didn’t happen all at once and although it wasn’t always easy, it wasn't overly difficult either. What it took was self-awareness, openness and freedom to experiment, It also took the willingness to recognise the core of a few unconventional ideas we believed would improve the weaknesses. If excellence in delivery is the capacity to adapt and execute strategy rapidly, i.e. agility, such distributed and learning teams are the engines that power successful, agile organisations.