Agile in name only
hi all
We are currently involved in an infrastructure type project to deliver a piece of third party software. There will be no self development here, essentially the software is provided by a vendor and we have to integrate this into our environment.
There is talk of this project being run in a an agile manner, and we have broken the delivery into a series of sprints. However, if we do adopt agile practices here I want to avoid this being “agile in name only”, where sprints are essentially the same as waterfall phases.
the scrum manifesto is quite explicit in terms of guiding principles, however any recommendations on how we can ensure this delivery really works in the spirit of agile as opposed to being a waterfall project named agile?
It sounds from what you stated that this approach is much better than a vendor going dark for a period of months and then throwing it over the wall for your team, resulting in many more months of integration. I have seen many vendors state they use Agile, but in fact are anything but. My advice is to understand and negotiate a good contract with them that spells out scope changes and an exit strategy.
Has the vendor stated which Agile framework they use? Is it Scrum? The key piece of your contract should spell how out the length of each Sprint and how scope changes will be handled after inspecting each delivery.
Is there flexibility in the contract to adapt and change scope for the next Sprint? After each delivery your team will learn more as you integrate.
Is there an option for the contract to be terminated at any point for a small penalty? For example, your team finds that you have all the functionality needed after 7 of 10 planned Sprints, and the remaining cost to finish the work exceeds future value of the functionality. Rather than continue to waste money, the contract terminates for n% of remaining costs, a win-win for both you and the vendor.
Is there an opportunity to bring both your team and the vendor together to come up with a high level plan? And then in rolling waves (after every Sprint), inspect and adapt the plan?
There is talk of this project being run in a an agile manner, and we have broken the delivery into a series of sprints.
Why? What degree of complexity or uncertainty is there for agile practitioners to bring under control?
Is there a reason, in this case, to suspect that integration will not be straightforward, and that staged planning will prove inadequate? How well has this risk actually been articulated?
However, if we do adopt agile practices here I want to avoid this being “agile in name only”, where sprints are essentially the same as waterfall phases.
I'll answer this from a Scrum perspective. Of course it is possible to be agile without Scrum.
Does the vendor agree to provide a "Done" increment at least once per Sprint, so that you can provide feedback?
Will the vendor share their definition of "Done" with you, so that they are accountable for the quality of that increment?
If they do this, then you should at least be able to form some kind of empirical judgement about progress towards a goal or milestone. The more transparent they are, the better.
Ideally the contract or working relationship will be sufficient to allow your company to influence what is developed, as more is learned.
One question - assumimg Agile states that each sprint should be based on user stories and deliver working software that meets the definition of Done - and the vendor can do this - then I think this is good?