The author here, thank you for checking this link, looking forward to your thoughts in the comments! Summary below.
---------
Today Agile is the default choice for the software development life cycle (SDLC); every conference, book, or blog post is telling us we are doomed to fail if we don’t follow this established convention. But isn’t it surprising to think that we should use Agile for every possible company doing software out there? Are we going to organize software development exactly the same way if we work for a startup, NASA, or FedEx? It seems hard to believe.
If you are already screaming this is heresy! …please bear with me; I am not trying to send us back to the dark ages of Waterfall. At the same time, no project or company is the same and we should keep thinking about Why we do what we do. Choosing the appropriate SDLC requires a deep understanding of the dynamics of your environment.
In this blog post, I will use the lenses of risk management to help you pick what SDLC is right for you. We will first look at how to put your software development lifecycle into context by interpreting it as a risk map. We will then look briefly at the history of Agile and Waterfall and why these risk maps make sense in their own context. Finally, we are going to learn how to use Cynefin and Wardley maps as tools to better understand the uniqueness of your risk territory, so you can pick the software lifecycle that better suits your team or company profile.
I hope you enjoy the journey and looking forward to your thoughts in the comments.
Why is the topic almost always dichotomized into "waterfall" and "agile"?
Does "agile" these days simply mean "not pure waterfall"? If not, what are other life cycles?
I often bring this up because my introduction to the topic was in the 1990s through Steve McConnell's 1996 book "Rapid Development: Taming Wild Software Schedules". It lists a number of software development life cycles in chapter 7, "Lifecycle Planning". From the ToC these are:
3 comments
[ 4.8 ms ] story [ 20.6 ms ] thread---------
Today Agile is the default choice for the software development life cycle (SDLC); every conference, book, or blog post is telling us we are doomed to fail if we don’t follow this established convention. But isn’t it surprising to think that we should use Agile for every possible company doing software out there? Are we going to organize software development exactly the same way if we work for a startup, NASA, or FedEx? It seems hard to believe.
If you are already screaming this is heresy! …please bear with me; I am not trying to send us back to the dark ages of Waterfall. At the same time, no project or company is the same and we should keep thinking about Why we do what we do. Choosing the appropriate SDLC requires a deep understanding of the dynamics of your environment.
In this blog post, I will use the lenses of risk management to help you pick what SDLC is right for you. We will first look at how to put your software development lifecycle into context by interpreting it as a risk map. We will then look briefly at the history of Agile and Waterfall and why these risk maps make sense in their own context. Finally, we are going to learn how to use Cynefin and Wardley maps as tools to better understand the uniqueness of your risk territory, so you can pick the software lifecycle that better suits your team or company profile.
I hope you enjoy the journey and looking forward to your thoughts in the comments.
Does "agile" these days simply mean "not pure waterfall"? If not, what are other life cycles?
I often bring this up because my introduction to the topic was in the 1990s through Steve McConnell's 1996 book "Rapid Development: Taming Wild Software Schedules". It lists a number of software development life cycles in chapter 7, "Lifecycle Planning". From the ToC these are:
Pure Waterfall • Code-and-Fix • Spiral • Modified Waterfalls • Evolutionary Prototyping • Staged Delivery • Design-to-Schedule • Evolutionary Delivery • Design-to-Tools • Commercial Off-the-Shelf Software
Yet those different approaches, and their respective advantages and disadvantages, are rarely mentioned.