«So how do you ever tell your customers how much something costs?»
My cousin asked me that question as I tried to explain to him what we do at AgilityFeat. My cousin is the CFO of a major division of a large multinational European company. He knows numbers really well, so it was no surprise that he asked that question. Although he’s very smart, he doesn’t know technology or software development, and so he was a bit baffled when I explained we don’t do fixed price contracts.
«I understand the idea of working in small chunks, what do you call them – sprints? That makes sense to me. But how do they know what it will cost?»
At AgilityFeat, we build custom web applications and mobile software for our clients. We pride ourselves on working with interesting clients that need pretty innovative work done. The innovation may be in technology («we need cutting edge real time software»), in design («upgrade our legacy app to something beautiful and usable»), or in business models («we’re a startup and still exploring what our customers want»).
Every project we do requires innovative and creative work along any of those axes. That makes it very hard to quantify the costs and effort necessary at the beginning of the contracting process. How long will it take to implement that new technology? How long will it take to refresh a legacy site design and all its associated workflows and user interfaces? Will we discover what your customers will pay for with the first sprint of work, or is it going to take a few iterations to get them to open their wallets?
«Software development is like art.»
Software development is often lumped in with engineering professions, and as a former electrical engineer myself, I understand why. There is a bit of hard science to it, and at the low level there are repeatable patterns for how to write code. For that reason, people assume sometimes that we should be able to give hard estimates and hit them reliably.
The art though is how to combine those low level coding patterns into a tight, usable, beautiful piece of software that delights your users. If the project also involves new technologies of coding frameworks (and most do), then there is also art and finesse going on at the lower levels of coding.
«How do you estimate art?»
I gave my cousin an example that I learned from agile consulting and training company Lithespeed. I have taught agile courses with Lithespeed before, and they have a graphic in one of their introductory slides that I really like.
It shows how the painting of the Mona Lisa might have been painted. On the left hand side is a pencil sketch – think of that as a wireframe of a product concept. You can see the rough outline of the woman, and you can get a sense of the vision that the artist has. But unless you already know the artist’s reputation, you’re probably not going to pay much for that pencil sketch by itself.
In each frame of the graphic, from left to right, you see the artist filling in details. More detail is added to the pencil sketch. Things are erased and lines change. That fascinating smile of the Mona Lisa takes shape. Color is added in layers, and eventually the final product takes form.
We only know the Mona Lisa as that final product and masterpiece. But it actually could have been «deployed» to users at earlier stages, and much art is. That might occasionally deny the world a masterpiece, but we should also forget that many artists die broke, and that is not our goal as entrepreneurs.
If you were the patron funder of a painting, you could in theory stop the funding at any point and say «that’s enough, I love it (enough), and I will hang it on my wall as-is.»
The same is true with innovative and creative software development. We all want to turn it into an absolute masterpiece, but if we keep working in small increments and we make sure to deliver more value (and not more new bugs) at the end of each sprint, then we can choose to end the project at any point and still have something valuable.
I already admitted I’m trained as an engineer, not an artist, so a real artist might critique the comparison I’m drawing. But essentially this is how art is created:
Customer: «I want a sculpture, of me. On a horse.»
Artist: «Yes, that will be great – you would look very impressive on a large bronze horse! This is going to be beautiful!»
Customer: «But I need it in time for a party next month that I’m throwing for myself.»
Artist: «Oh, only a month? Hmmm….»
Customer: «Yes, that’s right. And here’s my budget … don’t spend it all at once.»
Artist: «How do you feel about mini soap sculptures?»
While the constraints of a budget and timeline may drastically change the vision that we can implement, the fact is that an artist can still get you something. It may not be the life size bronze sculpture you dreamed of, but even a smaller prototype will let you test the concept with your friends and see if you do actually look good on that horse.
«We can work within budgets, as long as you can work with us on features»
And that was the point where my comparison made sense to my CFO cousin. It’s not that software development is a black hole that you just keep throwing money into, with no idea if you’ll ever get a return on your investment. That’s what sailors call a «boat.»
We understand that customers have budgets and timelines they must live within, and we can give rough estimates if what you want can be built within that budget. We can promise not to exceed that budget, but only if you can promise to work with us on the features as we go. It requires a bit of trust, a lot of communication, a flexible contract model, and constant re-prioritization of what’s important based on technical and customer learnings.
The artist who signs fixed scope and fixed price contracts for sculptures is the artist who dies penniless. That’s not good for art, or software development, or your innovative product idea.
Comentarios recientes