Category: Methodologies

The promise of Agile!

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.

Continue reading “The promise of Agile!”

Software Delivery: Waterfall vs. Agile

Over my career, I’ve seen and participated in a lot of Waterfall projects, and a lot of “agile” projects.

I have personally really soured on the Waterfall methodology after a really large project where we spent months designing a solution and documenting a specification.

During those months of “solutioning”, the business would regularly change some requirements/business processes in response to changes in the market and each change meant a new change-request, a new scope, and a ton of fixes and updates to this ever-expanding specification along with the associated library of UML diagrams (think thousands of them).

Suffice it to say, this is a rigor that is completely inappropriate for 99% of software projects out there. Sure, there’s that 1% of projects that require absolute details for a specification upfront, but, what most projects these days actually need is a continuous collaboration between the business and development teams and a much more responsive and agile approach.

Having said that though, I’ve also been on a variety of Agile projects that could be best classified as “barely” Agile.

I think a lot of companies and teams want to speak the same language as the cool kids, and so they start talking about 2-week sprints and they add a daily standup meeting (where everyone is actually sitting down) and call themselves Agile.

Sure, that’s a step in the right direction, however, I firmly believe that the maximum value of doing projects in Agile comes from implementing every last aspect of the Agile methodology.

In my mind, the best argument for adopting every last agile commandment and performing every last ceremony to the letter is that the “whole” is definitely more than just the sum of the parts.

I have a lot of thoughts on what this “whole” comprises, so check back soon for a full description of what I think is the agile promise land!

Update: done! Read part 2 here: The promise of Agile!

Till next time,
MJ