Waterfall, extreme programming, sashimi, scrum, kanban or scrumban?
This article answers exactly that question and puts a stop to those endless heated office discussions. Period. Forever. Period.
You will be forced to digest an overwhelming set of postulates as basis for arguments that will support my proposition: I am right. This will annul everything you have known or thought to have known. Reader discretion is advised, since you will experience cognitive abuse upon being bashed to unconsciousness with indisputable arguments. You will go through all stages of a grief cycle upon realization of how right I am and how wrong you were: from shock and disbelief, over to anger and guilt, all the way to acceptance. Without further ado, let’s begin the healing process:
Shock
Despite the fact the answer was in front of you all along, but you could not see it, here it goes: 42.
Disbelief
Making the decision on a software development methodology is based on various factors: nature of project, team’s size, team’s quality, just to name a few. Since all of these factors differ from case to case, overselling any of the mentioned methodologies and picking a single one would simply be a fallacy.
Anger
Recognizing that article’s title was purely bait and that it’s impossible for me to provide a “one size fits all” answer.
Guilt
As much as feeling guilty for wasting time to read this, feeling even more guilty about wasted time in pointless arguments with your colleagues. All this wasted time could have been spent on actual software development.
Acceptance
Acceptance is about using the lessons learned. Despite the cynical writing style, there are two lessons here to take away.
Firstly, it’s pointless to go into a discussion on what’s the best methodology. That usually ends up into a philosophical infinite loop. The only people that should get into that loop are PhD candidates that need to satisfy the number of published papers criteria in order to get their doctorate or paid-by-the-hour consultants trying to save a lost-cause software company by convincing them that all their troubles will be solved by picking the “right” methodology or technology (more about that in another article). Either way, one gets the doctorate and the latter the consultancy fee. You, on the other hand, in case you got into that discussion, will only waste time.
Secondly, it’s a good idea to make an informed decision when picking a (or multiple-hybrid) methodologies that align best with the project. That entails learning and weighing the pros and cons of each methodology case by case. I was both fortunate and unfortunate of being a dinosaur that experienced the pros and cons of waterfall on my own skin, primarily the non-iterative mode that doesn’t flex in an environment where the requirements change. Thereafter, we picked up on scrum hype and adopted it as the best thing since sliced bread, but the short-term, forever sprinting developers that burn out and “terminal juniority” turned us more towards kanban. Somewhere in between all that, we’ve experimented with extreme programming, but I left that company only to learn that it went down a few years later. Not to say that this was due to extreme programming, I have seen projects fail and succeed in each one of those methodologies and the reason for that was never the methodology itself.
Currently our methodology is a hybrid that we’ve naturally evolved over time. We like how scrum defines stakeholders and product owners and their responsibilities. This helps us communicate and translate clients’ requirements towards developers. On the other hand the development teams are more inclined towards kanban style. Additionally we often find that some tasks are best handled by pair programming.
So what should we call this hybrid? XP Scrumban? I frankly do not care about the name as long as it works for us. I am sure that we’ll adjust and correct that hybrid methodology down the road if the need should arise. In short, there’s absolutely no need to be dogmatic about a single methodology.
Spotify is a good example of a successful company that was adaptable enough to scale quickly and adapt their methodology over time. Being adaptable is probably the key here. Instead of dogmatically enforcing a single methodology, they let it evolve over time and take away from lessons learned.
Hacker Noon is how hackers start their afternoons. We’re a part of the @AMIfamily. We are now accepting submissions and happy to discuss advertising &sponsorship opportunities.
To learn more, read our about page, like/message us on Facebook, or simply, tweet/DM @HackerNoon.
If you enjoyed this story, we recommend reading our latest tech stories and trending tech stories. Until next time, don’t take the realities of the world for granted!