Adaptation - the survival of delivery
Something I recently discovered was that the phrase;
Was coined by Herbert Spencer, when drawing parallels between his own economic theories and those of Darwin's. It was actually someone else (not Herbert) who recommended to Darwin that he uses that phrase instead of "natural selection".
There are several interesting points there;
I always thought that was Darwin's phrase, solid reminder to continually sanity check oneself. Oops.
Collaboration and embracing feedback is key.
Adaptation theory seems to apply to almost anything, not just biology.
So what's all that got to do with delivery? Well, everything really.
In the technology world, there are too many statements banded around about one methodology being better than another, the classic dichotomy being agile versus waterfall. There are also too many people who draw lines in the sand and point fingers at opposing methodologies and their practitioners, depicting them as either "too rigid" or "immature" in their respective approaches.
This doesn't just apply to delivery, technologists are also notoriously bad at agreeing on all sorts of things, another example being micro-service versus monolith application architectures, is devOps a role or a mindset, do we need QAs if the Engineers test stuff?
The good news is, they're all absolutely correct. Er, what?
I've had the "pleasure" of working within a miasma of methodologies over the past 25 years, one approach IMHO that has survived the test of time is Adaptive Software Development by Jim Highsmith III. Interesting read involving mountain climbing expeditions, the key message being;
speculate, collaborate, learn
Adaptation of methodologies isn't new in the delivery space (scrum-ban, PINO), but I fear that too much emphasis is placed on the success of one approach over another. We do, after all, have the option of mixing techniques from both waterfall (WTF-all) and agile (FR-agile) respectively. Lack of trust in either of these leads to the emergence of something new to bridge the gap, hello SAFe.
Each methodology introduces some great tools and processes that you can benefit from in the right circumstances. There is no one better way than the other, but IMO there is one common denominator that dramatically increases your odds - adaptability.
If you have the right safety net (data), and the right mindset, you can chop and change anything to reach your goal. Even if that goal is to close the project down, fast. If you're hoping that following the rules governing a particular methodology to the letter will prevent you from going belly up, you've probably already failed.
For this reason, despite the fact that Jim's book was published a year before the Agile Manifesto was chiseled in stone (he was one of the founding fathers, so to speak), I still think the 3 principles he outlined will help you navigate successfully through any project, and are still very relevant today. As I mentioned earlier, adaptation seems to be required in order for anything to survive and thrive.
Don't be afraid to cross the streams, live on the edge a little. Break the mould of slavishly doing one thing over another because that's the belief system you've subscribed to. Embrace the power of gantt charts whilst smashing through small development iterations, who cares? Use the right tools for the job, irrespective of what the rule book or the departmental dictators of the month are telling you.
Adapt to survive, adapt to succeed. Rebel for fun.