Some time ago, I wrote an article about applying Agile frameworks to real client scenarios. We looked at Agile methodologies from a business standpoint, specifically at a point when people were becoming critical of the strategy’s ability to deliver on the results it promises. Many articles out there - just like mine - focus on what Agile does for the business – how to apply Agile to the enterprise, how to scale it to larger teams, and how to generate the most value from it.
But this isn’t what Agile was originally developed for. Though some believe Agile was created to improve productivity (and this has been a driver in the development of Agile methodologies), the instigators were not businesspeople, project managers, or CEOs trying to increase productivity and shareholder value. In fact, the movement started in the tech community, between developers, architects, and IT experts. The founders of the Agile movement (like Martin Fowler, Alistair Cockburn, Jeff Sutherland) were more concerned about the environment they were working in. Slow processes, rifts between clients and developers, and outdated plans that teams held onto religiously – these were points of frustration that made it impossible to build great products.
This defined the goals of Agile: changing these inefficiencies and creating an environment that engineers can thrive in. The primary purpose of Agile is to foster an environment that supports experimentation and learning from mistakes. Incidentally, these types of environments usually lead to improved productivity and end results, but this was secondary. Upon discovering Agile, however, the industry turned it into a vehicle for improving profitability. This altered the proposed approaches to some degree, shifting their focus and impacting the resulting environment.
Today, we’ll return to reflect on Agile from an engineer’s perspective, delving into these questions:
Agile methodologies are all about empowering the team, and giving them responsibility and authority over the development process. Decisions regarding the tech stack, solution approach, estimating and planning are all owned by the team. In theory, the company simply supports the team in communicating with the customers, as the product is shaped by the discussions around the customers’ needs and constraints. This often proves to be a challenge even in small, nimble startups, let alone large enterprises.
What usually ends up happening is a partial transfer of authority and responsibility. The team may have decision power over the tech stack, but only within the constraints of options that meet certain standards or that fit within existing systems. Plans need to be aligned with external stakeholders who may impose their own vision on the team’s efforts. This isn’t necessarily a bad thing, per se; defining the tech stack within these limitations helps ensuring that the tools being used are vetted and come with the internal support and know-how to make them work. And within the context of a business, plans should of course be aligned with other units, products, release cycles, and so on.
So, the expectation of the team is to take ownership over their product in the scope of the larger organization. How can your team do this successfully?
Even if you fulfill all the conditions of an optimal Agile environment, it doesn’t automatically guarantee success. Essentially, we refer to risks as situations where the outcome is not certain between success or failure. Aside from the usual risks that come with project work and product development, Agile environments also harbor some pitfalls themselves.
Agile methodology is primarily about shifting responsibility and authority to the team, but this is never a complete shift; the team should own a certain amount of responsibility and authority, in balance with other stakeholders. A big risk of Agile implementation is an imbalance in this shift – for example, assigning all responsibility to the team without granting authority. If the team inherits full responsibility for the outcome, including the possibility of failure, but does not have the authority to influence their chances of success, it isn’t a balanced or empowering environment.
This means you should always validate whether the team’s authority and responsibility are in alignment. If you have no authority over how the work is getting done, then it makes sense that you’re not held accountable for the outcome (though that doesn’t sound like an ideal environment either). If you’re being held accountable for outcomes and deliveries, but also hold the power to influence or decide how things are done, then you’ve achieved a balance in responsibility and authority.
Other risks include common biases, which you should always take into account. We usually overestimate the probability of success due to survivor bias (we only see successful outcomes, while failures disappear silently) and availability bias (we hear much more about successes than issues or mistakes). It’s good to be mindful of this when your team is committing to timelines and deliverables.
The environments we work in play an important role in setting us up for success. Generally, strong cultures are liberal with the autonomy they grant to the team and encourage a healthy mindset of learning from mistakes. It’s interesting to assess your current environment. Of course, every individual contributes towards this. But you can tell a lot about a company’s culture in how people interact and react in general to daily ups and downs and periods of turbulence.
Some of the signs to look out for include:
The Agile methodology presents great opportunities for team members to take on more responsibility and grow by tackling new challenges. Individuals have the chance to make a more significant impact on the final product. This is akin to the shift from production lines to lean production that the automotive industry went through in the 80s. A team gets ownership over building a certain part, and can apply improvements to the process and product along the way as they see fit. Software is a virtual product, which can make it more complex to manage timeline, budget, scope, and quality factors on the delivery. That’s why it’s crucial to work in an environment that promotes nimble testing and learning, so that the team can thrive and grow while iterating on the final product.