Agile Software Development is a Horse
As part of the struggle of being the founding partner of a new company in the 2020s, there is the everpresent looming question of how to market yourself. This is true both of yourself as an individual - as an executive you should embody and represent at least some slice of the value of my company’s meta on LinkedIn and the whole shebang; and you need to know how to position your company in order to attract new clients and feed yourself reliably over the long term. The sales must flow.
We have a special marketing problem at Opreto that we share with any agile software development agency trying to work in the agile way: the customer’s expectations for what they are purchasing are rarely aligned with the way we work, and we often need to communicate a paradigm change before our value becomes truly apparent. In order for us to be ultimately salable, we must bring them somehow completely onside before working together, changing hearts and minds as part of a larger sales process. In order for the project to be ultimately successful, we must gently disabuse them of the concept that traditional software delivery holds meaningful value, and rehabilitate their expectations at the same time as also discussing our particular merits.
One of the most critical aspects to how we work is that we build teams, and we drive them in a certain way and at a certain speed. This is designed, and adjusted over time, to balance key considerations such as budget and the rate at which new software features are delivered, in a responsive feedback loop. We build teams that can speed up and slow down without sacrificing quality control. We build teams that can endlessly and seamlessly match the rate of development required by the client.
One of the major downfalls of traditional software development are the timeline and cost overruns that they reliably incur; software development is notoriously overbudget and late. Agile software development methodology was meant to cure that, and it does so thoroughly.
Yet in the real world, the first questions most purchasing agents have, when they are shopping around for software solutions and encounter us, are: How much do you charge? Do I have the budget for it? How do I compare your software development crew with another, and make a decision on which vendor to start our relationship with? How do I gauge what my total eventual effort and cost will be?
This means we often get asked about our rates. When we give them, they come in the form of the hourly rate for the various team members we assemble. There is a problem with that, in that it is an obfuscating misfire, only partially relevant to the way the project gets developed or what its costs might end up being. We know that it has these limitations, but we have not had an alternative idiom with which to convey it more clearly.
The issue with asking for individual rates is that we deploy teams (not individuals), and that the size and composition of the team can and should change during various phases of the project. Software architects get a higher hourly rate, but comprise a lower percentage of the team’s weekly delivered hours, especially as time goes on and the architecture has been solidified. Developers and data engineers have the most hours, as they participate throughout the lifetime of the project, but are billed at a lower rate than an architect. QA is often bottlenecked by developer output, and represents a different cadence entirely, whereas a UX designer may only be needed at the start of a project and then never (or infrequently) again.
Traditional software development methodology is usually too inefficient and slow. But its also true that a team (internal or external) too juiced up with developer hours can be too fast and burn through cash needlessly and then slam up against a wall. A truly agile team can accelerate and decelerate as is most appropriate to the goals for the business they’re partnered to, whatever the frontline business actually is. This is a key fact that gets lost in a traditional rate card.
So, how do we communicate the flexibility of agile software development, and the impact that has on how the project is built? What does a rate card for our kind of business actually look like? How, more generally, should the agile methodology paradigms be represented in order to make them intuitively understood?
We need a metaphor. One that is organic, and natural for the human mind. One that resonates on the human scale and says everything it needs to say to communicate how an agile software methodology works.
After some serious thought, I think I’ve come up with an answer: the horse. And more specifically, the tiers of gait which are available to them: from a walk, to a trot, to a canter, to a gallop, the horse can pace itself according to need. In this way they are exactly like an agile software development team, which can vary its speed to serve the needs of the project. The working relationship between humans and horses are one of the most ancient we have, dating back thousands of years, and humans intuitively understand it. The bond between horse and rider is a special one of augmentation for the rider. The regalia of horses - the saddle, bridle, stirrups and reins - are the highly evolved way in which we communicate velocity requirements to them. The well trained horse responds instantly and flexibly, with great strength, in answering the directions of its human rider. Horse and rider are attuned, with the horse bringing strength and momentum for the pair.
Let us explore the metaphor a bit more, and see how it fares when applied to an agile software development project:
When we begin a project, we wish to walk slowly and with care. We are watching our footing, and a software architect, and perhaps a user experience designer, are creating a framework upon which the rest of the project will be built. It is too early at this point to have software developers on the team, as they would have no direction yet. The horse is at a walk.
When we have a good sense of the final architecture, we add some developers to the team to begin the construction of the software, to build out its skeleton and the features required to achieve a Minimum Viable Product, the base from which to build everything else. The horse begins to trot. Our development methodology with its daily agile processes and the various workflow-alignment ceremonies allows for optimal efficiency for feature completion rates, and this is an efficient (if not yet rapid) gait. The team is focusing on building the MVP, and they are studying and building out the architecture and UX design created previously.
When the project’s framing has been hung, and the features the software needs to prove its utility are established, we add some QA to speed up the process and some project management to streamline work further and clear obstacles. The horse has sped up to a canter, moving at higher speed but not yet at peak development velocity. We are focusing on reinforcing development pipelines and allowing for more rapidly building out new features.
Finally, if we now wish to push to a gallop we can add more developers to increase the deployment of new features, or increase the velocity of development for more complex features. We may also add additional QA or project management resources if the project or teams require it. The horse is now at a gallop, running at ground-eating speed, having aligned the project and refined development processes while we were in the phases of acceleration.
We can, of course, also slow down our speed. This might be done for budgetary reasons, or to allow for a shift in priorities or direction for the project going forward. It will also slow down if there are no more features that need to be added to the software. The team slows to canter as the end of the track becomes visible, then back to a trot as it approaches the finale. Finally, it is walking again, performing maintenance activities, and once again placing each foot with deliberate care as more and more edge cases and minor quibbles get handled or constructively eliminated.
It could, of course, begin to trot and gallop again when and if needed.
For 6000 years, horses have occupied a special place to our species. In agriculture, they revolutionized plowing and transportation, contributing to increased food production and exchange. They found uses in war and mining, logging and trade. Today, while their practical roles have diminished due to modern machinery, horses continue to be valued for recreational riding, sports, and therapy, maintaining a connection that has evolved over millennia. As a result, all humans have an intuitive understanding of horses and the partnership between our two species, and the velocity and requirements that their various gaits reflect.
Our rate card (when requested and given) has, up until now, not been communicating a clear picture of what a client should expect in terms of cost, or about what a deliverable even looks like in an agile software development project. Unidimensional individual rates simply cannot give an accurate representation of the actual cost or the shape development takes. Opreto tends to deploy several common tiers of team composition, but even those may not (and usually should not) remain the same throughout the lifetime of a software development project.
In agile software development, when we wish to speak to clients about cost and timelines in an accurate idiom we should speak about the destination we are traveling towards and the velocity of the project (which derives from the overall team composition), reined in or spurred on as needed by a rider.
So we must speak of our agile software development company as though we are a horse, and communicate it to clients in that way. Then they may intuit the value of our approach and leap, leaving us to the simpler problem of what exactly makes us the best at what we do.
All agile software development companies are horses. But Opreto is a goshdarned thoroughbred derby-crusher.
Comments