“Fast, good, or cheap. Pick TWO.”
If you’re a professional software developer in this day and age, chances are you create software using the agile/scrum methodology.
I’ve blogged plenty about this before, but in a nutshell, it’s a way of developing software that is significantly different than the traditional “waterfall” methodology of software development.
What Is Waterfall Development?
Waterfall development was a way of developing software where all the upfront planning, analysis, and project requirements happened before a single line of code could be written.
Only after all the analysis and project requirements were completed could software programmers actually go out writing the computer code to implement the project.
Sometimes the project analysis and requirements gathering could take weeks, if not months.
This was a lot of time for software programmers to have to wait around and spin their wheels. And as we all know, software programmers aren’t cheap. It costs companies lots of money to keep them happily employed.
The problem with waterfall development is if the project requirements change or the original analysis was flawed or incorrect.
Not too surprising… how many of us get things perfectly right the first time? The same goes for project requirements.
Often times, we may initially know what we want, but then we change our minds. Or want new or different things.
This happens all the time.
But waterfall development’s core tenant is that project requirements shouldn’t ever change. Because if they do, everyone must literally go “back to the drawing board”, so to speak.
Any active software development must immediately stop until the new project requirements and analysis have been redone. Any other steps further down the line after the active software development phase… QA testing, documentation, etc., must also halt and wait until the new project analysis and requirements gathering have been redone.
It’s the primary reason why the whole agile and scrum movement came about, as a way to address the shortcomings of traditional waterfall development.
How Agile Works
Agile development eschews the notion of big upfront analysis and design.
Instead of waiting for the entire analysis phase to be complete, agile tackles a software project in little chunks at a time.
Scrum, which is a specific implementation of agile, is about tackling these chunks of a software project, into definitive and finite slices of time called “sprints”. Sprints are usually 1-3 weeks, and during a sprint, a software development team works on specific project requirements.
For the duration of the sprint, the software team concentrates only on the project requirements agreed upon by the software team and the role referred to as the “product owner”, who is the person responsible for writing down the various requirements of a project, into entities called “stories”.
A story essentially represents a “chunk” of desired functionality of the overall software project.
Perhaps one story is about establishing the connectivity to a specific database. Another might be about designing the login page of the application. And another story could be adding a logging system so that all important activity within the application is properly recorded and permanently persisted in an external database.
The stories are designed in a way so that the time estimation to complete those stories will fit within the duration of a sprint. In fact, any stories that are estimated to exceed the duration of the sprint, are either pulled out of the sprint or perhaps split up into smaller stories so they will fit within the time constraints of the sprint.
The goal of each sprint is for the team to finish all the stories agreed upon during the beginning of the sprint. At the end of the sprint, the team can proclaim that a chunk of the overall software project has been completed.
Over the course of time, story after story and sprint after sprint, the project gets more fleshed out, more complete, more functional.
So what happens when a monkey wrench is thrown into the fray? Say the product owner decides to make a major course correction on the project and wants to change some core feature of the project to something else entirely.
If the product owner happens to change the project requirements during an active sprint, scrum dictates that the sprint finish, without interruption. Only when the sprint ends, can the product owner reprioritize what the team needs to work on next. The product owner can then slot in the new story requirements into the next sprint.
This “course correction” mechanism, is the primary selling point behind agile/scrum development methodology.
The flexibility to adapt to changing project requirements is a reality for most software applications. When I look back at my own programming career, I can’t recall a single project I’ve tackled where some aspect of the requirements haven’t changed over the course of development… it’s the nature of software development.
And it’s why agile and scrum has become so popular. Waterfall development methodology still has its place. Many government agencies and institutions still favor waterfall development … it seems to fit within the “DNA” of many government institutions, where everything is carefully thought ahead of time and there is a natural aversion to change.
I’ve worked at government agencies at the city, county and federal level, and I can attest to the fact that changing requirements are frowned upon.
Of course, no system or methodology is perfect. Everything has flaws and shortcomings and agile and scrum are no exception.
The Problem with Agile
Many developers, including myself, find shortcomings with agile and scrum.
While many people consider the aspect of changing requirement adaptability a huge plus, many developers see the negative consequences of this.
Since agile and scrum discourage big upfront analysis and design, it can often lead to the misconception by many product owners, executives, and managers to the unfortunate conclusion that analysis and upfront design is a BAD THING.
Sadly, many fans of agile go so far as to discourage developers from factoring in what are referred to as “research spikes” or “research stories”, when a developer needs to implement a particular technology, but doesn’t currently have the knowledge and know how to implement it.
And why? Because they consider it “big upfront design”, which they equated to traditional waterfall development.
I call baloney on this.
I think deep down, a lot of these product owners and other non-developers, who don’t actually possess the technical skills to implement the story deliverables themselves, support this notion that analysis and design is a bad thing because it simply takes time away from the actual of writing code.
They seem to forget, or don’t want to acknowledge, that analysis and project requirement gathering is still a crucial necessity for any successful software project.
But they want to “have their cake and eat it too”. That is, they LOVE the notion that they will get their software deliverables done FASTER but without the time-consuming act of doing the necessary presswork of analysis.
In fact, many proponents of agile and scrum often like to use the term “analysis paralysis” to discourage software developers from doing any sort of project analysis.
Lately, it’s been bothering me quite a lot when I experience this kind of attitude from non-software engineers.
It places unrealistic demands on the software developer and reinforces the incorrect notion that “Agile development” equates to delivering software FAST and CHEAP.
Well, those folks seemed to have forgotten this classic saying, “Fast, good or cheap. Pick TWO”. They love the notion of agile, because they think you can have all THREE without paying for it.
In the long term, I wouldn’t be surprised if many developers rebel against the current concept of agile and scrum. That’s not to say they don’t produce results if applied properly.
But it just seems to leads to too much potential for abuse. I’ve personally experienced this attitude from multiple product owners and managers who think that the agile way is all about doing things quickly and perfectly without any analysis.
There needs to be downtime between sprints. Where developers can take a breather and do other things like training themselves on technology and concepts that could benefit the team in the future. Or spend the necessary time to research some specific future story requirement that they don’t currently possess the technical skill to implement.
And if companies and organizations continue to abuse this incorrect notion, they’ll find themselves with the possibility of a mass software developer exodus on their hands. Developers are highly in demand these days, and they often “vote with their feet”, if they don’t like the methodology by which software gets written.
I certainly wouldn’t want to be the product owner or hiring manager who ends up being responsible for a mass developer exodus. And neither do they, one hopes.
