Our ways of developing software are still broken. Methodologies are outdated and not well fitted for the products we want to build. Management must adhere to new ways of working to solve this problem.
We want to build software in a more efficient way. We want to stop wasting time and resources with bad ways of working. People are doing their best, it is the system we force them to fit into which is flawed. We want to fix this. We want to stop economic waste by enabling individuals making the most of their time. People deserve being motivated, passionate, driven, autonomous, and happy at work.
Old ways of developing products were fine for systems and components with predictable behavior. But when we develop software, we don’t know from the beginning what path we will take, and where it will lead us to. So, we must stay nimble; we don’t want long committed plans. We want a strict vision and a loose roadmap. We want commitment only for the near future.
“We want a strict vision and a loose roadmap
Contracts are designed to force contractors to align and commit to rigid rules. They are ways of making ourselves disciplined enough to adhere in the future to our present choices and decisions. With contracts, we want the future reality to conform to the rules we edict now.
At the opposite, with software development, we don’t want to limit ourselves to things we’ve taken for granted too soon. We know chances we are wrong are high, so we want to free ourselves from preconceived thoughts or judgments. We want to quickly adapt to reality all along the product development journey. We want reality always guides both our choices and decisions. Instead of contracts, we want a commitment to reality.
With software development, only time, experimentation and failed attempts, inform us about what is the right product to build. We want to make assumptions that we are eager to revise whenever it is necessary. The reality always remains our only master. Budgets are Lean-Agile, dynamic, revisable, and adaptable. Plans are not committed for months, and we frequently adjust them to reality.
“we want a commitment to reality… the reality always remains our only master
With SAFe, for instance, budgets are guided through guardrails, but that’s not contracts, that’s policies. They guide us through the adversity of the continuously moving conditions and changing circumstances of a complex environment. On the contrary, contracts are not designed to respond to change; they are only updated by exception. Contracts are not agile, they are fixed, static objects.
“Contracts are not agile, they are fixed, static objects
So why so many software development practitioners continue to use contracts? Because contracts have a reassuring effect. They procure a feeling of security. People sign contracts for everything: insurance contract for a smartphone, life insurance, a sports subscription, etc. Securing us with a contract has become a habit that we bring to the workplace. But, for developing good software, the workplace must look like a place of innovation and creativity rather than like a notarial office.
“for developing good software, the workplace must look like a place of innovation and creativity rather than like a notarial office
Even when the contract clearly goes against the interest of the product, our modern instinct pushes us to sign one (signed-off detailed specifications document) in order to alleviate the anguish created by the absence of a formal commitment (as says the neurologist Jonah Lehrer: “If a major brain function is to maintain mental homeostasis, it is understandable how stances of certainty can counteract anxiety and apprehension.”). We still cling to this feeling of certainty when we should be braver by accepting our ignorance, submitting to empirical testing what we took for granted, validating or not our hypothesis, and progressing towards a perfect understanding of the solution. As Jonah Lehrer says: “Only in the absence of certainty can we have open-mindedness, mental flexibility and willingness to contemplate alternative ideas.”
Being wrong is an indicator that we are trying hard enough to be right. When we pretend to be 100 percent right from the beginning by signing detailed specifications, it’s a sign we refuse the idea of being wrong. But if we’re never wrong, we never learn anything we didn’t already know.
“if we’re never wrong, we never learn anything we didn’t already know
The agile mindset promotes trust in place of contracts as a way to build confidence between individuals. Trust establishes confidence, transparency, and respect without the drawbacks of a contract; it permits continuous adaptation and response to change, what contracts absolutely hinder with their prescriptive nature.
Trust and contract are two words that don’t marry very well together. A contract is needed only when trust is not total. But we want the full trust to develop the best software.
The subtle art of modern management is to embrace both trust and uncertainty. In presence of chaotic and uncertain events, trust is more than ever needed. And in the modern software development world, contracts are not welcomed because they are vowed to misguide us.
“The subtle art of modern management is to embrace both trust and uncertainty
What about your way of developing software? Do you still use long, detailed, fixed, committed and signed-off requirements documents that don’t let any space for change and adaptation? Or do you prefer an empirical and agile approach, submitting your beliefs and hypothesis to testing, taking advantage of uncertainty and of the alternatives that it keeps alive, letting contracts aside in favor of delivering the right software through trials, errors and subsequent learning?