In Part 1 of this series, we have discussed the basics of Agile and some misconceptions around it. In Part 2, we dug deeper into the Agile Iceberg and understood what it means for RPA. In this final part, I will aim to bring all of this full circle to answer our original premise: whether Agile should be used for RPA projects or not.
My response to this is in two parts:
First, Agile for RPA is no different than Agile for any other software project. The 12 Principles of Agile Software are agnostic to technology being used to automate a business process. The Agile model you choose will only determine your path from idea to implementation – e.g. with Scrum, you will have a Product Backlog (of Blue Prism processes and objects), Sprint cycles (spanning design-environment setup-develop-test-demo-repeat), Planning, and Retrospectives; With Kanban, you will setup boards and cards to track your work and progress – but the end goals discussed in Part 2 are still the same for RPA or any other software project.
Second, RPA is a strong enabler for Intelligent Automation (IA) capability, and Agile for RPA helps you fast-track your IA journey. Evaluation and usage of IA tools usually takes a longer time as there is not only a plethora of options in each IA category, but also varying technology complexities involved. The Waterfall way of identifying all the needs of your business and then determining which tool fits the bill will clearly be very time consuming. But an Agile methodology clearly will be helpful here as it creates a culture of experimentation (fail fast, learn faster). This means you can pick one department and evaluate the IA tools against it, shortlist your options, pick the next department, evaluate and shortlist again, and so on. You can do this in multiple iterations (for multiple departments) or just do 1 iteration (for one department) and call it a day. If you don’t get the desired results along the way then drop the tool, pick the next one in your list, and repeat. Regardless, your lead time to evaluate and decide reduces significantly.
The takeaways from the above is this:
- If your organization is already setup for Agile, then use Agile your RPA program as well. If your organization is setup for Waterfall, use Waterfall. The rationale is don’t disrupt the current way of working just for a new technology. In my experience, it is lot easier to learn a new technology than to create a culture of working.
- If the vision for your Digital Transformation starts and stops with RPA, then #1 above still holds good. However, if you intend to use the full gamut of RPA+IA technologies to drive Digital Transformation across the Customer Journey, then Agile gives you a significant strategic advantage.
A few final thoughts and observations –
- Co-location significantly improves pace of delivery and some organizations have gone as far as redesigning their building floor plans so that business and developers can sit together. However, co-location can be very expensive to achieve. If you have abandoned co-location in your delivery model, do compensate for it elsewhere.
- Remote Agile will probably be a necessity than an option in a post-Covid19 world. This McKinsey article outlines the do’s and don’ts of remote Agile quite nicely (be aware that the author has used Agile and Scrum interchangeably here).
- Documentation is everyone’s pet peeve. Rarely anyone likes it, but it serves the crucial purpose of recording what you are building for. You will also hunt for the requirements or design document when a Change Request comes along 6 months after the project completed and the original developer is no longer working for you. Similar situation may arise if you are undergoing an Audit and are asked to provide documentary evidence. Having said that, your goal is automation, not documentation. Document what you need, and the way you need it, and discard what you can live without. Note that Agile preaches a working software over comprehensive documentation, not to eliminate documentation altogether – another common misconception!
- Tools are important, so factor them in from day 1. While Spreadsheets help a lot in early days, they become an administrative burden after a point. Be cautious of that and plan accordingly.
- Adapt and Evolve – Successful adopters of Agile are successful because they adapted the vanilla models to their organization and kept evolving them over time.
- Train your team of Developers, Managers, Product Owners, Senior Management – and anyone else closely linked to the success of your project – on Agile. More importantly, they need to understand why things are the way there.
And this pretty much sums it up. (I did say I was a fan 😊)
Thanks for reading. Hope the blogs were relevant to you. Please do share your experiences with Agile for RPA.
#agile
