When building software today it’s hard to know whom to believe or where to start. You have a vision for the product you want to see, but how do you get there and how much does it cost?
There’s a lot of noise too: Do you “build” or “buy?” What stack will you use? Will your developers work to build object-oriented code or functional code? What libraries and tools will be used? Who is watching the backend if something goes down?
In 2001, a group of experienced engineers who were tired of the management-heavy approaches of software that was common in the early days declared in the “Agile Manifesto” a set of practices and beliefs that were the best way to build software.
It’s complicated to explain to non-coders why this shift in thinking was so important to the industry, why it continues to be talked about and debated, and why people say “agile is dead” and “TDD is dead” and what that really means.
To read the Agile Manifesto today, especially the page of actual practices seems almost trite and simplistic: “Build projects around motivated individuals.
Give them the environment and support they need,
and trust them to get the job done.” Today, this kind of language is commonplace in corporate America and startup land alike. Nonetheless, its resonance is felt deeply throughout the industry.
In 2004, an influential book called “Extreme Programming Explained” took many of these best practices further. It advocated for things like pair programming (two programmers, one computer), stories, continuous integration, and test-first development. It also espoused a lot of touchy-feely things like courage, respect, and mutual benefit. Then it advocated for sets of things that seem pretty obvious to most engineers today: flow, redundancy, failure, quality, accepting responsibility. Albeit, when the manifesto was released in 2001, these things weren’t always commonly practiced.
“Agile” and “scrum” dominated the conversation about software development for more than a decade. (The term “XP,” or extreme programming, caught on less-so.)
In 2011, an influential book titled The Lean Startup was published. (Ries, Eric, Crown Publishing Group.) This book modernized the term “minimum viable product” (or “MVP”) which touts the idea that the most important thing is to build a minimum amount of useful working software before moving on to the next step. Lean Startup was widely heralded as one of the most quintessential pieces of thought on the relationship between business and software. Although its focus is different, the idea of focusing on waste reduction is consistent with the core principles of the Agile Manifesto.
Finally, waste reduction is also highly relevant to software engineers who follow a lean process, as influenced by the Sigma6 process developed in the 1980s by Toyota, which essentially prioritized all effort around reducing the three wastes: 1) the waste of underutilization, 2) waste of unevenness and 3) waste of overburden.
We will explore these concepts in future blog posts, but today, we will take on the first thee concepts of the Core Principles of the manifesto:
1) “We want to “satisfy the customer” through “early and continuous delivery.” This core value is essential for laypeople to understand: Too much up-front planning is often the project’s failure.
We’ve seen it all too often: a founder’s vision for the ‘big picture’ leads to a kind of incessant and obsessive compulsion to continually talk about the future. Sadly we feel this is often a red flag for the kind of people who won’t be successful at good software. It isn’t about not talking or thinking about the future, it’s about thinking about it only just enough. Any additional thinking about it will actually be detrimental to the development process today.
But how much forward-thinking is the right amount? That’s where Dual-Track Scrum(™) aids us in thinking both forward and also about the now.
2) “Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.”
Here we think the manifesto has a core principle that is valuable but its language is unfortunate: We don’t actually welcome changing requirements mid-flight, that’s nonsense, but we do know deeply that what we are saying here is that in life change is the only constant. In business, we must fly like the hummingbird and sting like the bee: Opportunity is here today and gone tomorrow and what you built last month might not actually be relevant.
So requirements do change, and we do have a process to deal with it.
3) “Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.”
This is perhaps the most important part of the manifesto that is frequently overlooked. In short, this means estimating a 2-3 week timeframe rather than estimating a 10-12 week timeframe. One might wonder if an estimate can be made for a 2-3 week project of size “x” why can’t a 12-week project be estimated for a project of size “4x”
The answer lies in three fallacies about software that are significant enough to pause on:
The fallacy of knowables.
A house that you might hire an architect to build will have a foundation, a basement, sides, and a roof. It might have an entranceway or a back porch. All of these things are probably knowable, but as most people who build or renovate property will tell you a contractor you hire more often than not will go over budget.
In software, there are even fewer knowables.
The fallacy of uniqness.
Most people who build software think they’ve come up with the most brilliant idea that nobody ever thought of before. Maybe they have and maybe they haven’t. Where most businesses think their problem is unique, in fact, if the marketplace will support the venture it will be repeatability, or the common-denominator, that will succeed. This is of course balanced with your stomach for risk– those who take greater risk will have the strongest case for why the solution should be unique.
Most apps and websites aren’t unique, and for this reason, the platform has an advantage over custom software. The rise of DIY platforms for all kinds of things from T-shirt printing to booking and scheduling services to telephony demonstrates that most businesses’ problems aren’t actually that unique at all.
The fallacy of linear investment.
Let’s say you are a brand marketer. Or a small business trying to market to your channel. Do you pay an excellent writer by the word? In fact, you don’t. You pay them to find the right words, often
In the next post, we’ll explore more of the manifesto and the various ideologies that have come to define software development in the modern age.
To keep updated, be sure to follow MOMEAS on Twitter, Facebook or LinkedIn (see above).