I’ve noticed a recent increase in project management method “obituaries” – Agile is dead, waterfall is dead, scrum is dead. I believe this sort of negativity should be considered harmful. Why?
Every method was born out of necessity
It’s only natural that in the early days of programming, in the 1950s and 60s, most projects were governed by the guiding principles from other trades, such as construction, that had many similarities. Management could be brought in, even without knowledge of actual programming, to oversee projects, as long as there was a framework to communicate the steps and goals of the project and monitor the progress.
Waterfall method emerged.
Initially, systems were large, software was all-encompassing and monolithic, and everything affected everything. Some other modified methods, such as iterative or overlapping waterfalls, were utilized as well. Then, personal computing happened. Coming into the 80s and 90s, times were very different:
- Operating systems now had standard ways of running custom software
- Programmers themselves over time became managers over new projects
Operating systems’ effect on development
Having an operating system, along with development tools, made it possible to write smaller software, smaller components. Even the simplest waterfall methods would mean making a small piece of software could take months – meanwhile, a sole developer might write a utility in the matter of a few hours.
Without a way to manage these smaller projects, things would quickly devolve into chaos, so lightweight project management methods became necessary. This nicely coincided with the second development:
Programmers to managers
A new group of people was spearheading these projects – people with programming background. They were able to take their expertise, as well as the lessons they learned from how their larger projects had been managed, and turn them into new methods that worked in this new era. Just to name a few:
- RAD (Rapid Application Development) – a big simplification in itself, but it and its derivatives consist mainly of taking in requirements, doing some planning, iterating in development and delivery. This full cycle could be repeated over and over, in smaller chunks, which in essence became…
- Scrum – this solidified the concept of sprints and continuous development, often combined with…
- Kanban boards – becoming Scrum boards: Kanban boards were introduced at a Toyota factory in 1940s, to keep things moving between stages, while giving a visual overview of the workload at each stage. These, combined with development sprints became Scrum boards, to encapsulate a sprint into a board where eventually all items would be in the right-hand ‘Completed’ column.
- Extreme programming and pair programming
Many of these methods fell under the Agile term in the mid-90s, culminating in the Manifesto fo Agile Software Development in 2001.
All methods are still alive and well
There’s really no reason to go after any of these, or even make a statement that simply because someone changed to or came up with a new method within their company, the previous method would somehow be worse for it.
Waterfall is alive
When you step on an airplane, are you more comfortable knowing the avionics software was written with a clear goal from the beginning and that after meticulous planning, that plan was followed through to the letter, then thorougly tested and documented before installing on the aircraft – or if it was done using an agile method with daily development meetups to ensure delivery was done to meet a tight deadline?
In most mission-critical environments, a lot of the development needs to be already done in the planning stage, on paper, without a single line of written code. Additional methods of enforcing code integrity, such as Design by Contract or Defensive Programming can also be brought in to aid in waterfall development of software that must not fail under any circumstances – things such as power plants or traffic control.
RAD is alive
Many environments still need on-the-spot tooling development. RAD combined with graphical tools (think Visual Basic) sometimes means the timeline from requirements to first delivery can be as little as 15 minutes.
Scrum is alive
Scrum may be the most popular tool of choice in corporate environments today, for a good reason – it provides a nice middle ground between waterfall-like stability and total anarchy, while visually representing the progress in the form of scrum boards and burndown charts. Some teams even have eliminated most of the recurring within-sprint meetings, as developers track their progress within the tasks themselves to feed the boards and charts.
Pair programming is alive
While pair programming can be extremely useful under a tight deadline, it’s even more useful when introducing new developers to a project.
Agile is alive
Agile is not a framework but a way of thinking. Even if all the agile methods would cease, as long as agile-thinking developers are alive, agile is alive, and will manifest in different methods.
Be happy, it’s good for you
As mentioned in the beginning of this article, I believe the “obituarian” negative communication that’s been around since the Internet and alive and well on platforms like LinkedIn, is harmful. Here’s my reasoning:
Projects need to adjust to whatever the environment around them is.
A developer needs to adjust to whatever is required by the project.
Unless you’re the person directly responsible for a project, or the manager on a project, just go with it. Enough with the negativity. You’re less likely to even be hired if you’re known to be rigid or against certain methods of management, so probably the last place you want to rant about them is LinkedIn.
You might find yourself working on an agile project, then moving on to a waterfall one. You might love a specific scrum tool, but your next project consists of developers who are already using a different one. If you have a mindset of “this method is backwards” or “other tools are better”, chances are you won’t be a very productive member of your team.
Be happy with the methods. Be happy with the tools. Be happy with the chosen frameworks – you’ll also be happier with your coworkers. Your output will be better and your managers will be happier with you, everybody wins.
Leave a Reply