I’m not an experienced Agile professional. I would, however, still like to share with you our foray into Robotic Process Automation (RPA) & how we used Agile to deliver an RPA Pilot and prove its viability. I will explain why Agile was a great approach for exploring the potential benefits of a relatively new technology like RPA, and how it changed our cultural perceptions about tool selection, delivery, and business engagement.

1.     Introduction

I have been leading IT teams for over 20 years.  I am PMP certified and have managed a large number of IT projects and programs. For many of the projects I’ve managed, I have seen the value of iterative development, but I had never really embraced the tenets of Agile.

In October 2016, I attended a Scrum course, wrote the test, and received my SCRUM Master certification. Within weeks, I started a new job. It was a contract position, but this time it was very different. For the first time in my career I was hired into the business, not IT. So much for using my SCRUM Masters certification…or so I thought.

I am currently managing a group of wonderful, technically savvy individuals, whose responsibility is to help improve and optimize the business. The business is Energy, Trading and Marketing. My team comes from finance, economics and IT backgrounds. They naturally gravitate towards technology, but they are ultimately business focused, and use technology merely as a tool to solve difficult business problems. I believe individuals like these should be imbedded more and more in business, not IT, and their skills should be leveraged accordingly. We did just that, with RPA.

It is also important to note that we have a very strong and supportive leadership team who has tasked us to challenge ourselves, think beyond our current technologies, and look for true game changing approaches. They encourage us to dig deeply into our business, work with IT, and investigate the new and cutting edge disruptive technologies that will enable cost savings, revenue generation, and potentially change how we think about our business. To accelerate doing this, we delivered a Digital Strategy, in June of last year (2017), with a focus on Cloud, Data & Analytics, and Robotic Process Automation or RPA. The Cloud and Data & Analytics portion of the digital strategy were well underway by the summer of 2017. RPA…not so much, but we all knew the potential was big.

2.     Background

I have been working for TransAlta for 1.5 years. My role is Manager of Business Process and Technology Optimization within the Energy Trading and Marketing business unit. We call ourselves BTO. The atmosphere within a commodity trading business is highly demanding, fast paced, intense, and fun. As I’ve already mentioned, my team is very technical with finance or IT backgrounds. What is truly a wonder to me is that the leadership and my team have pushed the limits of IT expectations beyond anything I ever experienced in IT. The experience I am writing about is a prime example. Remember as you read this…this is a business led initiative.

3.     The RPA Story

Everyone understands automation; taking a business process and hand it over to IT to automate.  RPA is different. It is a virtual software robot that is doing basic tasks across applications just as a human would do. RPA is automating high-volume, repeatable tasks, that cross multiple systems. RPA is possible where you have people rekeying data between systems. Investment in RPA is relatively low, and the payback is very high, or so they say. One of its key strengths is that once installed, the business can teach the system the processes they want to automate, support those automated processes, and ultimately reduce their dependency on IT.

Our leadership within Energy Trading and Marketing was very excited about the prospects of RPA. We brought in experts to challenge and validate our assumptions. We spoke to companies who had already invested in RPA. We attended conferences, investigated RPA tools through Gartner and Forrester Research. We had brainstorming sessions with the business areas, and identified many processes, specifically back-office processes which would be great candidates for automation, and provide a potentially large return on our investment. Now it was time to prove that this could work.

3.1       Our Approach

Through all this investigation and research, we came to the conclusion that we knew very little about the tools and how to estimate our effort. As result my team and I decided our approach would be Agile. We would do a 6 to 8-week pilot made up of 1-week sprints. At the end of each sprint we would reassess our progress and effort. We would adjust our estimates based on our learnings. Our deliverables would include:

• Tool selection
• RPA Infrastructure setup
• Training
• Automation of 2 key processes
• Learnings delivered to our sponsors
• Approval to move forward with an RPA Program or stop

3.2       Our Principles

We delivered a Business Case and Charter. The executive leadership expected low cost and results within weeks. To accomplish this, we adopted the following principles to guide us through our RPA Journey:

1. Limited upfront investment – We did this by using a trial software license (free), and doing a short (6 to 8-week) pilot, to prove we could automate 2 candidate business processes.
2. Business led, managed and orchestrated – We wanted the business to manage, build and support the RPA processes. This would be my team. They knew all the business processes very well which would in turn reduce analysis time. We would partner with IT and IT’s role would be infrastructure and application setup, support, and enablement.
3. Learn from other’s experiences – hire an expert – We engaged a consultant to guide us through our RPA journey. We had a local RPA Practice Lead located in Calgary and we were impressed with their credentials.
4. Move fast – This meant, no Supply Chain RFI or RFP processes to select a tool. We picked a best of breed RPA leader based on Gartner and Forrester research.
5. Learn fast – My team would automate portions of processes in one-week sprints. The business owner would be engaged constantly to ensure the devilish details were considered. Accomplishments would be reviewed every week with the business owner.
6. Fail fast – We would meet every day to discuss progress and understand obstacles. This was new for us. We knew that there would be obstacles; whether it be the tool or the infrastructure.  We wanted nothing to fester, no surprises. If there was a showstopper, the earlier we knew, the better – “fail early and often”.  Leadership agreed that if we needed to pull the plug we could, although I think everyone would have been greatly disappointed if we did; there was just so much excitement and possibility. I believe an Agile principle is to build projects around motivated individuals. With RPA this couldn’t have been easier.
7. Cloud technology could be leveraged for the RPA – We wanted to prove that IT could set-up and configure the RPA infrastructure on the cloud within days, and that it could be supported and tweaked easily as we went along.

3.3       Setting the Foundation to Deliver Iteratively (Sept – Oct 2017)

And so, it began… The principles seemed to fit nicely with Agile. The team, as well as leadership, were interested in learning and using Agile, but we did not immediately start doing one-week sprints. There were things that needed to happen before we could start:

1. First, we selected the RPA tool and acquired the trial license. Our choice as mentioned earlier was based on a few key criteria; we wanted a cost-effective leader in the RPA space, and we wanted software that could be managed and owned by the business. There were two RPA contenders that led the pack according to Gartner, Forrester, and our RPA consultant. Their licensing model was very similar, their cost per robot was similar, and in both cases each robot license covered 24 hours of processing time. From our perspective, Option 1 required deeper development skills, whereas option 2, Blue Prism had a business workflow GUI, enabling what we thought would be better business engagement and understanding. We picked Blue Prism. No RFI, no RFP…we just picked it. We felt the time and money to go through supply chain to pick a tool for a pilot seemed cost prohibitive. We felt if we could do the pilot quickly, including tool selection, our turn-around time in learnings and results would outweigh a lengthy tool assessment process. IT and Supply Chain still have issues with this approach because it did not fit within their processes, but from a cost perspective it seemed to be the right approach to us.

In hindsight, I would do the same again. We did our research through Gartner and Forrester as well as received guidance from our outside consultant. We selected a “best of breed” solution or a “Leader” as described by Gartner and Forrester. We may have just gotten lucky, but we believe we chose well. Also keep in mind, we are talking about a 45k investment. We would have spent that much just selecting a tool had we gone through supply chain. We would have also spent the last quarter of 2017 in a selection process and would not be where we are today.

1. Next, we finalized our selection of the two candidate automation processes with the help of an RPA consultant.  We already had a pretty good idea of the processes we wanted to automate, but the consultant validated those processes by putting them through their Process Assessment Tool, and helped to confirm the automation effort estimate as well as potential FTE (full time equivalent) savings.
2. Then, we built our project team:
   1. Two business people from the Business Optimization team to each automate a process – I will call them the Automaters going forward. We expected they would spend 80% of their time on the following processes:

1. One Invoicing process
2. One Trade Confirmation process

• Two business owners to review the automation progress (Approx. 2 hours per week)

1. 1. Two IT people:

1. One Cloud Architect to help build the RPA environment
2. One IT Business Analyst to capture the solution design, configure the software, document the configuration, and run point with IT on any infrastructure/configuration issues we ran into

1. 1. RPA Consultant (4 hours per week during the sprints) to guide us through issues with automation, and help with governance and best practices
2. At the same time, IT built the RPA Environment on the cloud and ensured Robot access to the users for training
3. Finally, the RPA consultant trained 4 people in our offices over 3 days. The trainees included, the Business Automaters, IT BA, and 3rd Business person as backup.

3.4       Sprint 1 – October 9^th to 13^th, 2017:

Our first stand-up meeting or scrum was held on October 9th. This was really a working design session.  We focused on 3 areas:

1. Process 1 – Counterparty Invoicing Process
2. Process 2 – Broker Confirmation Process
3. RPA Tool (Blue Prism) Configuration and Setup

We white-boarded the 2 processes at a high-level and then broke the process down into workable pieces that could be completed in hours’ vs weeks. Each piece of work was entered as a task card and placed in the “To Do” section of a makeshift Kanban board in our meeting room. Counterparty Invoicing tasks used green cards, and Broker Confirmation Process tasks used pink cards.

As we worked through and discussed these processes, it became very clear that the RPA tool would require further configuration. It would require access to various mailboxes and systems. Each configuration item was also entered onto yellow cards and placed in the “To Do” section of the Kanban board. We discussed priorities, dependencies and order of execution. The team then selected the cards they agreed to complete by the end of the first week/sprint. The different colored cards helped to simplify communication and might have even enabled some healthy competition.

Every morning we had a daily stand-up to discuss progress and pitfalls. Along with my day-to-day business management duties, I managed this project. This included escalating issues, removing roadblocks, tracking and reporting on results, and motivating the team. I never called myself a Scrum Master as that role or that jargon is not familiar to my team or my business unit. Each team member focused on completing their tasks and showing results by the end of the week.

By the end of the first week, 13 cards were complete, but there just wasn’t enough demonstrable material to show our progress to our stakeholders. What we discovered is there is process optimization work required before the actual automation can begin. As a result, the early cards were for process cleanup. In one case we worked with external counterparties to deliver results to us in .xls instead of .pdf. This work was not demonstrable to the user, but had to done nonetheless. The business owners were engaged on nearly a daily basis, but we did not have a retrospective until the end of sprint 2. The users were very supportive of our progress; to demonstrate something in 2 weeks was very impressive to them.

3.5       Sprint 2 – October 16^th to 20^th, 2017:

By the beginning of sprint 2, the team had fallen into stride. Cards would be adjusted, added, removed, split out into smaller tasks as each person learned more about the effort required and the RPA tool.

We were finding the Kanban board in our meeting room a bit tedious so we investigated some free Agile Project Management/Collaboration tools. My husband used Trello for his projects and liked its simplicity. We set up accounts on the free version of Trello, and began moving all of our cards into Trello and abandoned the Kanban board on the wall.

By the end of the second week we held our first retrospective with all stakeholders including business owners and sponsors. We demonstrated very successfully a portion of the robotic process in action. We received a very positive response and the excitement for the potential of RPA grew.

3.6      Sprint 3 & 4 – October 23^rd to November 3^rd, 2017:

Progress continued through sprint 3 without major issues, but something was missing. I felt a little lost as a project manager. I could see progress in the number of cards that we were delivering, but we weren’t using story points or estimates. This bothered me. It felt a little like working blind. Did we have the major work and technical hurdles behind us? Or were we in for a big hit/roadblock in the future? By the 3rd week, the team was quite comfortable with the effort involved with automating using the RPA tool. There was no reason that estimating and tracking actuals couldn’t start now.

We downloaded Burn-down for Trello and started to include estimates (hrs.) for each card. We went back to the completed cards and populated those with actual effort (hrs.). I know within Agile, story points are used but we found it easier wrapping our heads around hourly estimates. I liked this approach because you could not only see the expected hours in front of us, but also the actual hours we burned behind us. Is this “Agile”? I don’t know, but for me actual hours made it easy to see that the two Automaters, who were expected to spend 80% of their time on automating were only spending 50% of their time. The guys had other business-related tasks to attend to. I could not change this fact, but what I could do was manage expectations, prioritize and plan accordingly knowing they were only available 50% going forward. As result we completed the pilot in 10 sprints instead of the 6 to 8 we had originally planned.

3.7      Sprint 5 to 8 – November 6^th to December 3^rd, 2016:

I had a previously booked a 3-week vacation to South East Asia, leaving November 4th, but by Sprint 5 the team was truly self-organizing so the risk to the project was minimal. We knew this because we were already seeing positive outcomes, and the team had found their stride. They knew very clearly what their objectives were, and how much time they had to complete them. They knew they needed to prove to not just our Energy Trading and Marketing organization, but by now the entire corporation, the potential benefits of automating processes through RPA. They understood this as potential game changer in our organization and as result took their tasks very seriously.

One team member took on the role of “Scrum Master” although we referred to him as the project leader. He continued to hold the daily stand-ups and ensured progress was made, and stakeholders and business owners were informed and engaged. He also demonstrated progress to many interested others including the CEO.

As result of the CEO’s engagement, there is an immense amount of excitement and anticipation across the organization. They are patiently waiting for us to complete the first phase of the RPA Program, which will end in June.

3.8       Pilot Closure and Program Planning

Upon my return, there was clear support for moving forward with an RPA program. We began work on an RPA Roadmap for 2018 along with detailed planning and the RPA tool procurement.

The RPA Automation Program was launched in January. The team is intact, and we’ve trained five others, although only 3 will be doing automation for this program. We are now doing 2-week sprints, and we hope to deliver 14 processes by June 30^th. We expect to save the equivalent of 2 full-time resources in time savings by June 30th. So far, we are on track in savings but behind in delivery. Maybe that means we will deliver less, but realize the same savings… but that is another story.

4.     Learnings

4.1       The good:

• Short sprints and manageable tasks made it much easier to measure results and plan for better outcomes in the next iteration.
• The unknown subject matter like RPA technology was a perfect candidate for Agile – it enabled us to adjust as we went along – we got better with each iteration.
• Making progress visible to the team – the Kanban motivates the team because they can easily see progress (I can demonstrate our Kanban in Trello).
• The benefits of burn-downs and story points (estimates for work to do, and actuals for work completed). This was very effective in making visible our velocity.
• Don’t underestimate the power of self-organizing, motivated teams. What they can accomplish is incredible, and the sense of ownership and accountability is great for morale.
• Business Owners and all Stakeholders continuously engaged. This might have happened anyway; simply because of the cool factor associated with the tool.

4.2       The Bad:

• We did not engage IT Security early enough in this Pilot. IT was involved so we in the business assumed Security was involved as well, but we were wrong. New technology such as RPA really needs to consider IT Security. Get as much lead time as possible so you are not figuring it out after the fact.
• Within our organization, typical POC/Pilots do not have security resources assigned. My suggestion is anything groundbreaking, like a “digital workforce” or onboarding a “digital worker” or “bot” should always include security very early on. This was a significant learning, as the time required to get everything in place is more than one would expect.
• For the program, we will spend more time up front on the process design sessions, allowing a couple of hours per process dependent on process size. We did this hurriedly within our first stand-up meetings on a whiteboard, creating our task cards from that. I would like to see us use a Smart Board, capture the process and its components, and break them down accordingly. The results of the Smart Board session can be saved as project documentation and referenced as required.
• We really needed a focused Solutions Architect on the project team. I think this is especially true for new technology. Someone to work through what it means to onboard a “digital workforce”, and all of the security considerations that go with it. We will have this for the Program, but I think working through this sooner would have helped us to resolve technical hurdles sooner.

5.     Acknowledgements

This experience report and my opportunity to deliver this to you is because I work for an organization that thinks differently about embracing innovation to create business value:

• Brian Gillis, Managing Director of Risk, who provides constant support, challenges me when necessary, and provides me the runway and the trust to try new approaches to delivery
• Jennifer Peirce, SVP of Energy Marketing, who is constantly challenging us to push the boundaries of the status quo and make a marked positive difference within our organization
• Robin Wylie, who has become our in-house RPA expert and business expert. He is now leading us through our RPA journey, and is embracing Agile all the way
• Benoit Legare, another home-grown RPA expert and business expert, who challenges conventional wisdom and takes on every challenge with a dose of skepticism, always keeping us honest.

It’s also important to look beyond our own organization for training and insights. For that I would like to acknowledge Mike Miller and Andrei Savu at Ernst & Young for providing RPA Training to my team, and sharing in RPA best practices.

And finally, I would like to thank Avraham Poupko, my assigned Agile XP Experience Report shepherd for all his time and help in editing and helping me to shape this report into what it is today.