The Script of the Episode:

01:01 Tracy’s background
02:25 Move from Automation to Project Management
04:32 First Experience with Agile
06:52 Defining Agile 
09:53 How open are people to the strategy of Agile
13:23 Is there any standard duration for iteration? 
14:43 What are the decision factors in duration for iteration?
17:45 Is the team size one of the criteria for Agile?
19:25 Main benefits of Agile
25:25 Changes within the iteration
33:47 What are the disadvantages of Agile Methodology
41:59 Differences between Traditional and RPA Software Development in Agile 
50:30 Core principles of Agile
52:34 Myths about Agile
57:37 Agile 2.0
01:02:22 DO’s and DON’Ts of Agile

About the Guest: Tracy Dixon is Senior Manager, RPA & Project Manager @ Centric Consulting Miami, Florida + UiPath MVP

Tracy Dixon, UiPath MVP and Senior Manager at Centric Consulting got her Computer Science degree in Information Systems and then started out as a programmer in Visual Basic. Later on she moved into project management. Even then she used to automate things in MS Office just to help herself in project management. Tracy says she can “wear both hats” as a sole technologist and RPA Architecture even though she prefers the second one. 

Tracy’s first experience with Agile dates back to 2004 when she was introduced to scrum philosophy. She explains that the basic philosophy of Agile is the same now as in 2001, however, the knowledge of how to scale it has evolved. E.g. Frameworks how to grow the size did not exist before as well as guide how to handle international teams.

Agile is different from waterfall and scrum (which is a flavor of Agile). There are other flavors that you usually don’t hear often: extreme programming, feature-driven development. In the old style of software development, people tend to sit and think about things in advance all at once. In Agile philosophy you do that in cycles, so you do not have to think through everything in advance. The customer can check if you are on the right track, give you some feedback which you incorporate, do little more, and then take another cycle. It’s still ok to create deadlines as there still are limits (misconception about no limits). Agile methodology can be a real advantage if the trust is put into team, but can be a disadvantage if there is no trust.

Agile enables you to act faster. Iteration typically takes from 1 to 4 weeks as the idea is that you are getting the feedback quickly. Project itself might not necessarily be faster but you will get higher value. As Tracy says the idea is that “You fail earlier”. The duration of iteration depends on the team culture and what can be produced in a week. The goal each time is to have working software where you can demonstrate something to the customer or better said the shortest cycle in which you can have fully functional features for the customer. Team should be deciding on the duration as it is not something for the managers to decide. Team in Agile is relatively small and typically consists of less than 10 people. “You want to keep it to small teams. Size is not a 100% hard rule but it is advised to keep it small” according to Tracy. 

When it comes to changes within the iteration – those are limited. If any changes are needed they are added to the backlog for the next time, next iteration. If you realize that you cannot complete a step of the iteration as was intended – you can remove certain steps and replace them with other items from the backlog. Keep in mind that you should also reserve time for bugs fixing in the iteration (more time when coming to an end of the product). Also finishing the iteration earlier is favored as you can then play with the product and explore it – or you can also devote a full iteration to this. 

Agile Methodology Benefits

1. Flexibility
2. Adaptability (change is expected and welcomed)
3. Reprioritization (customer identifies what is most important to work on)
4. Problem identification comes earlier (compared to waterfall)
5. Customer can see the product early on 

Agile Methodology Disadvantages / Challenges

1. Takes training (not one-shot type of thing)
2. Ongoing learning (not just Agile 101)
3. Leadership alignment needed
4. Can be difficult to scale 
5. Not planning in advance (can be uncomfortable)
6. Team working without management directions (can be uncomfortable)

For Agile in RPA, the requirements are very specific. Set of instructions has to be very exact (so the robots can perform the exact steps as humans would). That makes it difficult to have less documentation. 

Core principles of Agile – http://agilemanifesto.org/

1. Individuals and interactions over processes and tools.
2. Working software over comprehensive documentation.
3. Customer collaboration over contract negotiation. 
4. Responding to change over following a plan.

Myths about Agile

1. Agile projects are faster (NO! But the end result = higher value).
2. Agile projects do not need any documentation (NO! Requirements are still needed).
3. Agile cannot really scale (NO! Whole departments or even companies can become Agile).
4. Agile is an easy undisciplined approach 

Tracy thinks that in the future (Agile 2.0.), focus on value will continue as “value is the name of the game”. Organizational change management is essential in RPA. Companies often forget to focus on communication between employees and departments. Tracy hopes that the “barrier of entry to be a little less (scary)” in the future.

5 DO’s while using Agile

1. Always keep the focus on VALUE on the customer.
2. Empower your Agile Team.
3. Senior Leadership needs to support Agile.
4. Plan to improve continuously (training is not a one time thing).
5. Allow the team to experiment and fail fast. 

5 DON’Ts in Agile

1. Team cannot be made only from IT (business & IT collaboration needed).
2. Don’t start with a huge team.
3. You cannot expect the whole team to understand everything after first training.
4. Don’t assume Agile means Agile if you call meeting a Scrum (focus on core values).
5. Never prevent teams from experimenting.