How agile can we really be with RPA? It’s a conversation I remember having in 2014 when I left an established ‘Operational Agility’ team (the old name for RPA, although not quite as catchy) and joined a well-known consulting firm.
Agile RPA is a concept many industry practitioners still struggle with today. Yet it remains one of the biggest opportunities for business leaders to maximize their return on investment.
When done right, agile RPA accelerates delivery, reduces cost and increases engagement across project teams. Despite these benefits, many organizations still turn to traditional delivery methods which are often slow and expensive.
The question is why?
Well, adopting a truly agile approach contradicts everything that we as change professionals have been taught over the last 10-15 years. Everything about Prince2, V- Model and Waterfall. Everything we know about the roles and skills needed to deliver change. Perhaps most of all, everything we’ve gleaned from the RPA industry in recent years.
There’s no denying that agile RPA is a paradigm shift for most organizations, but automation leaders must be willing to challenge current ways of working and pilot new approaches. Nevertheless, many RPA methodologies I see published today are inherently Waterfall, even if the term ‘user stories’ feature. Part of the problem is that online RPA training courses, project templates and industry certifications all point to an RPA playbook that hasn’t evolved much since 2011:
- Design and document all requirements. Lock down scope and sign it off.
- Design and document the solution. Lock down scope and sign it off.
- Build & test everything at once. Sign it off.
- Release, break, fix, repeat.
Under this Waterfall-style model, RPA teams are effectively asking their customers to sign up to a design contract to protect them from scope creep. Invariably, requirements are missed or mis-interpreted (we are human after-all). This then triggers a change control process which is a major source of frustration for everyone involved, especially after so much time invested in the ‘Design’ stage. It causes project delays, but crucially fuels animosity between project teams.
Furthermore, the traditional approach adds unnecessary time, cost and complexity. Waterfall teams can fall into the trap of delivering documentation, rather than business outcomes. The ‘Design Document’ becomes the main deliverable and teams lose sight of what the customer values: a working solution.
Through years of experimentation, I’ve found that agile RPA is most effective when delivered as part of an internal Centre of Excellence. However, even when leveraging a partner ecosystem, there are three agile concepts that you should consider:
- Deliver value quickly through Minimum Viable Products (MVP)
- Focus on creating working solutions rather than documentation
- Collaborate with the customer and establish a culture of trust
1. Deliver value quickly through Minimum Viable Products (MVP)
Remember, the value to your end customer is having an automation solution that removes manual activity as quickly as possible.
Set the expectation upfront that the process may not be fully automated when the solution goes live, and that that’s OK. If a process has ten scenarios, but 70 percent of the work can be removed quickly by automating three of those scenarios, your customer will be delighted. The other 30 percent can be set as ‘exceptions’ and added to your RPA product backlog.
There is one fundamental Operating Model element that needs to be in place for this to work: a governance structure, spanning Operations and IT, that allows for quick and frequent releases.
2. Focus efforts on creating working solutions rather than documentation
Perhaps the agile concept I love to debate most. It’s a proven approach, but few have piloted it. Those who have, report great success.
To build an RPA solution, Developers don’t need a 60+ page requirements document written by a Business Analyst. Nor do they need a 50+ page technical document written by a Solution Architect. They simply need to understand the process in enough detail to start developing. The question then becomes, how do we give developers a deep understanding of the process?
Consider this. Your RPA Developers are your new Analysts. They run observation exercises with Subject Matter Experts (SMEs), they understand the business rules and they work with the SMEs to decide which scenarios will add most value. Under this model, Developers have the opportunity to identify and solve technical challenges early on and build relationships with the business.
Any process documentation that’s created is done so in parallel to development and serves as a reference document to be used once the process is live. Under this model, a Design Document is not used to inform the solution, nor is one used to lock down scope.
The goal is to develop a solution that you can quickly put in front of SMEs, gather feedback and iterate every few days.
There is another fundamental element of your Operating Model that needs to be in place for this to work: People. You’ll need Developers with the right soft skills who are willing to build great relationships with your customers and elicit process information through conversation rather than relying on documentation.
3. Collaborate with the customer and establish a culture of trust
Instilling a collaborative culture is hard. Not least because culture is influenced by so many different factors: leadership behaviors, HR practices, management competencies and team structures.
Collaborative ways of working across project teams are key and behaviors like appreciating others, engaging in purposeful conversations and actively trying to resolve conflicts should be nurtured in all RPA teams.
However, this is actually where I’ve seen most organizations excel. The more difficult culture to instill is one of accountability within the business and trust within IT.
One proven way to build trust with IT is to partner with them and define a set of RPA principles upfront, one of which outlines when the business has authority to approve processes into live and when IT should be involved. Truly agile RPA teams create an environment where the business is trusted to approve processes into live and to manage their operational risks. By contrast, IT focus on managing technical risks. The beauty of RPA is that technical risk is virtually non-existent.
One way to create accountability within the business is to have process owners adopt the role of RPA Product Managers. Product Managers determine which items in the backlog should be delivered first. This gives a sense of ownership and shows your willing to put your customer’s interests first. Product Managers also become the gatekeepers for any new RPA projects and have sole responsibility for approving new processes into live.
By constantly challenging the model, automation leaders have an opportunity to create even more value in their organization. However, one could argue that there is a safe option. Stick with you what you know about RPA delivery and trust that things will eventually come good. As the great Charles Kettering once said: If you have always done it that way, it is probably wrong.
Dan Johnson, Director and Co-founder, AiSpace