A Hybrid Agile approach to delivering RPA

Organisations have been rapidly taking the leap from considering initial proof of concepts in Robotics Process Automation (RPA) to committing to invest in the technology and deploying it at scale, with more than 22% of large companies already using RPA in their space. 1

Once leadership teams have identified areas of opportunity within their businesses that would significantly benefit from leveraging RPA, they are delving into setting up the most appropriate operating models and relevant governing bodies required for successful delivery of RPA.

Successful delivery of RPA – what does this look like?

The ‘traditional’ RPA delivery model (as traditional as it can get, still being fairly new) is mostly structured as a waterfall method. This involves clearly defined, sequential stages to follow – from conceptual idea to design, development, testing and deployment. While all organisations will have their unique operating model set-up and governance, the common themes largely remain the same.

Broadly speaking, the delivery of RPA can have three main phases. The initial phase of an RPA lifecycle is an Assessment phase, where the business case for an Automation is justified. Delivery phase takes the automation from design all the way to deploying in production, and the last phase is to fully productionise the solution with maintenance and support structures in place. Each of these phases are underpinned by multiple checkpoints and gates before progressing along the line to deliver automation into production.

So in defining the right operating rhythm to deploy RPA at scale, why does it make sense to have an agile approach to the Delivery phase of the RPA lifecycle?

RPA is a non-invasive technology that interacts with applications at the presentation layer, with capabilities for API and other integration methods. This makes it relatively much faster to deploy than traditional large IT programs. Sitting mainly on the User Interface level also, in theory, gives RPA a greater licence to be eligible for agile.

General concerns regarding deployment of software or IT changes can still hold true for RPA as well, in regards to technical and people change. Issues such as gaining access to system environments, getting security approvals and coordinating with the relevant stakeholders – this sort of change management blockers are usually faced in the initial Assessment stage.

However, once the initial Assessment phase is complete, the delivery of RPA which includes the scoping and design, build, test and deployment of automated processes can be done in very effective timeframes – and this is where agile comes in to play.

This is one example of how a hybrid-agile delivery model can be set up.

The length of the Delivery phase is generally proportional to the size and complexity of the process being automated. For processes that have a considerable amount of complexity to them, the Delivery can be tackled in iterative sprints. In one sprint, the deliverable after Configuring, Testing and Deploying a unit of automation would be a signed-off and approved Version 1 of the Technical design document and the test summary document. In the same sprint for Scope and Design, the deliverable would be an approved Version 2 of a Business process requirement document. This would be the basis for configuration in the following sprint, and so on.

In a hybrid-agile model, the length of the sprint can be defined by what is achievable and viable to build and test. The number of sprints can be defined by the overall goal for automation.

Why it makes sense to use hybrid agile for RPA

1. Continuous improvement

Particularly in a scenario where an automation is deployed for the first time, it is more susceptible to large volumes of exceptions and errors. Given the technical landscape of RPA is not yet fully mature, both the business and delivery team may face challenges as experience in developing code or capturing requirements may be limited.

In using agile delivery, it is possible to tackle these exceptions iteratively and quickly in each sprint so that the business can realise incremental benefits from the automation steadily, and enable them to obtain a deeper understanding of RPA through implementation.

Think of a new employee starting out on a role. Just as s/he will ask a lot of questions to become familiar with a new process, the virtual worker (robot) will go through a similar learning phase of asking questions – by throwing out exceptions when an unfamiliar scenario is encountered. In these instances, a human worker would ask a more experienced team member (in the robot’s case – the process controller) to enhance their knowledge of the process (or increase success rate).

While the business may be well-versed with the process to be automated – this is vastly different to knowing the minute details and variations of each step to the level of detail required for automation. Going into production quickly and iteratively means the automation can adapt to learn variations of the process as they are encountered over time. It would also increase confidence of the business to approve deploying into production as a continuous delivery pipeline provides comfort that any errors can always be dealt within the next iteration.

2. Collaborative, multi-disciplinary teams

An agile set up generally means that the core stages of the design, build and test phases would need to be executed in a cyclical manner each sprint. This means that dedicated team members responsible for different stages of the delivery would be utilised at all times, making the delivery model more effective from a cost and time perspective. For example, during the ‘Build’ phase, the team member responsible for finishing Design can focus their effort on the next iteration of design – making the staffing of project much easier as all team members are continuously utilised. It also allows the scrum team the opportunity to continuously cross-skill in their knowledge of the business and of the process by progressively gaining in-depth familiarity through working with the business teams in each sprint. Additional updates to the automation can be made as new rules or scenarios are uncovered. It also allows the chance for minor process improvements within the business teams if required to support the automation.

3. Visibility

There are a number of cases where Agile can enable greater visibility into the deployment of RPA.

  • Visibility of outcomes: Deploying in frequent short sprints means the value being provided by automation can be continuously monitored. “Statuses” and “Tags” can be built into the code for ease of reporting.
  • Visibility within the team: Daily stand-ups, retro’s and demos all help provide visibility within the teams and helps identify risks, dependencies and issues early on. By including Process Owners in discussions iteratively, issues or discrepancies identified in the process undergoing automation are surfaced as they are encountered, allowing the opportunity to mitigate them before deployment.
  • Visibility to the Business stakeholders: In an agile way-of-working, a dedicated business subject matter expert (SME)SME for the delivery team should support the constant iterations of Design and Test. Gaps in logic or algorithms used manually is quickly identified. If required, the SME would then have the opportunity to relay back to the business team and the Product Owner the new rules to adopt. This means the business would be continuously engaged, and the delivery team would start to work with the business rather than for the business, which helps foster a culture of shared responsibility and accountability.
4. Continuous interaction, not just documentation

Documentation for RPA broadly can be split into two areas: technical documentation related to the build, and the documentation used to record the manual processes. In documenting the manual processes for automation to replicate, there needs to be a far greater degree of detail and decision-making logic included than a normal work-instruction sheet for a team member. For example, human instructions might state something like – “check that field A matches field B”. In documenting the same step for a ‘robot worker’, this would need to specify, for example – whether or not the fields are case sensitive, whether special characters would be considered a match or not, and what action to take in case of a blank field. These details are much easier to surface through gathering requirements through multiple sprints, rather than one long ‘design’ phase. Through multiple iterations of testing, new scenarios surface and can be included in the documentation as updated versions to capture and build a robust process.

When you consider the virtual workers making decisions based on logic autonomously, detailed documentation becomes critical to the success of an RPA delivery model, particularly from a risk and legal perspective. While it is important to maintain a focus on detailed requirement capture and documentation, having an agile principle also strongly supports a culture of interaction – which becomes pivotal when considering communication between development team, production support team and business stakeholders. As underlying logic and algorithms are strengthened through iterations of development and design, they can be reported back to the Business progressively and in real time. RPA essentially transforms the way people work – and as with any project, effective communication is critical to ensuring no roadblocks are faced. Potential resistance to change can be minimised by engaging broader teams through agile ceremonies such as sprint reviews.

5. Flexibility

Working agile also means the project team can adapt to external factors Because RPA technology works with systems on the presentation layer, any small changes can lead to automation failures. For example, a small visual update on a website that would go unnoticed to the average human eye, can cause the automation to break as the new elements would not the recognised. Being able to adapt quickly to a system upgrade or a screen change becomes of utmost importance while deploying automation.

It is also particularly important to cross-skill team members in a new technology competency so that the knowledge is shared. For example, Environment Lead can appreciate the challenges a Developer can face around VM availability issues, or Designers can understand the level of detail required in documentation by getting visibility into the types of test scenarios it can lead to.

Considerations of delivering RPA using agile

While the benefits of an Agile delivery approach of RPA seem relatively easy to envisage, before jumping head-first into an Agile way of working, there are some careful considerations in deciding whether agile is the right approach.

Don’t bite off more than you can chew

A key consideration in using an agile way for working is the level of an organization’s or team’s experience in agile. As any agile enthusiast would agree – agile is a lot more than stand-ups and retro’s. Adopting an agile way of working comes with its own set of learnings and obstacles that need to be addressed, from governance to upskilling to change management. If you have a team that is new to Agile, which requires a lot of upskilling and training and practice to get right and is transformative to the operations of a business – and new to RPA, which also transforms a business and requires dedicated training and upskilling – it may be a better idea to focus on one rather than tackling both at the same time.

Be prepared to get it wrong, before you get it right

When starting out in an agile journey delivering RPA for the first time – it is better to aim low and set marginal targets before gaining momentum than aiming for the sky. Set realistic timelines and story points for tasks, and over a few sprints the team will naturally start to gauge an understanding of what works and what doesn’t. Setting expectation early on with business on this approach is also critical – with the confidence that the automation will be incrementally approved as more use cases are built out. Adopting a forward looking approach and ensuring the implementation has been given adequate time to go through thorough QA and testing are vital in ensuring no surprises are met with when deployed into production.

Setting up an RPA delivery programme is not PoC on a larger scale

A big trap in diving headfirst into productionising RPA after successfully proving out a business case from doing a few proof of concepts is the thinking that productionising is simply an extended version of a PoC. Regardless of delivery model of agile vs. waterfall vs. hybrid, the most important focus before productionising should be around set up of a base operating model, having a clear owner/custodian to support and define process controls, standards, operations and support models with clear definitions of accountability and responsibilities.

Lastly, don’t forget the people

Delivering RPA successfully essentially transforms the way humans work by introducing virtual robot “colleagues”, and is a definite disruptor in the market. There should be a significant focus on change management and providing comfort to employees around the realities of the impacts, including providing upskill and reskill support specific to their role and preparing them with the right tools. This is best done iteratively, so workers are brought along the journey of deploying RPA in the processes where traditionally only their team members were responsible for and have a chance to gain familiarity with their new virtual colleagues. There will always be value in experience, human judgement and institutional history provided by employees that drives a successful organisation enabled by technology. Dedicated change management is key to empowering the human workforce to nurture their new virtual colleagues just like any other new human trainee in their team, and is an important enabler to the iterative delivery of RPA.

In summary, delivery of RPA makes for a perfect use-case for a hybrid-agile approach given the type of technology it is. However, to fully realise the benefits of this delivery model, the holistic impacts of RPA unique to the process and the organisation must be considered and catered for upfront.

1 Deloitte UK article, Robotic Process Automation https://www2.deloitte.com/uk/en/pages/innovation/solutions/robotic-process-automation.html


Want to stay up-to-date?

Stay on trend and in the know when you sign up for our latest content

Subscribe