I wrote an article last week on Waterfall vs. Agile, and while I didn’t get into too much detail then, I did commit to writing again and expounding on some of the thoughts I have on the topic.
Before I start, I have to mention that I’ve read a lot about Agile (and have experienced many close-approximations) over my career, however, it’s not until I started working at my current employer that I finally experienced what I consider the agile promise-land.
So, credit to the solution leaders and Scrum masters that have honed my perspective on the topic!
What is Agile and why does it matter?
The term Agile is actually an umbrella term as it doesn’t refer to a single methodology. Agile principles were first popularized in the field of software development following the creation of a “Manifesto of Agile Software Development” by Kent Beck and a few others in 2001.
Some of the common Agile methodologies that you might have heard of are Extreme Programming (for software development), Scrum and Kanban (for software-project-management practices).
While Extreme Programming is dreamy, you’ll be hard pressed to find faithful implementations of it at most companies. However, over time, a lot of its teachings (and their benefits) have been accepted into the programming world’s set of best-practices (e.g. Test-Driven-Development, Pair-Programming…etc).
On the other hand, a few different Agile project-management methodologies emerged as well, each with their own unique strengths and areas of focus. The most common of which are Scrum and Kanban.
In this post, I plan to focus on Scrum specifically as it’s the more popular of the two, but, please note that a lot of companies use Kanban and are quite happy with it as well.