Over the last 10 years or so, the software development world has taken a strong inclination toward agile methodologies. And rightly so, as there are many advantages to running a software project in an agile mode, including:
As software teams increasingly adopt agile methodologies, the strong agilists tend to favor a “no estimate” paradigm. The argument is that when “we know things are going to change, any forced estimate provided will be wrong.”
Many have heard of the #noestimate movement. It saves valuable time spent on estimation, allows teams to work on a reliable long term solution, and thrives on the creativity of the team members. Unfortunately, it doesn’t work for 90 percent of clients.
When a new prospect comes in, they fall into one or more of the following categories:
During the first few meetings with your team, the new prospect wants to get to a point where an estimate can be provided. This would provide the guarantees on budget, date and scope they want, to either sell the project internally to their own management, which demands similar guarantees, or to satisfy the number they had in mind.
While many agilists disapprove of providing estimates, there are many technology stalwarts that are for it — even working in an agile mode. According to Martin Fowler, “an estimate is valuable when it helps you make a significant decision.” For example:
A prospect once commented that if we are not able to provide him with an estimate, we may not be good at our jobs. Harsh and incorrect as that may be, it provides a keen view into the world of stakeholders. “How can I buy something from you if you do not tell me what it would cost?” The simple answer is: we cannot provide you a cost for something that will change.
But trust has to be earned.
Over the years, we have formulated a process:
As the project progresses, the team works in an agile mode, with a pre-prioritized backlog and a duration estimate. The engagement manager works with the client, regularly showing them progress, and has any tough scope discussions if the need arises. At the end of the process, the client has a working product they can sell or use to perform business. A successful product earns us their trust in the agile process, now that they have seen it, sprint over sprint.
As with every complex software applications, the work has just begun at this point. With established trust, and a product that they can do business with, the client finally buys into the agile process, and we engage again, this time in a month to month resource-based agile model. We provide the client with tools to manage their own backlog, view story points (they get a crash course on it), and adjust priorities as their business needs dictate. No more questioning the invoices every month. Now they know the size of the team they are paying for and the velocity in which they can develop.
The process I have defined is nothing extraordinary. It’s simply an amalgamation of old-world, estimate-first tactics combined with the understanding that our work is what will buy us the trust we need. It’s about showing clients the benefits of agile, not just the process.
Once we are there, it’s smooth agiling!