What Makes a Team Agile?

Agile is a software development philosophy focusing on collaboration, adaptive planning and continuous improvement. Lately, Agile has become somewhat of a de facto development method for the tech world. At it’s core, Agile aims to fundamentally restructure the way work gets done through a handful of principles.

Various Agile methodologies — like Scrum — introduce a lot of boilerplate. They encourage specific ways of executing routine tasks — such as software estimation, gathering customer feedback, or even measuring team progress. Different teams have different ways of going about being Agile. Over time, different groups of people tend to adopt their own set of processes based on what they feel makes them move faster.

Having worked on a handful of teams, each with their own “implementation” of Agile, it is quite interesting to see that despite all the differences, there are usually a handful of core principles that most teams try to adhere to. It is these principles, that fundamentally determine “how Agile a team is” and ultimately, how successful it is.

1. Concise but Robust Feedback Loops

One of the biggest hallmarks of an Agile team is it’s ability to rapidly incorporate feedback from it’s environment and minimize the time it takes to identify problems and fix them. Agile teams always strive to identify potential issues hindering the development processes and come up with strategies to mitigate them before it’s too late.

For example, work is broken down into small iterations, typically ranging between two to four weeks. In the Scrum world, each iteration is referred to as a Sprint. Breaking down larger projects into smaller Sprints — which further contains a list of Tasks — allows teams to better estimate the tasks they are working on. This further allows them to set more realistic expectations of themselves. There is a direct correlation between the complexity of a task and one’s tendency to misjudge the time required to finish. Read more on that here.

But more crucially, perhaps, breaking work down into small enough iterations gives a team the opportunity to regularly reflect on it’s successes and failures. At the end of each iteration, the team is able to evaluate the things that were done well and areas where things need to be changed.

This serves as an opportunity to reflect on what processes work well for the team and what modifications need to be made to make the team more productive. These changes can then be incorporated into the next iteration creating a virtuous feedback cycle where the team ideally gets more effective over time. Scrum implements this idea through periodic Sprint Retrospectives, or “retros”.

In fact, Scrum takes this idea of feedback loops even further by introducing the concept of a Daily Stand-Up. The goal is for all members to meet every day at a fixed time and spot and simply discuss

• What you worked on during the previous day
• What you intend to work on for the rest of the day
• What, if anything, is getting in your way

Ideally, this creates an opportunity for everyone to get in sync frequently — before the designated retros — and also ensure that everything is on track to successfully complete the iteration. Blockers are surfaced as soon as possible and team members have an opportunity to raise any concerns they might have about what they’re working on.

2. Collaboration Is King

One of the most discerning aspects of Agile and Scrum is how little emphasis is placed on an individual when compared to the team as a whole. Unlike conventional management techniques which seek to maximize individual productivity, Scrum proclaims that an individual can only be as good as the team that they are a part of, and the processes and values that it embraces. Team dynamics and collaboration, thus, take the center stage in the Agile world and not individual flair.

To that end, teams are assembled with the goal of making them as self reliant as possible. Ideally, any given team must have all the resources that it needs to execute on a product. The goal, therefore, is to have engineers, designers, product strategists, and business folks all working together as one coherent unit towards one common vision.

There are a couple of tangential benefits that are gained as a result of this. Quite obviously, pulling together people from multiple facets speeds up the communication process quite a bit as it eliminates some of the bureaucracy of inter-department communication. It puts everyone on the same page much faster.

This also allows everyone to be better informed about why certain decisions are being made and where the product is headed. As an engineer, for example, understanding the rationale behind certain business decisions gives me a more holistic overview of the product that I’m building. I’m able to get a better understanding of who my customer is. I don’t have to treat the product specification as a checklist of features that I work on in isolation, but rather an opportunity to improve the experience for end consumers.

Another — more subtle — reason, behind encouraging cross functional teams is the sense of ownership that is automatically enforced as team members start to associate themselves more with the product that they are working on than their individual job titles.

3. Shippable Improvements

So far, we’ve talked exclusively about how a team can build feedback loops to improve how it functions. But Agile methodologies often extend the argument one step further, and apply to the development of the product itself.

If a team can strive to produce a functional version of it’s product at the end of each iteration — albeit with only a subset of all it’s features — this product can then be put in the hands of stakeholders and potential customers. This allows everyone involved to provide their input regularly. This also ensures that things are moving in the right direction by creating a mechanism where bugs are caught early on.

Note that this is in sharp contrast to traditional software development methods where there is little communication between developers and customers until the handover stage, at which point, it’s often too late to make any changes to the product.

However, because changes are pushed out so frequently, a huge emphasis is also placed on each feature being “vertically integrated”. This simply means that every feature is fully baked, so to speak and contains everything from the required backend infrastructure to the frontend UI. In this sense, tasks are broken down from the perspective of a potential user.

Ultimately, the beauty of Agile is in it’s openness. Organizations don’t necessarily have to stick to the processes dictated by Scrum, or any other single methodology. Tools like Daily Standups, Planning Poker, Agile Retros, Kanban are just the means to an end, not the end itself. In order to be truly Agile, it is important to first understand why certain things are done the way they are. It is important to understand what benefits are being achieved by adopting certain processes and if they even make sense in your specific context. After all, it is the spirit of Agile that is more conducive to a team’s success than anything else.