Every software development or technology firm boasts that it relies on a unique process and development methodology to create great software products and solutions for clients.
Calling out the methodology as a point of unique differentiation seems, well, pointless. Or is it?
Just like the end products or solutions themselves, a software firm’s approach to development may — at least from the outside looking in — appear pretty much the same (or similar) to everyone else’s when, in reality, it is not.
But, does this even matter? Well, if you consider the current digital transformation frenzy, which has created a pressing need for development speed, agility, and scale — then yes, it does.
Every organization has, to some degree, become a software company, and all are vying to quickly get to market with new digital products or services in order to meet growing demand, compete more effectively, and differentiate their offerings. In fact, as software eats the world, companies are not just having to become software producers; beyond that, they’re having to learn how to succeed at creating software that fuels their business growth.
For decades, companies and consultants have created new methodologies to help them manage ever-growing complexities in software development that cause less than 50 percent of software projects that run on Agile methodologies to be classified as successful.
Every single methodology comes with consultants who will tell you what you want to hear — things like, “twice the work in half the time.” But, none of these claims can be proved by anything more than anecdotal evidence.
So how do companies pick the right one? First, let’s run down a list of the common methodologies and paradigms that exist today:
Disclaimer: These are very brief summaries that leave out vast amounts of details. Whole books have been written that explain each one.
Scrum has been around for 30 years now and relies on time-boxed sprints to focus a team on small and achievable sets of work. It uses burn-down charts, planning meetings, a product backlog, and retrospectives to manage complexity and add order to the chaos.
Extreme Programming got its origins 17 years ago as Kent Beck explained and expanded upon his preferred software development best practices. XP uses a variety of techniques to eliminate rework and unused functionality by seeking to build the “simplest solution that can possibly work.”
Lean is based on the Toyota Production System, and it was first talked about 13 years ago with the publication of Lean Software Development. It emphasizes reducing the amount of unused functionality through waste minimization techniques.
DevOps came around eight years ago around the idea of having an “Agile infrastructure” that is seen as the intersection of development, quality assurance, and operations. This can really be seen as applying Agile principles and best practices to QA and operations to create integrated processes with development that enable the continuous delivery of software.
Kanban is only seven years old, and it is based on the Toyota Production System, as well. Its battle cry is reducing work in progress in order to focus not just on a small amount of features simultaneously, but also on only one task at a time. Each task must be fully completed before moving onto another.
All of these methodologies center around that idea that developing software is a complex series of tasks that needs formalized rules that bring order to the chaos. Each contains lists of best practices that create processes and introduce new organizational hierarchies to manage the complexity.
In the midst of all of this, the Agile Manifesto came along after several development experts tried to distill the varied landscape of software methodologies into a set of common ideas. Afterwards, "Agile" became a category that methodologies declared themselves to be a part of — though what they really meant was that they weren’t "doing things the old way” — something mostly referred to with derision as “Waterfall.”
Because companies want to be seen as decidedly not “doing things the old way”, they choose to become “Scrum Certified” or practice Kanban and start enforcing a list of rules that try to create order out of chaotic complexity. The problem is that this approach — featuring lists of rules and required techniques — doesn’t quite get companies to a 50 percent success rate.
This can’t possibly be the right solution.
Maybe the word “agile” is more important than the ideas in the manifesto. And maybe it doesn’t actually mean “not Waterfall.” Maybe "Agile" simply means being agile and choosing the right thing to do depending on a given context.
The lists of rules and required techniques shouldn’t be ignored; they should be seen as tools to use when the need arises. Andy Hunt, one of the authors of the Agile Manifesto, wrote in The Pragmatic Programmer, “Every day, work to refine the skills you have and to add new tools to your repertoire.”
Software development is a complicated field of knowledge work, meaning everyone in the software development field — software engineers, product managers, UI designers, and quality assurance specialists alike — is paid first and foremost to think.
Blindly following a set of practices isn’t thinking, it is buying a commodity that does not give you any competitive advantage or worse, possibly creates disadvantages by focusing a team on the wrong part of the problem to solve. The software methodology that works the best is one that is centralized around the idea of continuous improvement. Software is similar to a plant (the gardening kind), in that each specific plant in a specific location is different. By taking a one size fits all approach of fertilizing a varied garden, you’ll harm many of the plants (1). And likewise, some plants will die from too much of a good thing, such as succulents and water (2). The best way to ensure healthy growth of a plant is to inspect the environment that it will be planted in and amend that environment. Similarly with software projects, we should first inspect the context of a project (scope, timeline, budget, ability to maintain post launch, the market, competition, etc) and then use the correct tools to boost the chances for success.
Gardenia from my yard.
That’s why at Skookum we frequently pair program, we use continuous integration and we hold standups, but not always daily because some projects don’t need them every day.
We read books about development best practices as a team and discuss them over lunch, and we’re becoming more empirical in our processes by collecting more metadata on ourselves and our projects to help ensure we’re creating the best environment for our projects to succeed. We seek out new tools such as those in the GROWS Method to help us continue to expand our set of tools that we can use for our clients. But in all of this, we spend time thinking. We talk to our clients, and we look at the project in front of us and we consider what are the right tools for this project and we choose them, whatever methodology they may be from. This keeps us focused on what matters: client success and measurable results.
(1) As someone with the last name Flowers that has burned the same patch of grass with fertilizer multiple time, this is in fact possible.
(2) I’ve lost count of the number of succulents I’ve over watered. They need somewhere between no water and barely any water.