Doing agile is challenging but being agile is transformative. Where is the right place to start? There is no one right answer. But first things first. What is the difference between doing agile and being agile?
Doing Agile
Agile is not a methodology; it is a mindset you can apply in your life and your way of doing business. Agile is common in the software development industry, but any industry can use and benefit from the agile mindset. For me, doing agile is about implementing specific behaviors or ways of doing business based on four values and twelve principles (the Agile Manifesto). Therefore, a way to do agile is to implement frameworks or methods that are very powerful to organize, collaborate and prioritize tasks and workflows in a team such as Scrum or Kanban.
Most teams try this approach. I don’t think it is wrong, but I do think it is incomplete. When teams focus just on using SCRUM, they forget why they are implementing agile. In other words, they can’t see the forest for the trees. Agile is not about speed. It is about producing better outcomes for the business in a rapidly changing world. For example, a team measures the number of new features (outputs), rather than new subscribers (outcomes). It is okay to have deliverables, but new features do not guarantee business results.
Being Agile
Being agile, on the other hand, is about transforming your mindset. It has to do with how you understand the world. It encourages a new way of leading teams, developing a product, or testing ideas. Being agile is transformative because it forces us to put the customer first and focus on developing the things that matter.
Why Being Agile is So Hard
Being Agile is common sense, but not common practice. It goes back to the Waterfall Project Management framework. This way of managing was created during the industrial revolution. The goal was to find the best way to optimize a production line. Things are different now because the speed of change is so high that companies need to adapt every day. And what is tricky about change is that it’s not so fun. Change means constantly learning and coping with uncertainty. And learning with the wrong mindset means failing, which touches our insecurities.
I remember coaching a Product Manager to include an experimentation mindset in their agile sprints. In order to do this, she had to coordinate experiments with a team of UX designers and developers. The team was struggling because everyone wanted to have everything perfect. It’s okay to pursue doing things right. The problem is when perfection is a way to keep your work within your comfort zone. For example, their focus was on having the perfect design or the perfect line of code. Instead, they should have been trying to understand the impact their new features would have on their customer. But they preferred to focus on what was less scary for them: the technical output.
Everyone had a reason for this. The PM was new to the role, so she did not want to measure outcomes because, for her, that meant she did not understand the customer well enough, and she was not ready for the role. The developer did not want to measure outcomes either because his job was to make a button work and get that perfect algorithm. He did not see himself as having to change the customer behavior. The UX designers did not want to test with mockups. Instead, they had to do things properly and follow their internal procedures as good design mandates.
This makes sense because it is harder to commit to impact customer behavior (outcome) than to produce an output. It is hard because apparently, the former is not under the team’s control. And this is true if you look through perfectionist lenses, but it is not the only way.
The Simple Solution
Sorry, there is no simple solution. But there is a solution. I will summarize some key points, but I also want to anticipate that agile means implementing a profound cultural transformation and that is a complex process that takes time.
As a manager, you need to accept the impact of working under agile. You cannot ask teams to use Kanban but have a two-year roadmap of features that the team needs to develop. Instead, it would be best if you adopt a learner mindset. As Jeff Gothelf says, you are creating an infinite product. A product that is constantly evolving with the market, and you can’t know what the market will want in two years. A learner mindset implies testing and learning (failing) repeatedly.
Second, test and learn is tough if you don’t create psychological safety for your team to explore the unknown. This is a new way of leading in which leaders need to be capable of having crucial conversations to understand what failure means for each individual on his/her team. The best way to incentivize this is to stop appraising faster outputs, but faster learning cycles. Retrospectives or reflections are crucial but do not focus only on technical issues. Explore the individual dimension. This can start with a simple question: How did you feel during the experiment?
Finally, as a leader, you need to create a shared vision where everyone understands that a line of code impacts the company’s ROI. You need to be consistent and aligned with the results you demand. It is okay to have clear objectives and key results (OKRs), but they should be centered on changing customer behavior.
Conclusion
To sum up, being agile can sound cool and imperative, especially in these crazy times. Sometimes we want a quick solution — we might think agile can be the vaccine to get everything under control again. But things do not go back to normal with quick fixes. Conscious leadership is more relevant than ever. We need to change our mindsets, being players and learners who take care of each other at every step of the way. That is, for me, the best way to be agile.
