The project has just started up and the team are discussing the concept for the new solution. Perhaps, they are creating a product metaphor or even sketching out a Product Box. They remind themselves that the customer has cash constraints so whatever the outcome it must be cheap! After all the client did ask for Agile delivery ensuring that they get the highest value features first and that they can stop at any point.
But what did the customer really mean when they asked for cheap?
Did they mean A) cheap to deliver?
Here they want you to provide a walking skeleton as quickly as possible so they can prove the concept. This is quickly made releasable where it can generate value. Only when the solution is proving the concept and generating value is the product enhanced with new features. Only then is a more sustainable technical solution provided and put in place to underpin the product.
The IT supplier is looking to keep the schedule and head count as small as possible. The cost of the resources and the fat trimmed from the delivery plan becomes a primary concern. When issues are discovered during delivery, there is pressure to take the path of least resistance which is often a hack or a workaround or worst, reliance on human intervention to make up for something the software doesn’t do
Or did they mean B) cheap to run
The solution must be reliable and bug free. When a problem is encountered, a clear and consistent monitoring solution must enable simple and timely identification of the cause, allow the system to be corrected and restart any stalled transactions.
The solution should be pay as you go and the client wants to incur no capital costs or other overheads. If the traffic throughput goes down so should the run costs. Obviously, if the product is a roaring success the customer also wants an advantageous cost model that benefits from economies of scale.
A cheap to run system is not necessarily the cheapest to deliver. As a minimum the project team will have to deliver “ops” stories in order for the system to be run and supported effectively. Not everyone has embraced DevOps so perhaps for this customer you’ll have to ramp up a separate support team. Maybe they will mandate that the software has to be integrated with a predefined set of support tools. Maybe they have many other operational requirements too.
Or what about C) cheap in terms of their payroll, e.g., they can reduce head count
The whole point of software is to automate manual processes, right? The customer wants to be able to do more with less. They want to reduce their headcount and therefore the burden on their payroll and they expect that the remaining staff will achieve much more than the original team.
This means the user interface needs to be up to scratch. The user needs to be able to deal with large volumes of data quickly and effectively. When the system needs human intervention it needs to detect the most appropriate user with enough capacity to do the work.
None of this comes for free and the way in which the system will deal with this will require some thought.
Or maybe they meant D) cheap to change and customise the solution (without paying for an expensive IT supplier)
Change is inevitable and you should expect your software to be adapted, extended and repurposed continuously throughout its lifetime. It is unrealistic to work with a customer for a year delivering in an Agile way where the solution emerges over time, shaped by the customer’s priority, only then to assume that nothing else will change for the rest of the solution’s life.
So in this case the customer may be implying that the solution should be configurable so its behaviour can be changed along with the heartbeat of the business. They know that each financial or academic year the business changes and therefore their software needs to change too. The system behaviour should be adjustable by a business user – a development team is not required.
Building a data or configuration driven system is not easy. Not only do you have to develop the system in terms of the business now, but you also have to speculate on what changes may occur in the future. Without care every conversation about the current requirements degenerates into “what if” discussions. It becomes impossible to determine what is required for the present moment, what is required for later and what is simply opinion.
This extra effort in terms of clearing up the speculation and ambiguity should not be under estimated. If you cannot clearly define the requirements of how the system needs to be flexible and package them into unambiguous deliverable units, solution delivery will not be cheap and you are unlikely to meet the objective of having a system that is easy to change as the business changes.
The answer is all of them
Agile projects tend to focus on delivering business value quickly which is sometimes misinterpreted as simply delivering quickly. Delivering value quickly does not just mean JFDI. All the other quality objectives of the solution must be understood and there must be a means to deliver them too.
This is where architects add value on Agile projects. Architects have experience of looking at the bigger picture and focus on the non-functional characteristics of the solution. They can work with the Product Owner and the development team to help them understand how the solution will fit within the organisation. When Architects are asked for a cheap solution they can help the customer understand which kind of “cheap” they mean.