Implementation
Also, refer to Building RPA skillset.
Agile approach in automation
As agile practitioners, we firmly believe that RPA an ideal candidate to implement using an agile approach.
In this article, we will share our approach. As it is based on the previous experience we have completed, it isn’t exactly the same we followed at that time, as we have learned some things as we built them. However, this approach is definitely the one I am using right now and as I learn more it will be adjusted accordingly.
Build agile team
The team consists of:
- Business Analyst, ideally with some previous experience in Lean
- Robot Developer
- Product Owner
- Subject Matter Experts
- Agile Facilitator/Scrum Master
The ideal size of the team should not exceed seven people, so we would not have to spend too much time on management issues within bigger teams.
Business Analyst and Robot Developer usually is a full-time role throughout the implementation project.
Product owner, Subject Matter experts, and Agile Facilitator can be part-time roles.
The Agile Facilitator role is crucial as of a person who helps the team to structure the work in the way it can be gradually deployed in the business and get feedback as soon as possible.
Mapping and reviewing of process
- High-Level mapping of the process
- Low-Level mapping of the process
- Reviewing the process and identifying non-value added activities
This is an indispensable step in a robot implementation. All decision points have to be identified as well as all exceptions to the process and a list of possible risks.
In this step, we think about the data used by the robot. It might be a good idea to prepare all data before the robot starting to perform actions, so it might do them particularly faster than a human person. It also might be of value to think about some activities we are doing that might be not as beneficial to the business. For example, sometimes one might do actions in order to decide what to do next – send SMS, email, or do something else.
It makes sense when a person is doing these activities, so they can save their time later, but the robot can perform all of them at once, so this particular step might be irrelevant. Having said that, it is important not to try to re-engineer the whole process as it will be very difficult to automate it straight after.
The manual performing of the process for some time before automation is crucial as only these guys, who did manual work, can provide real insights about pitfalls and workarounds happening in BAU activities. We fell into this trap when we created a shiny new business process and it was incredibly challenging to automate this new process thereafter. Eventually, it took much longer to automate when if it were an existing manual process.
This step usually takes 8 hours (2 slots of 4 hours or 4 slots of 2 hours).
Creating robot journey map
During this step, we are building a User Journey Map for our robot and identifying particular activities for each step of its journey.
I would suggest using a tool such as Stories On Board or just a simple board on the wall to facilitate this story mapping exercise. However, if you are using a physical board, make sure that it will be with the team for the whole course of the project as you need to refer to it each and every day.
We map the main steps of the robot across the top of the board and then create a particular User Story to cover all the activities within the Steps.
Release planning
Here, we are starting to apply our agile principles to implementing RPA. During this step, we are splitting our implementation into releases. It is beneficial to use the knowledge acquisition curve approach.
The main idea of this curve is that we split our implementation into three phases. During the first phase, we are willing to learn about the process we build and about our proposed solution. This phase is very important to mitigate the highest risks we have in our project and to check our assumptions about the robot to be able to perform a particular task. For example, we are assuming that a robot can interact with one of our internal systems, but we never built it before. In this case, during the first phase, we are building that piece to check if it’s feasible, how fast we can train robot for that system and what pitfalls we might fall into.
A similar approach might be used to external dependencies. For example, if we are relying on an external website to provide us with info, it’s a good candidate to check during this first phase. The duration of the first phase is usually one week and might be a bit longer only for a real difficult process or for an absolutely new area of automation.
After we mitigated the main risks and proved our assumptions, we are ready to deliver business value – we are doing this in the second phase. All meat and bones of our robot are going to be completed during this phase. This phase should also include the deployment of our robot into production under very strict supervising. We usually split the second phase into a few one-week iterations, each of them ending up with the end-to-end robot developed, tested, and ready for deployment into production.
After we build main robot functionality, we are entering into the third phase where we are building its final parts, such as additional controls, optimization of its speed, and additional protections for unusual situations. It is not going to deliver much business value, but it is important to future maintenance of the robot and its robustness. During this phase, we also develop training and maintaining documentation to hand over for our support and BAU teams.
Developing bots
- Iteration planning
- Recording user steps per each activity
- Daily stand-ups
- Robot training
- Robot testing
- SMEs acceptance
- Iteration demo
- Iteration retro
The robot development is an iterative process. The cycle starts from iteration planning and finishes with iteration retro and then looping again until all the development phases will be completed.
Iteration planning
Each iteration we are having a planning session to define what particular User Stories we are going to release and in what order, so we can identify if there are any dependencies we need to address earlier in the iteration. The rule of thumb is to get the end-to-end process done and dusted, so first releases should cover the whole horizontal row of our Robot Journey map.
In the robot development, User Stories are roughly of the same size, so we are not estimating them. However, if one of the Stories looks particularly big or opaque for us, we are splitting it into a few.
Recording user steps per each activity
Per each activity in the low-level process map, we want to have a better idea of particular fields we are filling. We are recording all steps using the free Windows PSR (Problem Step Recorder) tool and then edit them if needed. That helps us to provide all the necessary information to Robot Developer and get that job done faster.
Daily stand-ups
Daily stand-ups to review the progress and resolve issues are beneficial for the team. As we usually aim to complete at least one activity per developer per day, if that hasn’t happened we can discuss difficulties we have and what we can do to resolve these impediments.
Robot training
This step is dedicated to training or developing a robot. Developing of one activity usually takes up to four hours and involves creating a draft robot, improving it to handle many similar cases, embedding protections in place, and then applying it into the testing environment.
Robot testing
Testing might be slightly different from the usual software development as we might not be able to generate test data for some particular cases. If this is the case, then Message Boxes are helpful. They describe the robot’s next action and thinking, so SME can judge if this is the right way of doing things or not.
SMEs acceptance
This step represents acceptance of the particular activity by Subject Matter Experts. It is usually done through a 1:1 session between Robot Developer and SME where they run a robot in a “guiding” mode and check if the robot reasoning is correct. The “guiding” mode is the mode when the robot put Message Box on each of its steps describing what input data it is using and what its thinking is about.
Iteration demo
This step represents a session in which we show our robot to the stakeholders and agree on the release completeness. That helps us to get feedback from the main involved parties and be ready for our next release.
Iteration retro
Each iteration we reflect on the results of the release and adapt our process accordingly. As RPA is still quite a new concept there are heaps of nuances needed to be taken into account, hence it is a rewarding field to adopt this technique.
Deploying solution
During this step we are moving our robot into the production environment, provide it with the access needed and train our maintenance and BAU teams to handle it. We are using a gradual approach in the deployment, i.e. during the first two weeks after deployment, it has a peer who supervises its daily activities and can get control in their hands if needed. During this period, the robot uses the “guiding” approach. Then for the next four weeks, we are switching the robot into daily control deployment when during the day the robot performs its actions without supervision, logging all the steps into its log file. At the end of the day, the supervisor monitors this file as well as controls we have in place and makes a decision if the robot performed according to the plan.
On the higher level, it also might be beneficial to have a Project Steering Committee that helps the team with resolving external issues that the team might not be able to cope with, such as a request for additional resources for other teams involved, communication with the company C-level, negotiation with external providers, and so on.
Try it, use it, challenge it as this is not set in stone and we are only on our early steps of that incredibly interesting journey.
Development tracking
Begin tracking and be consistent
Once you've entered your information into your tracking system, and your project is underway, it's time to begin the tracking process. It's not enough to determine the requirements, measurements, and methods for tracking. You need to actually do it. Be sure if you're using software that you're updating the software every day, at the very least. If you're using Excel or another spreadsheet program to track progress on your milestones, be consistent. Do not start entering items in using one type of measurement and then enter other items in using the metrics your team gathers.
Development tracking template
Download the development tracking template.
- See Status on the first sheet of the Client Tracker template.
- The second sheet is Weekly monitor.
- The third is Overall RPA Transition HLE.
- The fourth is Risk & Issue Lo.
Whether you're conducting retrospectives as a function of the ongoing development process or a postmortem at the end of a major project or as a part of an incident response, there are some best practices you should follow.
Retrospective suggestions
No blame allowed
Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.
Continuous improvement
A retrospective or postmortem in any practice is about learning from the historical record. Keanini stresses, "The most important thing to ask is if the telemetry and findings are complete and how we can prepare for the next retrospective or postmortem with better telemetry and visibility to the processes and domain of interest." Keanini also points out that you can't install the monitoring of an event post-incident, so it's important to continuously improve the fidelity of your telemetry to ensure you're capturing the right metrics and information in the right way to provide maximum value.
Learn from history
Lucas Welch, director of communications at Chef, describes how Chef employs retrospectives and post-mortems with an emphasis on using the lessons as a learning experience to prevent similar issues in the future. "We have a postmortem write-up, with the timeline, root cause, and corrective actions published in a private repository. Then, we schedule an internal post-mortem meeting, where the incident leader for the problem discusses with others who were involved in what happened, why, and how to prevent the same thing from happening. This is a learning experience for everyone, and these meetings are conducted in a blameless manner. For any production incident that could impact our users, we publish a public blog detailing the incident and resolution, as well as a forum for feedback."
Take action
Welch says that Chef conducts retrospectives or post-mortems with two important guidelines. First, the company doesn't focus on past events from a perspective of "could've" or "should've." Second, all follow-up action items are assigned to a team or individual before the end of the meeting. "If the item cannot be a top priority leaving the meeting, we don't make it a follow-up item."
Analyzing past performance and identifying the root causes of issues has always been valuable for organizations. In the rapid pace, the retrospective and postmortem are more crucial than ever. Many projects have no clear end, and it's important for organizations to continuously learn from mistakes and adapt in real time to ensure the same problems aren't needlessly repeated.