Beyond Agile (4/52): Beware of the Absolutes
Agile, Waterfall, do you go all into one side or can you do both? Each camp has their extremes. How do you stay above the fray?
I had a fun conversation with an engineer colleague recently about how extremes exist on both sides of the spectrum of technical project management.
You have the die hard believers of agile who believe anything can be broken down into something that can be shipped in 2wks cycles and no need to plan everything upfront.
You have the ardent waterfall believers who cannot comprehend a world where engineering teams stumble from one sprint to another without a precise end to end plan. Ambiguity scares them.
As a TPM, Product Manager, or Engineering Lead, you will constantly be forced to adopt one position over the other, oft from leadership above you, often going whatever the recent buzz word is in the digital transformation arena.
“We are an AGILE company, not a waterfall methodology.”
“Are you even 2wk sprinting yo.”
“LONG LIVE AGILE. DOWN WITH WATERFALL.”
“What are we.. Boeing… we are an agile startup, please.”
One of the most common misconceptions of agile is that you do not need to do any planning upfront or be rigorous with your planning. This plays out with teams going from sprint by sprint, often 2wks, figuring things out as they build them.
Waterfall on the other hand places a lot of emphasis on upfront planning. The adherence to the plan can often be too rigid especially if the environment around them is changing; the refusal to shift direction is often detrimental. This is the way.
At Apple, I was fortunate enough to work with or learn from some of the smartest people in the business. One of those, Chris Espinosa, gave me the greatest advise I have ever received that fundamentally changed my entire approach to Technical Program Management.
“Never deal in absolutes.”
I pass this advise and wisdom on to you.
Beware of the Absolutes.
There is a time to be rigid; there is a time to be flexible. Being a successful TPM requires knowing what situation calls for what.
When you find yourself in this situation where you must decide on process or implementation of a new framework, here is how you can navigate these troubled waters:
Assess the current state of how your engineering teams work as standalone and cross-functionally.
Find the faults, the issues, the problems that hinder progress.
Develop a cross-functional solution with input from engineering and all parties.
See where you need to be rigid (waterfall) with the process.
See where you need to be flexible (agile) with the process.
Above all, always be looking for feedback from your engineering teams on how things can be continuously improved (people + process).
Never deal in absolutes.
This mindset will help you in every aspect on your career and journey: assess, identify, solution, feedback, repeat.
Until next time 👋!
-Aadil
Feedback On This Week’s Newsletter
