In the previous article, we discussed the basics of Agile and some misconceptions. Now I would like to introduce the Agile Iceberg to you.
Why Iceberg you ask? Well, icebergs have an interesting pattern to them – approximately 10% of iceberg is above the surface of water and the rest 90% is submerged. Without getting into the science of Density = Mass / Volume, let’s just say the two parts – visible and submerged – need to stay in balance to keep the iceberg from sinking. I personally found it easy to visualize Agile using this iceberg-balance.
Ok, it looks nice. But what the heck does it mean? And more importantly, what does it mean for an RPA project? Let’s chip away at this iceberg to understand that.
GOALS: What does the organization want?
Faster ROI: RPA project should be be delivered as fast as possible, at as low cost as possible.
Error-free: Solution should be free of errors i.e. First-time-right.
Visibility: In-flight progress and post go-live performance should be easily available at all times.
ENABLERS: What does the organization need to do to achieve the above goals?
(Note that I said organization, not project team)
High Performance Team: There are many definitions of High-performance teams, so I’ll not go into that. But here’s what one really needs –
o Skilled individuals on the platform (i.e. Blue Prism and Connected-RPA)
o Motivated to learn and succeed
o Low churn in the team
o Experienced in the building RPA solutions on the technology stack in your organization (e.g. Web, Java, Mainframe, SAP, Citrix etc.)
If you are just starting in your RPA journey, you have a decision to make – should you build an inhouse capability or should you bring in a partner to jumpstart. The choice is yours, but each choice takes you down a different road.
o Build In-house Team: The team is new to RPA and/or the technology stack. This means the team is learning more and delivering less in early days – not really an enabler for Faster ROI. Forcing the team to deliver faster while they are learning will demotivate them and reduce their productivity. It’s better to run your projects in the Waterfall way in early days to allow the team and business to learn and find their balance. Do periodic checks on the organization maturity and team performance to make sure it is trending in the right direction. When the conditions are right, go Agile.
o Bring in a Partner: Sorry, you still shouldn’t go Agile on Day 1. Remember that you – i.e. your organization – is just starting with RPA. Also remember, that Agile is a way of thinking and the developers, business users, management can’t start thinking Agile overnight. If your organization is not already setup for Agile or if your organization is new to RPA, it’s probably best to run things the Waterfall way. If you still choose to go Agile, best to set everyone’s expectations that mistakes will happen and they should embrace them to avoid heartache. Although travelling on this road will be considerably faster than building a team in-house.
Co-located Teams: Simply put, you would want business and developers to sit together. This helps in avoiding crucial time lost in the back-and-forth communications and reduces the need for extensive documentation of requirements. Co-location helps the developers get early feedback and business can fine-tune/change the requirements based on the output they see. Obviously, testing is faster too. If the teams are not co-located, then it will require a strong willingness by two individuals at different locations to pick up the phone and collaborate with each other.
Communication and Transparency: Developers are usually bad at tracking progress, so you need someone (usually a Scrum Master) or something (e.g. JIRA) to do that for them. Get your tracking right, you can drive self-service Reporting.
Open to Learn: There is lot of learning that developers, business, management and others have to be ready for. The learning could be technical, process-oriented or people-related. All of this comes together at some point to drive success.
Good Design: The focus here is your Agile operating model. Just-enough amount of oversight coupled with efficient execution of idea-to-implementation is crucial. There is no secret sauce here – you need to try a few combinations to see what works best for the people involved.
Appetite to Fail: Project failure is a real possibility whether you do Waterfall or Scrum (using Scrum for correct comparison and as a proxy for Agile). Waterfall projects tend to take too long to fail. Agile projects tend to fail faster, or at-least warn you sooner. Nonetheless, organizations must have an appetite to fail. Sooner the project fails, the better it is – this avoids more money being spent on it. More importantly, organization must learn from the failures and move on. The mantra here is Fail Fast, Learn Faster.
Nimble to Change: You probably wouldn’t be Agile if you weren’t open to requirement changes. But this needs a little more discussion for an RPA project. Theoretically, requirements are unclear or changing in an Agile project, and that’s because the final product doesn’t yet exist, and the business is discovering it as they go along while staying in sync with the product vision.
RPA however is commonly used to automate a business process that already exists. At the very least, you already know what needs to be automated and the project team will obviously figure out how the process needs to be automated. But here’s the interesting question – if you already know the end product, know the scope, and have the right tools, then do you still need Agile methodology like Scrum or XP to run your project? It depends. If your organization is already setup for, say, Scrum (i.e. people, processes and tools are designed for Scrum) then there’s no harm in executing your project as Scrum. If you are setup for Waterfall, just go ahead and do that – nothing wrong with that either. But in both cases, you will have to make iterative tweaks to your model to ensure nothing is falling through the cracks. For example, Blue Prism’s vanilla delivery methodology is a hybrid model – it’s primarily a Waterfall model with iterative Build-Test cycles – with the intent of catching issues sooner than later.
Bottomline is there is rarely a one-size-fits-all model out there. In almost all cases, one has to adapt the vanilla model to suit their organization’s practices and people.
Continuous Improvement: This is quite straightforward, and I’ll not delve this further. One thought I do want to leave you with is that there is Agile doesn’t enforce perfection. So don’t spend too much time in getting everything perfect. Focus on Minimum Viable Agile i.e. what’s the minimum you need to start off, and then keep improving from there as time progresses.
Access to Institutional Memory: It’s no surprise that Process Knowledge is crucial for success of your RPA project, and Identifying, Triaging and Analyzing a process requires a thorough understanding of the business process. For this purpose, the Process Analyst usually relies on Subject Matter Experts (SME), Standard Operating Procedures (SOP) and Metrics to do the analysis. But often, the analysis will pose questions that the SME or SOP cannot answer – e.g. Why is 4-eye check being done at three separate places in the transaction flow? Why is Team 1 doing Steps 1-4 and Team 2 doing Steps 5-10? These questions can become the lynchpins if you intend to re-engineer your process to make it conducive for automation. And the answers are usually with individuals who were around when the process was setup. Needless to say, inability to answer these questions will delay the analysis and the project.
That’s it for now. Thank you for reading. In our next (and final) part we will bring all of this full circle to answer our original premise – should you go Agile for RPA?
Please do share your feedback/critique.
#agile
