Agile and Custom Software: A Love Story
Earlier this summer, I started blogging about how Agile methodologies can help your company get the most from custom software. For part three of this series, I will share a success story from one of our clients.
As I’ve mentioned, many companies are initially concerned by Agile’s lack of a firm deadline and specific deliverables. This was exactly the case for this client. Several years ago, they hired Entrance to create a custom engineering application.
At the time, they thought they had a pretty firm idea of what they needed the application to do. In addition, the internal team felt they would never get the project approved if it wasn’t fixed fee. As a result, they decided to go with Waterfall development methodology. After a year and a half, the project was going well.
Eliminating Administrative Hassle
However, the divergence between what was initially scoped and what the client realized they needed grew over time. Every time the project changed, it had to be documented, and then change orders needed to be signed. The delay and additional administrative hassle became a big pain point.
When we suggested that the client consider switching to the Agile process, they were initially skeptical about convincing management. Once we fixed an initial budget and explained the process of working towards a goal every two weeks, they agreed to try it out.
Agile Methodology and Sprints
The transition from Waterfall to Agile involved moving from a fixed fee to an hourly basis. Entrance and the client work together as a team to establish a goal for each two week sprint. As work is accomplished from these sprints, the scope of the project is tweaked as needed.
Our client’s business is changing all time, so over the past year and a half since the switch, they have found that Agile meets their business need much better.
Three of the biggest learnings for our client from this project are:
1. Trust is Key
When they first hired us, the client hadn’t yet established the trust to be comfortable with a project that was somewhat open ended. After we proved that we could do the work, it was much easier for them to commit to a slightly riskier but more efficient process
2. There will be unknowns
It would be nice to know the complete scope for a custom application in advance. Most of the time though, the requirements develop organically as the project moves along.
Be comfortable with the fact that what you know at the beginning of a project will not be the same as what you know at the end.
3. Agile isn’t completely open ended
One common perception of Agile in some circles is that it’s completely open ended and has no finite finishing point. For a well-managed Agile project, this just isn’t true.
Agile methodologies, when executed correctly, will result in a project that is more likely to meet your business goals, not less. One way to ensure that that this happens is to set your priorities for scope, budget, and schedule.
Any two of these three priorities can be fixed in an Agile project, so it is important to understand which will mean the most to success for your project.
Maybe you can only afford to spend $75,000 on a project, and you need it by the end of the year. Or perhaps your company has a hard deadline for the launch of an application and a very specific scope of work, which suggests that the budget should not be fixed.
This premise is called the iron triangle. The figure to the left illustrates this.
For more on Agile software development, check out part one in our series. Or find out more about the engineering software development that went into the client’s custom application in this case study!