Agile software development has been picking up steam in the last couple of years and especially SCRUM has become a very popular development methodology. SCRUM can produce better results for complex projects and the internet is full of helpful tips on how to tailor it to specific project types, team structures or industries.
I have been using SCRUM for several years now, in both large and small environments and found that there are non-technical benefits from the SCRUM process that can have a positive impact on your business. Benefits such as effective customer engagement, timely customer payments and better estimates should be of interest to everyone in the software development business. Small companies may benefit the most because the link between a developer’s pay cheque and customer happiness is obvious and there can be direct contact between end user and developers.
Engage the customer
Virtually every software development company out there claims to listen to its customers and care about end user value rather than focusing on technology. But if you have had custom software developed before, you know how hollow those promises can sound when you look at the end results.
The SCRUM methodology provides a framework to actively involve your customers: you can show them the backlog, ask them to prioritize stories, have them attend sprint demos and show them that their feedback is incorporated in stories and sprint planning. Your user stories are focused on the user and easily understood by end users, making it easy for them to provide feedback and decide on priority.
Agile development is only practical when the development contract is also Agile and allows for budget overrun and time slip. But justifying the extra cost or late delivery can be very difficult and sometimes even fatal. With SCRUM, you can help the customer discover the need for a change in requirements and make the calculation of the extra cost entirely transparent. This makes the justification easy and builds trust.
Speak to the person paying the invoices
Most contracts specify invoicing based on timelines or milestones. Using SCRUM sprint ends as milestones, you can specify demonstrated functionality as the milestones for invoicing. This functionality is described in plain English and the person signing off on payments can attend the sprint demo to verify that you have delivered the goods.
People who sign cheques rarely have the time, patience or interest for in-depth technical discussions. But if they can bring one of their own technical people to a sprint demo, observe that stuff generally works and have the techie try and poke some holes in the demo narrative, even the most sceptical managers can be convinced to pay you.
Build more accurate estimates
Small software development businesses are only as good as their ability to accurately estimate how much time will be needed for a project they are bidding on. Not only can using the SCRUM methodology improve the estimate accuracy over time, it also gives you valuable numbers and formulas to ‘prove’ that you know what you’re doing if you are looking for investors.
Creating a story backlog and assigning story points to those stories before you start a task breakdown is in fact very similar to how to go about creating a time and/or budget estimate for a software project. If your SCRUM team has not changed a lot, you can use the team’s velocity to calculate a time estimate and from there, a budget estimate.
For time & materials contracts (which need the time and budget estimates for hard maximum caps), you can use task burn-down numbers from previous projects to hedge the customer’s expectations: you can show them, in numbers, how sprint velocity generally ramps up for successful projects and thus how you will get more bang for your buck as the project moved forward. If you have an inventory of past SCRUM projects, you may even give customers examples of how ‘bad things’ happening to a project, for example the sponsor leaving or budget and requirement changes) have affected velocity and backlog length.
When customers google things like ‘velocity’ and ‘burndown’, they get results showing that SCRUM is a respectable methodology using straightforward metrics and formulas. Project budgets are often controlled by people who love numbers; if you can give them numbers to crunch, give them some guidance on what those numbers mean and let them figure out the rest, you remove some of the perceived risk and may get approved for larger projects.