Agile methodology is now so firmly entrenched in software development culture that any challenge or deviation from the “Agile Manifesto” is seen as heresy.
And that’s fine, we agree that Agile has its place in delivery of software - we use it internally ourselves.
The challenge comes when the approach is applied to the type of projects generally running in your PSA system; namely customer-driven billable ones.
Work you are doing on a funded basis for clients using Agile methodology has a number of issues, really no matter how the work is paid for. Let’s discuss these issues using the different ways such work can be billed:
Here the client is basically outsourcing development work using an agreed team size to deliver. This really works well with agile as the whole paid model is actually just like an internal team and the quantum of work produced can be tracked perfectly using sprints, stories etc. The client can increase or decrease their investment at any time and the number of features delivered in a specific timeframe can be adjusted accordingly. The issue with this approach is that the freedom to flex the budget assumes that a defined end point has not been agreed, and that the resulting application can work satisfactorily with missing features.
Here the client has agreed to pay for features based upon the number of points delivered. So, the agile methodology works perfectly, providing trust exists that points are of equal value (they are supposed to be in agile, but are they always?). The challenge comes when low-level easy features get delivered and more complex ones fail to complete. The supplier is earning money but the tough (and presumably more necessary) aspects of the application get pushed back.
Generally preferred by clients, who mostly believe that by fixing the price they are removing budget risk. This is of course untrue unless the supplier is prepared to work for free to handle the changes and clarifications that naturally occur in the development process. Fixed price work is perhaps the least compatible with agile methodology as it presumes that a discrete quanta of work will deliver a satisfactory solution - almost the antithesis of the agile manifesto.
Time and materials
Not really compatible with the methodology as preached by agile purists. Given that points are a calibrated surrogate for time, valuing points is seen as clearly superior to valuing worked time.
So, unless you can get a client to agree to team-base the effort, all billing methods have real challenges when it comes to applying pure Agile methodology to reimbursable work.
This is not so say that the alternative is old-style rigid waterfall software engineering as preached by IBM in the 70s. No one really does that any more, though it is still quoted as the benchmark comparison to the sunny uplands of Agile.
The argument is of course far more nuanced and the reality for reimbursable development needs to be a subtle combination of aspects of both approaches.
Most software development these days is highly flexible in concept, engaging customers at the earliest stage possible with mock-ups, workshops and prototypes, challenging their assumptions and prejudices. Applications themselves are more naturally user configurable, addressing acceptability gaps with simple configuration changes. Opensource toolsets embody standardised functions that eliminate much of the coding errors and allow rapid prototyping and deliver code that is fast to change and adapt. This is the reality of today’s software development - the tooling and approach is naturally more agile (with a small “a”) in nature.
Work can of course be documented as a feature listing (backlog), broken down into sprints and progress measured in points. However, the real productivity improvements and improving success rates since the 70s have come about from increasing re-usability of function, short cycle adaptive coding and dev/ops environments that support automated integration testing. This is approaching software development with agility, not to be confused with religious adherent to any manifesto.
Paid development must result in a working solution that meets the requirements of the buyer in such a way that (in general) the system being replaced can be decommissioned. This dictates a specific level of functionality that is not normally represented by the first MVP (minimum viable product) target proposed by Agile methodology. Buyers do not pay for new innovative MVPs; they pay for a solution that improves their existing situation (often a legacy platform that needs replacing). Something way beyond the scope of any MVP.
The key challenge with reimbursable development work remains agreeing the scope of the final deliverable in a manner that is both acceptable to the customer and understandable to the supplier. Plus of course the approach for managing changes.
This comprehensive end-state definition, while counter to Agile based iterative and flexible scoping, must be agreed nonetheless.
All billing models have their limitations and need to be enclosed in a framework that manages change to the satisfaction of both parties. However, taking a purist Agile approach to a reimbursable project risks creating confusion over the end-state deliverable and associated difficulties in revenue recognition.
About the Author: Harmony Business Systems Ltd (HBS) is the company behind HarmonyPSA, the most complete cloud PSA software on the market. Developed with functionality to cater for even the most complex needs of MSPs, VARs, ISVs and Professional Services organisations, HarmonyPSA truly is the next generation of PSA systems. Follow HarmonyPSA on Twitter, LinkedIn or Website