Practical Agile went on the road for December and was very kindly hosted by Opencast. As I couldn’t just walk downstairs this time I was a little late and found the discussion in full flow.
The conversation revolved around an interesting situation where negotiations were underway to deliver a project where a specific set of functionality had to be delivered by a specific date in order to secure funding. As part of the proposed contract punitive clauses would be applied if delivery was not made.
The first question raised was if Scrum was the best framework for tackling this work given a fixed specification and delivery date? Unsurprisingly – this being an Agile group – the feeling seemed to be this would not be an issue and that a more traditional approach such as waterfall would be more prone to failure. The team should be able to experiment, prototype and then harden and this fits well within a Scrum Inspect and Adapt cycle.
In order to avoid the penalties it is vital that the essential Core Functionality that must be delivered to ensure that the funding is received is identified and prioritised as such.
I Love It when a No Plan Survives Contact with the Enemy Comes Together
Given that (as part of the contract) we have a very well defined specification we should have a good understanding of what must be delivered. Concerns were expressed that this may stifle innovation and learning from the development team. Including the Development Team (not necessarily the full team all the time) in the discovery up front would ideally lead us to a situation where the WHAT is rigidly defined but there is wiggle room on the HOW.
However common experience told us that no set of requirements ever fully defines the product and that we will always want to make sure we set aside a suitable percentage of time for scope creep.
In addition non-functional requirements such as Performance, Stress and User Testing and Documentation such as User Guides are scoped and agreed up front and suitable stories created to support these activities.
With a hard dead line it’s vital the client is available and that Product Owner is empowered to quickly respond Yes or No if necessary.
In order to support the project the Definition of Done needs to be formalised and agreed. This will stop any misunderstanding or confusion about whether the contract has been met.
It’s not You, It’s M… Well It’s Them Actually
Involvement of 3rd parties was felt to be a potential source of pain.
It needs to be very clear what would happen if a 3rd party failed to deliver, with the impact that the project missed the deadline. What would this mean to the triggering of any punitive clauses?
Direct communications with any 3rd parties should to be firmly in place and it is essential that these be open and honest. The exact expectations from all sides would need to be clearly set out as would the responsibilities of all parties.
Bare Minimum Viable Product Or Minimum Marketable Product?
If getting paid is dependent on delivering the core functionality to the deadlines do we have any reason to go further than that? In addition would there be temptation to fudge the solution leaving lots of technical debt?
Several reasons were suggested as to why more than just the core functionality would be delivered. These included increased chance of an extension to the contract, repeat business for other projects and the desire to do the best job possible.
Teams would always seek to minimise technical debt purely out of a sense of pride in their work and professionalism. On a less altruistic motive they would always seek to reduce the support overhead that technical debt means.
Having a rigid set of requirements with a hard deadline doesn’t mean that Scrum isn’t the appropriate framework to use for the project. It is a framework and does not say how the work is to be done!
Isn’t every project a fixed budget project? (at least to begin with!)
And that sort of covers a very interesting and lively discussion. All that remains is to wish everyone Best Wishes for the Festive Season and thanks again to Opencast.
We’re taking January off so Look forward to see you all again in February when we’ll be once again back at NCFE!