BA (19/52): Systems, Truths, Shipping Software
All systems operate on fundamental truths.
These truths are the constraints which govern what a system can do, cannot do, or can be made to do.
At its core, a system takes inputs, processes it, to generate an output.
Smaller systems can combine operations through a series of interconnected dependencies to create larger, more complex system.
Regardless of scale, all systems operate on fundamental truths.
A software organization is a large complex system (product, service, platform etc) composed of many smaller systems (teams).
Its primary operation is software development.
Input = requirements
Processing = turn requirements to functioning code
Output = finished product or service (either an app, SaaS, something new and brilliant)
The fundamental truth of this system - the triple constraint1 .
The quality of work is constrained by the project's budget, deadlines and scope (features).
The project manager can trade between constraints.
Changes in one constraint necessitate changes in others to compensate or quality will suffer.
As TPMs, our goal is to help software organizations ship high quality product or service. This means that we are constantly managing these 3 control knobs to achieve the highest quality output possible.
At a quick glance, it seems easy enough - keep everything balanced. Alas, nothing is ever easy in building hard things.
Here are some supporting truths to the above fundamental truth that only experience teaches you:
You cannot create more time, it is always borrowed from the future.
Scope is never increased or decreased, it is traded.
Costs come in many forms yet we insist on only talking dollar figures.
So - how do we as TPMs turn these 3 knobs to achieve something spectacular? My recommendation - do what we did at Apple - FREEZE TIME.
Every iOS release had a fixed schedule.
All feature development adhered to that schedule. This was non-negotiable. Come September (or somewhere there), that release is going through the door with or without your feature.
When you fix time, that is one less element you need to factor into your equation. Cost is often not an issue in Big tech unless you are building something that needs more Cloud or Infrastructure support thus servers to buy or more cloud computing power, for example. Now, cross-functional teams can focus on what really matters - scope.
This kind of approach isn’t unique to Apple. Basecamp’s Shape Up framework is also about freezing time with their 6wk development windows. Scrum and the intent of the sprints, depending on your choice of 2wks, 4wks, etc, is about freezing time.
Now, full disclosure, not every organization can afford to fix time, granted.
This requires discipline and maturity around being honest about scope changes, hit to the bottom line, delays that cause morale issues (remember: cost is often more than just dollar values), and ruthless pragmatism.
If you are young software organization working towards maturity, strive for this mode of operation - freeze time. There is always another train to get on to. Always be shipping.
Until next time 👋.
-Aadil
What did you think about this week’s newsletter?
🤯 Amazing
😁 Good
😊 Okay
Source: https://en.wikipedia.org/wiki/Project_management_triangle