Skip Main Navigation

Agile in practice: embracing autonomy and experimentation

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: 

  • What’s expected of a team using Agile methodology? 
  • What are the risks of working in Agile environments? 
  • What are the signs of a great Agile environment? 
  • How can I thrive in an Agile environment?

What goes into a healthy work environment

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? 

 

  • Understand what you’re doing – This holds true for the technical and business side of things. In an Agile environment, this goes deeper than mastering your craft. It’s important that practitioners understand the “why” behind what they’re doing, and retain a clear sense of the goal that their code or solution supports throughout the development process.
  • Eyes on the horizon – With a framework like Agile that leans into rapid experimentation and learning, keeping your eyes open for opportunities and risks beyond the immediate situation is to your advantage. This could mean technical topics, ideas for features, UX approaches, target groups, marketing activities… the list is endless.
  • Explore and evaluate your options – Don’t stop at one idea; explore multiple approaches, and think about how different opportunities can be leveraged. This will also help others to be more receptive to your ideas and encourage added perspectives and support for different ideas. It’s generally best practice to not just stop at the first solution that works.
  • If you can’t make decisions, propose them – Chances are you won’t have full authority over your project and can’t call the big shots on your own. But you can propose and make a case for them. Assess the options, break down the pros and cons of each, and discuss with your team members. Step into your power by proposing the best option to the stakeholders so you can get the decision made. And don’t be discouraged if this doesn’t work out on your first try – continue doing so with new ideas.
  • Support others – A fundamental part of Agile methodology is collaboration, both internally and cross-functionally. In the end, every team is working towards a common goal. If supporting others requires you to take some additional time or impacts your tasks, align with the rest of the team and budget owners.
  • Educate yourself – This is true in any environment. Staying open-minded and leaning into the exploration of new topics, technologies, approaches, and ideas will make you both a better practitioner and help you enjoy the journey along the way. Being curious will help you adopt the flexible mindset needed to thrive in project work, regardless of the methodology.

Risks of working in an Agile environment

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.

Environments that empower

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: 

 

  • Daily interactions – Are people open and friendly? If you ask for support, do people seem willing to help? If not, do people at least receive the request with goodwill and redirect you to a better resource?
  • Professional vs. personal balance – Is this an environment that encourages bringing your full self to work? There are two extremes here to avoid: one is the case where people solely focus on their jobs without any interest in the people they work with. The other is the cult-esque environment (they often refer to themselves as “family”) that begins encroaching on your private life. A healthy balance looks like a team that cares about you as a person, but doesn’t try to invade your private life. There are extracurricular initiatives that help the team bond outside of work, but are typically optional.
  • Team stability – Does the structure and trust between teammates feel robust? Do individuals understand what their colleagues do, and how their work impacts each other? High turnover, constant shifts in organizational structure, and a general lack of cohesion are indicators that something is off.
  • Opposing opinions – How does the team manage discussions and differing opinions? Does everyone have a space to be heard? How do decisions get made? It doesn’t mean it’s a bad thing if an executive or senior leadership is the one to make the final decision – that is their job, after all. But there should be the opportunity to have an open discourse leading up to that decision, and decision-makers should approach their responsibility with an open mind and flexibility.
  • Successes and failures – How are successes celebrated? Does the team share in these wins? How does the team respond to failure? Do they lead to the blame game, or does the team take the constructive path to learning?
  • Times of stress – There will always be stressful periods throughout projects. Think about crunch periods that involve late nights, or the occasional frustration and snappiness. How do people weather those periods? Is there a sense of camaraderie, or does the team fall into the trap of accusations and hostility? Stress shouldn’t be a constant. If there always seem to be fires that need putting out, it’s a sign that the team doesn’t have enough authority, or timelines are always too tight.
  • Opportunities to grow – To me, this is one of the most important points. It makes a big difference to be surrounded by people who bring out the best in you, and encourage you to learn and grow. 

Thrive with Agile

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.

Discuss how we can help your team to leverage and benefit from Agile


Stefan Franck

Senior Director

One Netcentric’s co-founders, Stefan is an expert in shaping solutions for clients - from requirements analysis to project specification and more. Stefan sees himself as the link between business and technology and, for over ten years now, he has filled various roles as architect, project lead and lead consultant. Stefan's focus is on the Adobe Marketing Cloud and AEM, to which he is strongly connected from his days at Day Software and Adobe. He says that co-founding Netcentric was one of the best choices in his professional life. Never before been able to work with so many brilliant people.

More Developer Circle