Tag: scrum

agile myths debunked

Not long ago I posted a series of myths and realities about Agile on my LinkedIn account. While many in the business world talk about Agile ways of working, how accurate is the information we think we know? Are you confusing an Agile myth with reality? In June, I shared an article on the Agile Mindset and what a person needs to truly be agile. I would like to follow up by sharing my top 6 Agile myths:
agile myths debunked
 

MYTH #1: AGILE IS A SET OF PROJECT MANAGEMENT FRAMEWORKS

REALITY: Agile is primarily a culture, a way of thinking and acting.

  • The biggest and most common mistake and the reason that many fail at implementing Agile in organizations comes from focusing on the DOING Agile without working on the BEING Agile.
  • Implementing Scrum, Design Thinking, Hackathons, Lean, Kanban and other Agile frameworks will not be sufficient to be Agile.

 

MYTH #2: LEADERS ARE NOT NEEDED IN AGILE

REALITY: True…and false.

  • Agile needs leaders, but not where they might usually spend their time and energy.
  • Their role is to drive and foster the appropriate ecosystem and culture. They must genuinely inspire themselves first and then their people with a compelling Purpose, Vision, and Strategy that can guide decisions and actions. This is not a minor role. An Agile organization could not exist without these leaders.
  • In Agile, coaching leaders to empower their people by decentralizing decisions, control, and accountability to the point closest to action.
  • To put it in other terms, leaders move from the pilot seat to the co-pilot one.
  • Top management is often unconsciously the main barrier or intentionally the key enabler of BEING Agile more than being directly involved in Agile projects.

 

Myth #3: AGILE IS BETTER AND FASTER. Its role is to increase the speed of decisions and actions.

REALITY: Speed of decision and action is part of a predefined daily and weekly planning but is not a goal. Value delivery to customers comes before timing.
 

Myth #4: AGILE IS ABOUT PRODUCING MORE, QUICKER, AND CHEAPER

REALITY: Big mistake. Agile optimizes value delivery and customer satisfaction first, not just productivity and efficiency.
 

Myth #5: AGILE IS PERMANENT INSTABILITY MANAGEMENT

REALITY: Agile’s pre-defined cadence and framework are highly predictable. You know in real-time how the team is tracking against objectives with daily baby steps, one at a time, with clear objectives. This approach makes manageable permanent changes and instability with iterative adaptations, learning and improving from mistakes/successes with clear metrics from customer feedback.
 

Myth #6:  WE DON’T NEED AGILE COACHES. Agile Coach = Scrum Master

REALITY: Agile is about people before processes and the Agile Coach is here to help the team adopt effective mindsets and behaviors individually and as a team: Agile is a way of thinking, acting, and interacting.

  • The functions of a Scrum Master are to carry out all those projects that use a Scrum methodology from the elaboration of the product backlog, sprint backlog, the sprint itself, and the burndown of the tasks carried out and everything that remains pending.

 

Conclusion

Agile does not have to be a buzzword. It is what you need it to be. don’t copy/paste what others do. Find what works in your organization. BE the agility you want to see in your organization: Agile is not a destination it is a mindset and a way of working together.

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.
doing agile vs being agile
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.