There’s a certain, what I like to refer to, as an “Agile meme”, that I seem to constantly hear in the Agile development world.
“Analysis Paralysis”.
And to be honest, I really take issue with the meaning and context of that word in Agile development methodology.
Here’s why.
The whole Agile/Scrum movement was born as a sort of revolution against the older Waterfall software development.
Waterfall development breaks up a project into sequential phases. The first phase is usually the analysis and project requirements phase of a project. A business analyst begins formalizing all the details of a new project, involving lots of design and analysis meetings with the business customer, until a formal project spec document is created.
At no point can any actual software development can begin until this initial design phase has completed. The project spec must be COMPLETELY FINISHED and contain every single nitty gritty detail about what needs to get implemented in the project before the next phase of the project can begin.
Hence the term, “waterfall”. Each distinct phase of a project must be completely finished before it can “spill down”, like a waterfall, to the next phase.
Only when the design phase is completed, can the software developers begin the actual software development phase of the project.
When the implementation phase is complete, the QA testing can begin, and on and on, until the customer signs off on the final project deliverable.
This is, of course, the “happy path” of a project, when everything does smoothly, and it’s all rainbows and unicorns.
But what happens when the project turns from rainbows and unicorns to getting IRS audited and spending an entire day at the DMV?
What would happen, for argument’s sake, if the project customer changed her mind about some major feature of the project that has already been implemented by the software dev team and thoroughly tested by the QA testers?
Unfortunately, this isn’t as easy as it sounds in Waterfall development. In a pure waterfall development driven team, the business analyst must create new analysis and project requirement specs for the desired changes of the business customer.
And the whole waterfall process begins anew. Only when the revised project spec is completely finished can the development team begin implementing the desired revision requirements. And then QA, and on and on until you have a new deliverable.
Quite an expensive undertaking to make changes to a project.
The rise and popularity of Agile and Scrum was born out of a desire to move beyond traditional waterfall development.
Agile development differs from Waterfall development by acknowledging there is no such thing as perfect project requirements. Nor such a thing as a completely finished project.
It also eschews the whole waterfall concept that changing project requirements is a bad thing.
In Waterfall development, changing a project midway through development is a very expensive operation.
In Agile/Scrum development, changing requirements is expected and embraced.
In a nutshell, scrum development is able to embrace changing requirements with the concept of a “sprint”.
A sprint is a relatively short (2-4 weeks) period of time where a development team focuses on a number of features of a project (called ‘stories’). Each story represents a desired piece of functionality in a project.
During the sprint, the software development team only works on the stories in the sprint. At no time can someone outside the team dictate they work on anything else, including the customer the development team works for.
By embracing the concept that project requirements are not set in stone and can change anytime, agile and scrum do away with a lot of things that traditionally happen in waterfall development.
Like dedicating time to do project analysis and requirements gathering.
Sure you can work on stories to research things during a sprint. But I guarantee a team will get frowns all around if they spend an entire sprint working on nothing but research and project requirements gathering.
There’s even a phrase for spending too much time on research…”analysis paralysis”.
It’s supposed to mean that spending too much time and effort researching HOW to implement something is better spent actually DOING it.
The time and effort spent on potentially wasted code isn’t really a waste, according to many agile and scrum advocates. Supposedly that time and effort helps a developer gain better and more accurate insights on getting it right the next time.
I’ve noticed that the people who believe in “analysis paralysis” never seem to be the ones responsible for actually implementing the work in a sprint.
Which is why I say “malarkey” to this implication that spending a good amount of time and effort understanding project requirements is a bad thing.
Agile and Scrum may be the current and popular new methodology of developing software, but it won’t be around forever. After all, waterfall eventually fell out of favor, didn’t it?
If there’s one thing I’ve learned over the course of my software development career, the only thing that you can constantly rely on is CHANGE.
Spending the time to understand things you don’t have enough knowledge about to implement a desired piece of software functionality is absolutely essential to getting it done right.
The Agile movement argues that you’ll NEVER be able to perfectly understand the requirements of a project, so why even bother spending too much time doing research? Just start doing it?
I wonder if those same advocates would trust riding up a 50 story building elevator that was designed and built the agile/scrum way by engineers who never bothered spending upfront time and research to design an elevator the proper way?
Or what about driving over a bridge where engineers didn’t spend the time and effort creating a blueprint for the bridge? Can they afford to take a ‘first stab’ on building a bridge, and going back to the drawing board if they discover flaws in the completed bridge?
I’m actually serving as the scrum master of my development team, as well as a developer.
Our team is spending an entire sprint, every day in the sprint, studying and reviewing some existing codebase, in order to get a proper understanding of the inner workings of the current system this codebase is part of.
I can assure you that the product owner and our development manager is getting antsy with our team for dedicating an entire two week sprint, just doing research. I’m sure they would be much more happier if they actually saw us start coding right away.
After all, we wouldn’t want to get into … * start drum roll * … ANALYSIS PARALYSIS, would we??
Lots of non software developers equate coding with productivity. The more code you see, the better!
Nothing could be further from the truth.
In reality, every line of code creates potential new technical debt down the road. I don’t care how elegant and clean code can be. Every line of code means support and maintenance down the road.
The less code you have to write for a project, the less maintenance headaches you create for yourself and for others who have to support your code in the future.
Spending enough time making sure you understand project requirements means you won’t have to keep “going back to the drawing board”, that is, going back to the source code of a project, and fixing things to get it right, which in turn, reduces technical debt.
As a kid in the early 80s, I was glued to Saturday morning cartoons. Like Transformers. And G.I. Joe: A Real American hero. G.I. Joe used to pepper their episodes with little mini public service announcements for children. Like checking the door for heat during a fire and choosing an alternate escape route, if the door is too hot. Or avoiding standing water during a lightning storm.
At the end of each mini PSA, a G.I. Joe character would end the announcement with ” and knowing is half the battle.”
Half the battle indeed. More like KNOWING is more like 80-90% of the battle.
