Embracing agile RPA | ITProPortal
How agile can we really be with RPA? It’s a conversation I remember when I left an established Operational Agility team (the old name for RPA, if not quite as catchy) in 2014 and joined a well-known consulting firm.
Agile RPA is a concept that many industry insiders still struggle with today. Still, it remains one of the greatest ways for executives to maximize their return on investment.
When done right, agile RPA speeds deployment, lowers costs, and increases engagement between project teams. Despite these advantages, many organizations are still turning to traditional deployment methods, which are often slow and expensive.
The question is why?
A truly agile approach goes against everything we have learned as change professionals over the past 10 to 15 years. Everything about Prince2, V-Model and Waterfall. Everything we know about the roles and skills required to make change happen. Perhaps most of all everything we’ve learned from the RPA industry over the past few years.
It cannot be denied that agile RPA is a paradigm shift for most companies, but automation leaders need to be willing to question current ways of working and try new approaches. Even so, many of the RPA methods I see published today are waterfall in nature, even when the term “user stories” is used. Part of the problem is that online RPA training, project templates, and industry certifications point to an RPA playbook that hasn’t evolved much since 2011:
- Design and document all requirements. Lock the scope and log off.
- Design and document the solution. Lock the scope and log off.
- Build and test everything at once. Sign out.
- Let go, break, fix, repeat.
As part of this waterfall-style model, RPA teams are effectively asking their clients to sign a design contract to protect them from scope creep. Requirements are always overlooked or misinterpreted (we are human after all). This then triggers a change control process that is a great source of frustration for everyone involved, especially after so much time invested in the design phase. This leads to project delays, but crucially increases hostility between project teams.
In addition, the traditional approach adds unnecessary time, cost, and complexity. Waterfall teams are more likely to fall into the trap of providing documentation than business results. The ‘design document’ becomes the most important result, and the 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 deployed as part of an in-house competence center. Even if you are using a partner ecosystem, there are three agile concepts to consider:
- Deliver value quickly with Minimum Viable Products (MVP)
- Focus on creating working solutions rather than documentation
- Work with the customer and create a culture of trust
1. Deliver value quickly with Minimum Viable Products (MVP)
Set the expectation in advance that the process may not be fully automated when the solution goes live and that it will be okay. If a process has ten scenarios, but automating three of those scenarios can quickly remove 70 percent of the work, your customer will be delighted. The other 30 percent can be set as “exceptions” and added to your RPA product backlog.
For this to work, there must be a fundamental element of the operating model: a governance structure that spans operations and IT and enables quick and frequent releases.
2. Focus on creating working solutions rather than documentation
Maybe the agile concept that I love to discuss most. It’s a proven approach, but few have piloted it. Those who have report great success.
To create an RPA solution, developers don’t need a 60-page requirements document created by a business analyst. You also don’t need a 50-page technical document written by a Solution Architect. All they need to do is understand the process in enough detail to begin developing. Then the question arises, how can we give developers a deep understanding of the process?
Consider it. Your RPA developers are your new analysts. You will conduct observation exercises with subject matter experts (SMEs), understand the business rules, and work with the SMEs to decide which scenarios offer the most added value. As part of this model, developers have the opportunity to identify and solve technical challenges at an early stage and to build relationships with the company.
Any process documentation created is carried out in parallel with development and serves as a reference document that can be used as soon as the process is active. This model does not use a design document to inform the solution, nor is one used to lock the scope.
The goal is to come up with a solution that you can quickly put in front of SMEs, get feedback, and repeat every few days.
There’s another fundamental element of your operating model that needs to be in place for this to work: people. You need developers with the right soft skills who are willing to build good relationships with your customers and discover process information through conversation rather than relying on documentation.
3. Work with the customer and create a culture of trust
It’s difficult to convey a culture of collaboration. Not least because the culture is influenced by so many different factors: leadership behavior, HR practices, management skills and team structures.
In all RPA teams, collaboration between project teams should be vital, and behaviors such as appreciating others, targeting conversations, and actively trying to resolve conflicts should be encouraged.
However, here I saw that most of the organizations excelled. The more difficult culture is that of responsibility within the company and trust within IT.
A proven way to build trust in IT is to work with them and define a set of RPA principles in advance, one of which describes when the company is empowered to approve processes live and when IT is involved should be. Truly agile RPA teams create an environment where the company can be trusted to approve processes live and manage their operational risks. In contrast, IT focuses on managing technical risks. The nice thing about RPA is that there is practically no technical risk.
One way to create accountability within the company is for process owners to take on the role of RPA product managers. Product managers determine which items in the backlog should be delivered first. This conveys a sense of ownership and shows that you are ready to put your customers’ interests first. Product managers also become gatekeepers for new RPA projects and have sole responsibility for approving new processes.
The constant challenge of the model gives automation managers the opportunity to create even more value in their company. However, one could argue that there is a safe option. Stick with what you know about RPA deployment and trust that things will be fine at some point. As the great Charles Kettering once said, if you’ve always done it this way, it’s probably wrong.
Dan Johnson, director and co-founder of AiSpace