In my agile journey having to work with many organizations, multiple teams, and professionals who were very keen on adapting agile, I have observed many myths and misunderstandings. I have seen in most cases, these mythical understanding have become ‘common knowledge’ among the agile teams. Let me explain many myths that I observed in the community and why these are just myths!
Myth: Only Teams must be agile but the organization remains to be traditional!
This is the biggest reason for failure and wastes a lot of money in your agile transformation. Once, I went through a series of interviews with a big company for an agile coaching opportunity. It was supposed to be a long-term contract —I was asked to help them transform into agile. I thought it will work out and I proceeded. Would you believe that it took 10 months for its HR to draft the contract? So many hierarchies, so many internal conflicts about the role, my pay, its hierarchy within the org structure and issues were endless! HR was so chaotic! the organization was too hierarchical to be agile, a hiring decision could have been taken in a few days took 10 months! I decided to defer the offer! My point is that if you want your teams to be agile, you must start it within the leadership. In an environment like that, agile will never work. Be prepared to change the culture to fit the agile mindset and behaviors. Adjust your leadership approach, support your teams with what it takes to be agile. Otherwise, your teams will be just good at agile mechanics and you will complain — “Our teams are not delivering the results!”
Myth: Agile is a process
In Oxford online dictionary, a process is defined as “A series of actions or steps taken in order to achieve a particular end”. Does agile qualify this statement? I doubt!
Agile is not a process, it’s a mindset, a set of values and principles. There are agile frameworks that are developed based on the agile mindset, values, and principles and they offer agile practices specific to the given framework.
Agile is a mindset around inspecting and adapting in order to continuously improve, deliver the highest value possible to our stakeholders. It’s a way of working not just a process!
Myth: Agile is new
Well, for me, agile is not new. Agile is all about adaptability to deliver the highest value possible to our stakeholders. Yes, Agile Manifesto was created in 2001, the agile frameworks were introduced within a few decades yet, the core values and principles that agile talk about existed for a long time in human history. Agile is all about inspecting and adapting to a changing, complex situations, and environments where variability and uncertainty are expected.
Myth: Agile implementation is so easy
This is one of the major myths which becomes a huge challenge to implement agile in organizations. The organizations and team underestimate the effort and commitment needed to be agile and therefore, end up adapting a subset of mindsets and practices which will not give the full benefits. Since agile is a paradigm-shift, a lot of things must be adjusted to be successful. It’s very different from traditional thinking and approached adapted by most organizations. Transforming into agile must be started with the attitude or the mindset. A lot of behavioral changes and unlearning traditional concepts and practices must happen in order to adapt agile successfully and therefore, it will never be a straightforward way.
Myth: Agile gives you instant benefits
If you plant a tree, you will surely have to wait months and weeks to see it grows fully and produces its fruits. Transforming into agile takes time and you wouldn’t see instant benefits: Of course, when you change your mindset, your approach and practices, there will be possible changes in your teams, organization that will lead to the better results, but, you would see the ROI directly as you start adapting agile. Agile Transformation follows a learning curve. Please don’t be surprised if you see a downward trend initially. Keep going — inspect and adapt for better results.
Myth: Agile means no documentation
Oh, this one, very common misunderstanding among agile teams and organizations. This is probably due to the misinterpretation of one of the four agile values stated in the agile manifesto — ‘We value working software over comprehensive documentation’. This does not mean, the documentation is not required — it simply means, agile does not fully focus on very comprehensive documentation. What is more valued is working software over the comprehensive documentation. If you had worked in a traditional project, you surely know how much documentation is created for a project. “When I worked for a big company based on Traditional approach, when a highly critical, high priority change request was received, I remember spending 3 hours for the documentation. And the funny part was that the change implementation did not take more than 15 minutes.” — The clients were mad to hear that we spent 3 hours of documentation for a 15 minutes change implementation” — That is why Agile focuses on working software over comprehensive documentation. That said, you need to decide enough level of documentation to ensure that the most important requirements, details, acceptance criteria, and risks, etc. are captured.
Myth: Agile means developing code without a steady design
This mythical understanding can be so costly if believed and adapted. When the teams lack from agile maturity, this is believed. Agile is based on EDUF which means, just Enough Design Up Front. The traditional frameworks follow BDUF that is Big Design Up Front. In an agile setting, you may not be able to create the most detailed, the final design for your product, but, you must have a just enough design while you have thought about the big picture or the big design. “Think Big — Act Small” is an agile architectural concept used by agile. This emphasizes the need for investing enough on your design before jump in — and develop. But, we are not trying to finalize and seal the design for the product — the design will be evolving with time but, will be around the big picture or the design established. Even the design is inspected and adapted for optimized results and performance.
Myth: Agile is a silver bullet
No, it’s surely not the only way for every situation or your project need. Also, I don’t trust that agile is needed for every situation. Agile is not the only answer to all IT problems. If the requirements are predictable and you don’t see a lot of uncertainty, then, you don’t have to rely on agile — may be, a traditional approach such as Waterfall is more than enough. On the other hand, if your environment is too chaotic, and you are unable to act on a specific plan in a certain way. You wait for a knowledge-based response since you never know what the right decision is to take. The only possible approach to take is. “act–sense–respond”: act to establish order; sense where stability lies; respond to turn chaotic into the complex. Where agile is more beneficial is in the situations where you have a complex problem, there is variability yet, you are in a position to approach the solution through — Inspection and adaptation”.
Myth: Agile is all about just the ceremonies
In my agile journey, my observation is that the majority of agile teams and organizations get stuck there. They learn about the practices, maybe they obtain a certification, read a book about agile and start adapting a set of practices based on an agile framework. Let’s say Scrum — Now, the teams are well familiar with the practices and ceremonies such as Sprint Planning, Daily Scrum, Retrospectives, etc. Yes, mastering these practices and ceremonies effectively are must but, transforming into agile means a lot more than that. Adapting agile is started with your mindset and then living up to the agile values and principles which govern the practices and ceremonies.
You are successful, if you can optimize the value delivery, collaboration such a way, your clients are delighted, and your colleagues love what they do and how they work. Success is not just about being able to manage a set of agile ceremonies on time and effectively.
Myth: Agile means no planning, just do it!
In numerous occasions, I am being challenged by agile teams and product owners on this mythical understanding. What can you accomplish without planning? Agile insists that your planning should not totally rely on anticipation. E.g. If you plan for a one-year project using a traditional approach, you are to create a detailed requirement spec and a work breakdown structure, come up with the fully detailed, the final design and implement. This approach is risky! Therefore, what agile recommends is that you go for ‘adaptive planning’ — that means, of course, you must plan but these plans are adapted to suit the changing environment and requirements.
Adaptive Planning: is a great way of planning to ensure, your plans are not outdated, or inappropriate for the given moment. Agile works on short interactions and target in achieving product increments in these iterations. Agile planning is done at multiple levels and in each level, it narrows down to specific requirements. At the highest level, you come up with a vision and product roadmap to guide your implementation. Product roadmap sufficiently describes the product milestones to be achieved. And, then, you may plan your releases over a period to deliver the product roadmap milestones. Basing the Release planning, in every sprint, you are planning your sprint commitments, and this is the most detailed level of planning you do in an agile setting. And, during the daily scrum individuals plan their day! So, how can you say that Agile means no planning? If you say so after all this, you are insane!
What do you think? Have you observed any agile myths in your company and teams? It’s worth sharing because that surely will educate the community and maybe that is the starting point of correcting ourselves!
Niroshan is an experienced agile coach, a project management expert and a keynote speaker with over 19 years of work experience. Taking a servant leadership approach to lead people, he believes in creating high-performing teams empowered to drive change. His vision is to educate and inspire you with his own stories and knowledge.