BRS-001: The One Where All Projects Are Late
Surprisingly, Agile won't fix this problem, it may make it worse.
Welcome to the 1st Edition of Building Rome(s), a newsletter about managing technology programs.
This is an effort that comes from the heart and something I have been planning for quite sometime but only recently found the energy and courage to execute. It can be quite nerve wrecking to put your ideas and thoughts out there for scrutiny and judgement.
I will write about technology and leadership related topics that are near and dear to my heart or professional experience however, if you have ideas or subjects you would like me to share my thoughts, please reach out.
So, without further ado - here we go - Issue 001 of, hopefully, many more to come.
The promise of agile was faster, quality focused, iterative approach to software development. It was the answer to the molasses pace of waterfall. However, having lived through many incarnations of agile at Blackberry, Apple, Google, I strongly believe that agile has become the very disease it promised to cure an a very unexpected way. 😑
I joined Apple as an iOS Engineering Project Manager when iOS 6 was on “the path to WWDC”. I left Apple after shipping iOS 11. At end of each release, we modified our program management approach for the next iOS and macOS release. For each year I spent at Apple, we had a different program management process, staying true to the agile manifesto and honestly, staying true to the Apple way. Even in my interviews, everyone said it was never the same process. However, every year, every “path to WWDC” was paved with our ambitions meeting the cold hard truth of reality - not enough time to build all that we wanted. What inevitably followed was a series of Feature Reviews with Craig, Eddy, sometimes Jony, and other execs several weeks before WWDC to figure out how to revamp the deliverables so we still ship the amazing surprise & delight we set out to release to the dedicated members of the Apple Community of developers and users.
Now, the agile mindset or methodology is supposed to help reconcile ambition with reality. I feel it misses a very uniquely human underlying symptom which makes things worse. No matter what methodology we use to plan our projects, vast majority will be over promised, under delivered, inevitable over budget as we try our best to fix the original sin. This has stuck with me throughout my career and I never could pin down the why.
It wasn’t until a Freakonomic’s episode - Here’s Why All Your Projects Are Always Late — and What to Do About It (Ep. 323) - Freakonomics Freakonomics - finally answered the riddle for me. All projects, however well planned, suffer from “optimism bias”. 😐
It is in our nature to assume that we will always hit the happy path thus never plan nor do we evaluate our plans with an eye towards “what if everything goes to shit”. I am guilty of having commit this mistake. More often then not, I hear that “we need to do more agile”. Agile will not save you from this; it will make it worse. Our hope is that if we break things down small enough and fit them into smaller and smaller sprints, we will eventually ship it; we just need to throw more bodies at the problem to improve velocity, voila, problem solved. What inevitably happens is a series of negotiations on the product vision, a ballooning technical debt, and the constant need to ship newer and newer features while ignoring the mess we created last time - “we will get to it in the next sprint” said everyone, did none of us (mostly). 🤦🏽
Photo by Markus Spiske on Unsplash
My favorite research group, The Behavioural Insights Team, part of the UK Government, wrote a paper in August 2017 called “A review of optimism bias, planning fallacy, sunk cost bias and groupthink in project delivery and organisational decision making” in which they explain this very problem in much better terms than I can.
The concept of bounded rationality suggests that people use a simplified model of reality to make judgements.1 It postulates that in decision making, our rationality is not as perfect as described by the classical economic model of rational agents, but is limited by the information we have available to us, time constraints and finite cognitive capacity. Like any decision maker, government departments and project management teams do not have the time or resources to fully understand the complexities of project decisions, nor the ability to fully explore alternative options.2 As such, administrative behaviour consists of ‘satisficing’, choosing a course of action which is good enough and which allows progress.3
So, how do we fix this? 🤔
I have focused my learning to identify when the optimism bias kicks in. If you talk about the happy path then ask yourselves what if at this junction of the project, something goes wrong, what does that wrong look like and how can we fix or mitigate it. Maintain a list of all these risks and keep it handy.
This risk list tactic helped me immensely at Google, where as the Program Manager on Android Things Devices team, while I was building the software/hardware development program schedule for the Lenovo Smart Clock. That exercise made us take a pause and identify key issues with our critical path and deploy strategies to overcome them before they became showstoppers. Boy, one of the best schedules and plans I ever strategized. 😬
The skill to know when to shut down the optimistic bias, this very human attribute, will take time. It took me awhile as well. But, if you do not learn to recognize and suppress that optimistic part of your brain, you will always find yourself in that difficult position later in the project where you ask yourself “what do I need to cut to make my deadlines?” Because at the end of the day, we had a saying at Apple, “We never delay an iOS release; we must always ship in September.” 🙏🏾
That’s me at CES 2019 Lenovo Smart Clock Press Demo Booth in Las Vegas. One of the many memorable programs I have worked on. It is pretty nerve wrecking to do live demos with Press but I can add that to my skills set.
🧰 This Week’s Edition Of Solving Big F—king Problems
Anybody who is trying to solve a complex problem with scarce resources and race against the clock is a Project Manager. I love reading or listening to how people solve big problems with creative solutions.
In our inaugural edition, two of my favorite dynamic duo founders, Sidra Qasim and Waqas Ali, co-founders of Atom, talk about how they pivoted their business in a COVID world to solve a COVID problem.
I will let Sidra (co-founder Atoms) tell you the story in her own words. Enjoy their journey.
📕 What am I reading these days?
The Art and Science of Doing Engineering by Richard Hamming
🎧 What am I listening to these days?
Podcasts were my main jam during my commute. It was learning on the go but in the post-COVID world my commute now is literally 10 seconds. I haven’t had much time to focus on my podcasts. However, pre-COVID, Trump Inc by WNYC and ProPublica was on the top of my podcast library.
🤔 What am I thinking of these days?
Fintech is on my mind these days and how the neobank revolution never delivered on its promise to upend the banking establishment. If you are looking for a place to start on fintech, I suggest you immediately subscribe to Fintech Today by the amazing duo Ian Kar & Julie Verhage.
If you enjoyed reading this, please do share with your friends, family, colleagues, Linkedin peeps, twittersphere, or you know whatever/wherever you have.
Love it brother. Good insight 👍🏼
Great first issue! Building towards a deadline seems to be a common theme in pushing teams towards gets things done. For Apple, it's an annual cycle. David Sacks has a great framework for software companies for Cadence. It's a quarterly cycle where: you promise to ship something in month 2 of the quarter which helps sales which has to hit targets by month 3. He talks in more detail here: https://www.youtube.com/watch?v=G0sMviH3G24