Agile.
This word once symbolized progress. It symbolized a new way of developing software. A better way. The correct way.
But now we’re at a point where this word has a whole different meaning to some us. And it ain’t good.
Agile means endless meetings. It means dailies, weeklies, sprints, kickoffs, and retrospectives. It means scrum masters and updating everyone about every tiny insignificant thing you do.
You can’t poop if there isn’t a JIRA ticket for it. And you have to give an estimate about how long it’s going to take. And then you need to update how long it actually took you when you’re done.
You can then discuss with your team leader, if you have one, why your potty break took twice longer than expected. And between you and me, that’s an awkward conversation to have about last night’s burrito.
But seriously, How did we get here? Where does the line cross between transparent accountability and a bureaucratic nightmare?
Waterfall - He who must not be named
Every hero needs a villain.
When MongoDB came along, relational databases became the enemy. When C# came out, Java was the enemy. NGINX has Apache Server. You get the picture.
Agile proponents vilified the term “Waterfall” beyond recognition. They, of course, refer to the waterfall software development methodology. Which is a fancy way of saying you should do things in incremental steps.
You get your requirements. You design a solution. You implement it. Verify it’s working, and then maintain it. Simple.
The main problem here is that Waterfall has no feedback loop. Between collecting your requirements and the first release of your code there’s usually a significant amount of time. Significant could mean a month, a quarter, a year or more depending on the context.
There are several responses you can expect from users when you finally deliver your end product:
- “Wow! This is exactly what I wanted. Thank you so much!” - In your head, this is a 90% probability. In reality, you’re more likely to run into a dancing unicorn followed by three leprechauns than getting this result.
- “This looks pretty good. I just want to make a few adjustments. Also, that part doesn’t do what I meant.” - Your user then goes on for 20 minutes about all the different tweaks that need to be made. Most of them are minor. This the best case scenario.
- “This looks nice. But what I really wanted was…” - And then they go on to describe a change that turns your entire architecture and basic core assumptions upside down. This is a typical Waterfall scenario.
- “This isn’t I what I wanted. It’s all wrong.” - And then goes on to describe an entirely different system than the one you talked about 4 months ago.
The reason scenarios 2,3 and 4 happen isn’t because your users are inherently evil. Even though sometimes they act like demons from hell.
The real reasons are much more straightforward. Things change. What they needed half a year ago isn’t what they need now. That didn’t know what they wanted until they saw it. They couldn’t articulate it correctly. They were drunk.
It doesn’t matter. The end result is that your users aren’t happy, and you’re unhappy. Regardless of who’s to blame or who was right.
So how do we prevent a situation where both us and our users picture each other dying a horrible death?
Getting Agile
The birth of agile started with the Agile Manifesto. Long before you had a scrum master, agile was alive and kicking. Agile is based on twelve eye-opening principles. These principles are as true now as they were during their time of writing.
But these principles are general guidelines and don’t provide a concrete way of doing things. That’s where Scrum comes in.
If Agile is the spec, Scrum is the implementation. Scrum masters, retrospectives, dailies, weeklies, etc. All originate from Scrum.
And this is where what I like to call The Great Divide comes in.
You see, everyone agrees agile principles are good in general and should be followed. At least in spirit.
But Scrum is a whole different issue. Doing Scrum by the book could lead to mass suicide by everyone on the team. But not enough Scrum could mean you’re “missing out” or “doing things wrong.”
So where do draw the line?
Scrum Like a Boss
Here are the most common Scrum buzzwords you’ll probably run into.
- Sprint - A short period of time. Usually a week or two. At the end of the sprint you should have at least one deliverable.
- Deliverable - Is something you can deliver to your users. Something tangible that can be tested and used to some extent. Even if it does almost nothing.
- Epic - An epic is a big ongoing project. Example: “Google Search Page”
- User Story - A set of actions a user does in your program. Example: “User enters a search query and then clicks the search button.”
- Task - The things that need to be done to fulfill a user story. Example: “Create a search input field.”
- Scrum Master - Someone who’s in charge of nagging everyone on the team and ask how they are doing with their tasks. Think of a project manager who’s also a developer.
And now for the truly enjoyable part, the meetings…
- Daily Standup Meeting - The heart of Scrum. Every morning the team gathers-round and each member says what they plan to do today. Everyone should be standing up as the name suggests. To keep the meeting short. I’ve never been to one where we actually stood.
- Sprint Kickoff Meeting - This is where the team + project manager + R&D management go over what each team member will deliver during the sprint. These are the same tasks you’ll be reporting on in your daily standup meetings.
- Grooming Meeting - This is where the team gets presented future tasks, and they try to give a time estimate and assess its difficulty. These tasks can then be placed in future sprints.
- Retrospective Meeting - This happens when something goes wrong. You get all the people involved in the room and try to figure out why the bad thing that happened. You try as much as humanly possible not blame individuals. Instead, you figure out the process that caused the screw-up.
Nine times out of ten you’ll end up with another level bureaucracy to prevent future individual screw-ups. - Sprint Review Meeting - A meeting that’s supposed to be held at the end of every sprint. Regardless if it turned out good or bad. I’ve never been to one.
Is Agile Worth It?
Definitely, but up to a point.
Over the years I came up with a simple rule you can use to figure out where you are on the hell vs. heaven spectrum of agile.
Are you doing Agile/Scrum practice X for the sake of development effectiveness or for the sake of “Being Agile?”
Scrumming all the things, without applying critical thinking into whether or not these practices fit in your company is a recipe for wasted effort and disgruntled developers.
But selecting and gradually implementing Scrum and agile principles could make a big difference.