The cost of software development and tips how to reduce it
How much money is being spend on specific project? How to measure software development efficiency and effectiveness?How utilisation is managed?
A few days ago, I and several other development managers had a very interesting meeting with our guys from Finance. They were trying to understand how much money was being spent on any specific project. They were asking how do we measure development efficiency and effectiveness in terms of time, quality and cost and how utilisation is managed? They knew we are working in an Agile manner so they asked us if we knew what the cost of story point was, and whether this cost can be standardised for all teams? We discussed and agreed that story point means something different for each team, and even within the same team, the speed of development is continuously changing as we increase our experience in the teams. I started thinking that measuring costs per story point may create inflation in the estimation process due to the expected increase in the team’s performance. Then we started discussing whether Agile is, or is not, better to manage costs than the Waterfall approach…
This started to make me think that even though we had a better understanding of how important it was to manage costs with a limited budget, it highlighted that may be it we weren’t as aligned in the understanding of software development complexity.
That reminded me the Stacey Matrix. I drew a chart with ‘What’ (Business Requirements) and ‘How’ (Technology) and ‘People’ dimensions and described when the project is simple, when is complicated and when it becomes complex.
Since an analogy always helps us to understand a situation better I used these three examples:
1. A simple project is when requirements and technology are well known. For example, it can be factory producing bottles. We know exactly what we are producing and how resources and time of the production are well known. If the work is repeatable it’s simple and can be effectively managed in Waterfall approach.
2. Construction of a new building is a complicated project. There are many design details and this has to be managed closely by crew supervisor, but it’s easy to replace somebody from the construction crew if that is needed. If Janek fell ill, his work can be done by Stefan. The scope of the project is well known same is with the schedule, and it’s easy to add or remove resources to manage utilisation and deliverables.
3. Software development is complex. Initial requirements are never concrete enough nor complete, same with technology. No two projects are the same. Very often, what appears to be a simple problem is much harder to implement in reality. Development team “don’t know what they don’t know”, meaning that unknowns with the project can only be identified when they arise.
Going back to the question: ‘how do we measure cost and how utilisation is managed in software development’?
Each software development project has 3 constraints; people, schedule and scope. And we all know that Quality depends on each of them.
People — Effective Persistent Team
Forming a project team takes time and we can’t expect a new team to perform well from the start. Over time the team becomes more knowledgeable within the business and with the technology of the products they develop. This helps them be more effective, which means the speed in which they complete tasks increases, and estimates become more accurate. It’s also important to understand that the team is changing from being a group of strangers to a group with common goals. Bruce Tuckman’s forming-storming-norming-performing model describes all stages the team has to deal with. After the initial excitement, of when the team was formed, it moves into the storming stage, where people start to push against the boundaries. It’s also the time when conflicts between team members start. It’s a very critical time, and it takes a lot of effort and time to move the team into the norming stage to eventually reach the performing stage.
This is why in Agile we’re not forming new teams for each project, but building persistent teams working on the product.
Schedule — Fixed Iteration for Better Accuracy
In software development unknowns generate estimation errors. The accuracy of an estimate decreases with project duration; estimation errors increase the longer the project is. This can be represented by Cone of Uncertainty
In Agile, teams commit to fixed iterations of work for which it’s easier to discuss and estimate scope. It’s incremental approach where in each iteration the team delivers value to the business. Role of the Product Owner (PO) is to prioritise and define value and goal for the iteration. With this approach funding can also be incremental and increase. There is no need to ask for the total budget upfront. It’s enough to fund spike after which the team can report back a more accurate number depending on how long the project is going to take.
Scope — Effective Backlog Refinement
Agile projects have fixed iterations and resources while the scope varies. The team is constantly looking for feedback from the Product Owner and Business Stakeholders and adjusting the backlog of work to reflect it. The aim of this approach is to achieve the maximum business value by delivering what the customer needs by prioritisation. To manage costs, scope reduction is a better option than disrupting Agile teams.
In the end, the real cost is determined by which features are actually implemented and how long it will really take. This requires a fair amount of trust, but once the project starts and the team is delivering value to the business stakeholders in each iteration, they are rarely unhappy. Often, customers agree that some of the original features are not required.
The key issue is trust. Sometimes it’s good to start working with a new customer on a smaller project or explicitly break a large project into smaller projects to develop trust. If you’re not working with another department and you’re a totally new customer you may need to sign a Memorandum of Understanding (MoU), and Time and Material (T&M) contract to have the flexibility to adjust requirements, shift directions, replace features, and involve the customer to get the perfect/right product.
Tips on how to reduce cost of software development
Agile project management is necessary due to the complexity of the software projects. Such complex projects are not manageable in the traditional Waterfall approach. The Agile ceremonies focus on improving its teams, its processes and its product. Improving takes time, so I want to share some proven solutions on how to cut costs of software development:
Tip 1. Software Factory concept, DevOps culture, and Continuous Deployment solutions
Not every part of Software Development Live Cycle is complex. The work done during the iteration is complex and it’s an investment. When the feature/product is delivered in the Production environment it’s time for a return on investment (ROI). There’s a time between when the code is complete and is available to the end user. This time is needed to proceed with the tasks needed for the product release. Many times, this process is over-complicated, requires engagement from multiple groups, including the Dev team, release analysts, DBA team, OPS team… and very often it’s managed using the Waterfall approach. Since it’s possible to fully control this process and plan it upfront, it’s much better in terms of cost, quality and time to market, to build a Continuous Delivery solution founded on the concept of the highly automated delivery pipelines.
Continuous Delivery Pipelines shifts the release task from complicated to simple. This is also the way to provide quick and effective feedback on the product quality, increase team confidence and to reduce costs.
Tip 2. Cross-team collaboration (Inner Source), building Software Platform
Another way to save costs and to improve the quality is to code best practices into the shared software platform, which is easy to discover and to adopt by the Agile squads. It’s not easy to build a software platform. There are many challenges with software platform adoption in the company. In a separate article I will share ideas based, among other things, on the Inner Source approach, which helps with code reuse, cross-team collaboration, better quality and learning across the organisation.
Tip 3. The strategic planning technique — Impact Mapping
Using planning technique like Impact Mapping (by Gojko Adzic) it prevents teams from getting lost due to unclear requirements and wrong assumptions, focusing on deliverables in the context of impacts they are supposed to achieve. It helps to reduce waste by preventing over-engineered solutions. It helps to ensure that the right business outcomes are achieved, or that unrealistic projects are stopped before they cost too much. That model helps both the development of a team and to improve the questions asked by the business to Why the solution is needed, Who is going to use it, How should it work and What should it do. Team focus on goals and values which drives people’s behaviour change, as well on the way to measure progress and success.
There is more…
I just briefly selected a few aspects used to effectively manage software development projects. Many of them are already well described and easy to find on the internet, that’s why I didn’t focus on all the details.
Please feel free to comment and let me know what your experiences of managing software development costs effectively are. Do you know other tips which can help teams be more effective? For example, what is your experience with real costs of Cloud vs In-House infrastructure? Or maybe you’re experimenting with machine learning algorithms to lower costs of the production monitoring? I look forward to your comments…
