There are those who think that the Agile Manifesto and all the agile development methodologies brought to the world a better and more effective way for developers to work. After all, it was conceived by developers who struggled with the many problems related to closed scope. However, this is not all there is to the matter. What it primarily brought was total control over quality, deadlines and cost for customers, in terms of what they were contracting and receiving. And this is something that many people have still not realized, especially customers.
In addition to immense control over projects, customers are also given an extremely interactive and productive process, which further maximizes every penny spent, with much more complete, precise and valuable deliveries, since agile practices in a development company speed up deliveries and, at the same time, these deliveries are much more relevant, not only accelerating what is delivered, but also delivering that which really counts – results: profit for the customer is virtually exponential.
However, there is a large measure of healthy uncertainty in this relationship involving Customers and Agile Development, with Development versus Time being the most complicated one for customers to understand. Many find it hard to comprehend that not being able to give a clear deadline for developing software using agile methodologies does not mean that developers can take as long as they want, but rather that it will only take as long as absolutely necessary. Unfortunately, it is impossible to accurately establish beforehand what this necessary time is, since besides being sufficiently complicated to foresee every relevant detail in a project before starting, it is even more difficult to anticipate what will be discovered during the development process itself. This being the case, having the freedom to study every possibility is the ideal.
For 15 years of my life I sold web development using Closed Scope – customized e-commerce platforms that dealt with scores of complexities involving integrations, markets, managers and the needs of each customer. Large, costly platforms, and I can attest to the fact that of the hundreds of proposals and negotiations, there was not one, I repeat: NOT ONE proposal I made which did not contain a measure of uncertainty as to how long it might take, directly affecting how much it might cost the customer.
Having to guess at deadlines for developments did not mean I was a poor businessman. To the contrary, everyone does this when they work on customized projects with a closed scope. Logically, with time and experience the accuracy of this guesswork improves and, after costly trials and errors, I fine-tuned my conjectures as to how long it would take our developers, combined with how long it would take for customers to answer, provide information, prepare, approve, etc... Nevertheless, despite this progress everyone remained hostage to my conjectures, especially me.
Around four months ago, when I started working for HE:labs, I was struck by the fact that I no longer needed to give my customers a DEADLINE for a development... Hold on?! No longer need to? This had never been possible before. I used to give a possible time frame that each type of project would likely require, but I must confess that I was never able to achieve 100% accuracy as far as deadlines, which always bothered me a lot.
At HE:labs, I suddenly found myself freed from this deadline curse, this having to come up with deadlines in order to sell software. The initial sensation of no longer having this negotiation tool in my arsenal was quickly replaced by a much more truthful discussion tied to the reality I had always lived and experienced, a much more amicable and coherent discourse where saying to the customer "Let's discover together?" started making much more sense and has turned every customer into a genuine partner.
This new negotiating approach represents a complete change in business dynamics, where in principle we stop putting ourselves in the position of trying to meet the customer's objectives and instead, start working alongside their objectives, moving forward and discovering together with the customer. With this approach, the numbers in the equation are no longer the determining factor, and trust-based, competent analyses in relation to the work required and the future of the company take on greater importance. The question that should be uppermost in the customer's mind when negotiating is: "Is this the company I want to work with to jointly develop and discover the best solutions for my business?"
This change of mentality is striking for those who have been many years in the market without using agile methodologies, and if it’s striking for those who come from this market and are able to understand the advantages of this philosophy which embodies uncertainty as an integral part of a negotiation, then it must be even more so for those on the other side of the table and should be handled very carefully, since the discussion could easily appear to be based on insecurities, when in fact it is merely a healthy uncertainty which agile methodologies are prepared to deal with.
What's certain is that there is a cost in this entire process in order to generate a specific value where every party comes out winning, i.e., the development will be recompensed financially and the customer will receive an excellent software development. However, this excellent development and recompense for developers must be very well aligned, and it is at this juncture that our cost equation comes into play.
Not long ago it was easy for you to calculate. You’d say to the market:
After a few weeks sitting down with some traditional companies that use closed scope and studying each one of their proposals, the math was simple to analyze when it involved the cheapest and fastest solution. One of the results of all this was precisely the famous Programmer Man Hour discovery, often presented in proposals, always based on the formula: W = Y/X .
But now I'd like to introduce a new equation where:
This newly formed equation contains two unknowns for all the participants in the project. However, there are no longer any victims subject to any suppositions.
As final result, who will be in the control of this new equation is the customer who will grant the development of the software(W) as much as they want, for the time(X) they want, just limited and according to how much budget they want to spend over the cost (Y) for each sprint.
Customers, isn't all this control over your project what you've always wanted?
Welcome to the new market equation.