Top 3 Agile Myths among IT Corporates. (Includes a Bonus Myth FREE!)
Recently, I had the opportunity to attend the first Scrum Alliance backed Regional Scrum Gathering India 2014 (RSGI ’14), at Hyderabad. This two day conference was like being in an ocean overflowing with experience, knowledge and learnings accumulated from across the globe. Needless to say, I had more than my fill of learning and evaluating where I stand in the world of Scrum practitioners, and more importantly, in the Agile community. After absorbing the heady concoction of knowledge and experience, I took some time off to relate to how my real life experience – both past and present, align with the objectives I had when I wanted to attend this conference.
After plenty of deliberation, I realized that there are many common myths most organizations fall prey to, while trying to be Agile. So here goes..
The top 3 Agile myths, and how to correct them
Myth #1 – SCRUM IS THE ONLY AGILE PRACTICE!
This is oft repeated and heard – “We are an Agile Scrum company”. Sorry, that does not make much sense to me. Let’s get the facts right: Agile is a set of principles that gives guidance and direction, while Scrum invokes those principles to provide a framework for software development. More importantly, Scrum is NOT the only practice/framework available under the Agile umbrella. There are plenty of other Agile practices such as eXtreme Programming (XP), Crystal, Kanban, Test Driven Development (TDD) etc. All of these practices have unique objectives depending on the need and nature of the work – but use the Agile Principles at their core.
So, the next time you assert that you are an “Agile Scrum” company, think twice about where you stand. I highly recommended that you differentiate between Agile principles and frameworks such as Scrum, which invoke those principles. This leads to Myth #2 below.
Myth #2 – Agile Principles? Duh! What’s that?
Have seen many Agile practitioners, including yours truly go bonkers when individuals and companies alike claim to be Agile without ever having read or understood what the Agile principles are. More often than not, people miss the point that these principles are the fundamentals which act as the guiding light on how to be Agile. Instead, they become more engrossed on following a process/framework without even bothering to understand why, or what the benefits of “a particular” framework are. But before that, a sneak peak in to what the Agile Principles are –
The names in the picture above are the brains that got together and used their collective wisdom, experience and vast knowledge of software development shortcomings to formulate the principles that form the bedrock of Agile frameworks/processes. To read a more detailed and descriptive version about the principles, click here.
Myth #3 – Scrum is the magic potion to solve our problems, let’s get started.
Scrum – a very popular practice that is gaining more attention across organizations, because it is a very successful one. Sounds great? Of course! “So, we start following Scrum and we become a highly efficient team in a flash!” Organizations implement Scrum overnight, run it for a few weeks, and they realize – nothing has changed. Old problems still exist. “But wait we did all the ceremonies – daily stand ups, product backlog grooming, sprint planning and every other thing by the book.”
So, why does this happen?
First, did you as a group do an objective analysis on why you need to implement an Agile practice? What are you trying to solve, that keeps recurring every second day and affects your work? Are you willing to change your mindset and accept failure, to be Agile? There are many such questions that have to be answered before setting out to be Agile. All of these questions are summarized in the image below –
To highlight how organizations typically invoke Scrum let’s take a look at the famous cartoon character Dilbert and his experience of trying to be Agile.
To summarize, before trying to make the transition to a more Agile approach, it is well advised to honestly answer the below mentioned questions –
- What is your objective in trying to follow an Agile process? Do you have specific issues/problems that are to be addressed?
- Do you have a complete buy-in for the transition – from top management to the junior most developer who will be impacted?
- Are you willing to change your mindset, and even embrace failure? Are you looking to incorporate Agility as a value and culture?
When you have stared addressing these questions to begin with (you may uncover more in the process), there will be greater clarity on whether you need to make the transition or not. And if the need is to make the transition to an Agile environment, then do understand that Scrum is not a one size fits all solution – there are plenty of other options available. So pick and choose what fits your need, and even use bits and pieces practices without deviating from the core Agile principles. For a broader perspective, I would recommend reading Mike Cohn’s blog that addresses some of the above questions.
Myth #4 – Bonus Myth: I am an Agile expert
In the course of writing this blog, if at any point I sounded like a know-it-all expert, it would be my prerogative to correct that myth. I have just made a humble attempt to share the limited knowledge and experience gained in my journey as an Agile student, and more specifically, a Scrum practitioner. I will be more than happy if any of you will challenge/disagree/debate anything that you feel is inappropriate. I am great believer that : “Being Agile means Continuous Improvement and Continuous Learning.”
P.S. – All images have been credited accordingly and produced here for the purpose of learning, please let me know if I have missed acknowledging or crediting any source. Will make necessary corrections.