It would be extremely time consuming to write a detailed analysis on all the myths - I'm not aware of all the myths anyway, but I'll attempt to add content incrementally, over time and as I learn as well. In some cases will try and add an image or a video that can succinctly explain the point. Hope that sound like a fair deal - trying to be agile in my approach.
I'm a firm believer in an agile way of working and strongly believe that it is the best way to work for reasons that are beyond the scope of this article.
Image reference: http://www.eylean.com/blog/2016/04/best-agile-comic-strips/
Agile is dead, long live agility - Dave Thomas. Seriously, nothing could've explained the current situation of the majority of the "agile" market better and more succinctly than this statement. Do I believe in everything he says - no, but do I respect him for his views - yes. Dave was one of the 17 people "middle-aged" people behind the agile manifesto that was meant to be the guiding light of a new way of working - an agile way of working.
Instead what's happening amongst others, but not limited to, is the following:
we are agile because we use a framework
we are agile because we are certified
my way or the highway
you know nothing
we are agile because this is exactly what agile is
we are now 100% agile because our maturity assessment says so
we are agile because we use JIRA
we are agile because we do all the ceremonies and our standup is less than 15 minutes
etc...
Myths
Whilst the agile movement has picked up pace and has gained more and more followers with time, and for good, it has brought with it a lot of myths. I'm not claiming to be an agile god and neither do I claim myself to be an expert in everything that's agile but some myths are worth mentioning so that we all can learn what to avoid and what not to avoid. This is merely a medium through which I'm trying to express my views.
agile was invented by the "manifesto guys" - there's no doubt that the contribution of the 17 is unfathomable and my sincere respect to them for what they have done and achieved, but to say they invented agile is a travesty. I can bet you if you said this to any of the 17 they would probably blush and change the topic. The image on the right (courtesy my dear friend Duncan Ham) is an ode to people, in modern times, who have tried to improve the way we work. There's countless others and the 17 are a part of that group. Sincere apologies if I haven't been able to represent everyone here. They have contributed as much to an agile way of working as the 17.
agile is only for software development - if agile was only about software development then Deming's Plan-Do-Check-Act/Adjust "PDCA" framework documented in 1950 should've been associated with software development as well. It was a framework to iteratively improve products and processes - sounds familiar to some of the terms (e.g. inspect and adapt, build measure learn, etc...) we use, doesn't it. You can be agile in any domain, industry, team, project, etc... as long as the ethos of the values and principles are used as a guiding light. If you have your own organisational values and principles then use them as well as long as they make sense and help you continuously improve.
agile = scrum - at it's heart scrum is a guide on how to organise people and teams and build an inspect and adapt way of working around them. It talks about ceremonies and roles and an operational cadence that runs around them to help in the endeavour of inspecting and adapting. I liken it to a design pattern (please read my article on what is agile). It helps solve commonly occurring issues in the way people work. If you're doing scrum ceremonies well but still are not delivering incrementally as per the client's expectation or continuously improving, then I'm afraid you're not very agile.
agile = cloud - moving to the cloud is certainly an important aspect of being able to deploy, provision environments, using 3rd party services, etc... quicker and possibly cheaper. But the journey to being agile doesn't really stop there. By all means move to the cloud if it makes sense but stopping your transformation journey thinking you're done is not enough. You have to keep persisting and improving. For e.g if you deploy a monolithic application to AWS and you're still taking 24 hours to deploy it then you're not going to be very agile in your way of working. But if you can gradually evolve your architecture to modern architectures e.g. micro-services, lightweight frameworks, auto scaling, etc... then you're definitely being more agile than what you currently are.
agile means I'll lose my job - no one is losing there jobs due to an agile way of working. You should be more scared about losing a job to a robot. An agile way of working does talk a lot about automation and reducing the dependence on manual and repetitive processes and tasks but it also speaks volumes about cross skilling and getting innovative with how you conduct your business e.g. insights and analytics. All this needs people. For e.g. testers can become fantastic business analysts, they can help in deriving metrics and automate dashboards, they can automate tests and ensure the the CI pipeline is healthy. The list can go on an on. The idea is to focus on a team and cross skill people in other roles and areas within the team.
agile is only for some projects - well for starters you can build a car. Didn't think that was possible. Check out this video on Wikispeed. Need we say more on this. Anything can be built or maintained or patched using an agile way of working.
agile guarantees delivery of my project - not if you have unclear requirements for starters. If you don't follow basic hygiene factors, like gathering the right requirements, you will never be able to deliver. So agile doesn't guarantee anything but an agile way of working can almost guarantee that you will de-risk your project much earlier than in a non agile way of working.
we're now 100% agile - agile maturity assessment, specially the ones that are poorly crafted, are not a certificate for your agility. Image ref: http://rgalen.com/agile-training-news/2015/1/2/agile-journey-index-a-balanced-guide-for-continuous-improvement There's always room for improvement. For e.g. we will not be more agile if we make only our standups better. Let's do a small exercise. Think of any company that you deem as the epitome of agility in the world. Usual suspects are spotify, google, apple, netflix, etc... Now go ask any of them if they think they're fully agile or 100% agile. The answer will be a resounding 'NO'. Yes they're all doing great things in their rights and respect but there's always scope for improvement and they're continually striving for that.
agile means no documentation - one of the values in the manifesto says "working software over comprehensive documentation". Image ref: https://yanado.com/blog/what-is-agile-project-management-methodology/. This does not mean no documentation. By all means document things but endeavour to document only things that are necessary. There are a few pointers I give in terms of what I consider useful documentation (will write an article on this)
agile means no governance - scrum also has an element of governance in it. In fact anything that has the word framework in it means some form of governance or discipline. If your definition of governance is a 6 month gated processes to get funding for anything you do and then a 2 month release process just to satisfy some random audit requirement and senior management, then no governance would seems very tempting or at the least we need to change how we govern our work and teams. By all means build your own governance framework, if required, as long as its pragmatic and adds value to your work, people, teams and processes - certainly nothing like the one described above. Image ref: https://www.youtube.com/watch?v=kOCkUTN-ZNI.
agile means no planning - there's more to launching a product than writing code and CI / CD. If the delivery team have committed to launch by a certain date and the marketing team have lined up an advertisement blitz, then we need to be ready by that date. If we feel we won't make it by that date then what can be negotiated (reduced) is scope. Reduce the scope if you have to, but try and launch something usable on the date in order to move with the organisation. This phenomena of providing a straw-man's roadmap with tentative dates is called planning my friend. Plan change all the time so, by all means, keep it as lightweight an activity as possible.
agile needs to be scaled - one of the key tenets of an agile way of working is small teams, "thin vertical slices" of business value and functionality, etc... and then we go on to talk about "make them independent". If we have a firm belief in these 2 then what exactly are we trying to scale. Rather the focus should be on iteratively becoming smaller and independent - organisation, teams, projects / product, architecture, etc... By all means have "light" alignment sessions (that do not last 2 days) and arrive at a straw-man's roadmap, but do it quick because the plan will change. The image talks about the Eurozone union no matter what the weather. Well, looks like the phrase "when it rains it pours" got taken in an entirely opposite context - Brexit happened. Don't scale a system that can be made into a harmoniously working ecosystem of independent sub-systems.
agile is a silver bullet
Do you agree with the myths above, have you heard of any that have not been mentioned. If yes please do drop in a comment and I'll endeavour to incorporate it in the article.
Happy days and happy learning and sharing :)