Agile has become the default way of developing software; sometimes, it seems like every organization is doing (or wants to do) agile. But, instead of trying to change their culture to become agile, many companies try to impose frameworks like scrum onto developers, looking for a magic recipe to increase productivity. This has unfortunately created some bad experiences and leads developers to feel like agile is something they would rather avoid. This is a shame because, when it's done correctly, developers and their projects benefit from becoming involved in it. Here are four reasons why.
Agile, back to the basics
The first way for developers to be unafraid of agile is to go back to its basics and remember what agile is really about. Many people see agile as a synonym for scrum, kanban, story points, or daily stand-ups. While these are important parts of the agile umbrella, this perception takes people away from the original spirit of agile.
Going back to agile's origins means looking at the Agile Manifesto, and what I believe is its most important part, the introduction:
We are uncovering better ways of developing software by doing it and helping others do it.
I'm a believer in continuous improvement, and this sentence resonates with me. It emphasizes the importance of having a growth mindset while being a part of an agile team. In fact, I think this outlook is a solution to most of the problems a team may face when adopting agile.
Scrum is not working for your team? Right, let's discover a better way of organizing it. You are working in a distributed team across multiple timezones, and having a daily standup is not ideal? No problem, let's find a better way to communicate and share information.
Agile is all about flexibility and being able to adapt to change, so be open-minded and creative to discover better ways of collaborating and developing software.
Agile metrics as a way to improve, not control
Indeed, agile is about adopting and embracing change. Metrics play an important part in this process, as they help the team determine if it is heading in the right direction. As an agile developer, you want metrics to provide the data your team needs to support its decisions, including whether it should change directions. This process of learning from facts and experience is known as empiricism, and it is well-illustrated by the three pillars of agile.
Unfortunately, in most of the teams I've worked with, metrics were used by project management as an indicator of the team's performance, which causes people on the team to be afraid of implementing changes or to cut corners to meet expectations.
In order to avoid those outcomes, developers need to be in control of their team's metrics. They need to know exactly what is measured and, most importantly, why it's being measured. Once the team has a good understanding of those factors, it will be easier for them to try new practices and measure their impact.
Rather than using metrics to measure your team's performance, engage with management to find a better way to define what success means to your team.
Developer power is in the team
As a member of an agile team, you have more power than you think to help build a team that has a great impact. The Toyota Production System recognized this long ago. Indeed, Toyota considered that employees, not processes, were the key to building great products.
This means that, even if a team uses the best process possible, if the people on the team are not comfortable working with each other, there is a high chance that the team will fail. As a developer, invest time to build trust inside your team and to understand what motivates its members.
If you are curious about how to do this, I recommend reading Alexis Monville's book Changing Your Team from the Inside.
Making developer work visible
A big part of any agile methodology is to make information and work visible; this is often referred to as an information radiator. In his book Teams of Teams, Gen. Stanley McChrystal explains how the US Army had to transform itself from an organization that was optimized on productivity to one optimized to adapt. What we learn from his book is that the world in which we live has changed. The problem of becoming more productive was mostly solved at the end of the 20th century, and the challenge that companies now face is how to adapt to a world in constant evolution.
I particularly like Gen. McChrystal's explanation of how he created a powerful information radiator. When he took charge of the Joint Special Operations Command, Gen. McChrystal began holding a daily call with his high commanders to discuss and plan future operations. He soon realized that this was not optimal and instead started running 90-minute briefings every morning for 7,000 people around the world. This allowed every task force to acquire the knowledge necessary to accomplish their missions and made them aware of other task forces' assignments and situations. Gen. McChrystal refers to this as "shared consciousness."
So, as a developer, how can you help build a shared consciousness in your team? Start by simply sharing what you are working on and/or plan to work on and get curious about what your colleagues are doing.
If you're using agile in your development organization, what do you think are its main benefits? And if you aren't using agile, what barriers are holding your team back? Please share your thoughts in the comments.
4 Comments