Once your automation program has "in orbit" (pun entirely intended) and ready to scale to that next level of your automation program growth. In this special Hyperscaling The Automation Journey series of #AAillustrates, we're diving into the proficiencies of automation programs that grow and scale - with our third session in the series: Scaling with Citizen Development.

If you missed one of our previous sessions, we've got them all on the Hyperscaling The Automation Journey landing page - so be sure to check them out for additional content on growing and scaling your CoE. This session's focus is squarely looking at the experience of inviting business users (presumably with 0 background in computer science or information technology) to contribute to the automation program within your organization.

Why Citizen Development?

There's a couple key reasons why organizations will reach for the Citizen Development lever which looking to scale their automation program:

• Enabling Function for Business Units

  • Citizen Developers enable a business unit to identify, prioritize, and develop their own automations, without needing to wait for central CoE resources to do the development, or worry abut how the ROI of their identified opportunity stacks up vs the ROI opportunities of other functional areas. Citizen Development enables a business unit to be the controllers of their own destiny when it comes to automation.

  • Note that this doesn't mean that have to be all in Citizen Development or all in Central CoE Development - they can find a balance between the two - where higher risk/most complex use cases may go to Central CoE Development while lower risk, lower complexity use cases are done "in house" with Citizen Developers within the business unit.

• Teach Users to Build Bots or Teach Developers to Understand Business Processes?

  • There's a saying (I think its attributed to Mihir Shukla, but Micah steals it and uses it a lot too) - "Those who are closest to the problem, can be most insightful to its solution". Said to mean that with a low complexity automation tool (Automation 360), it may be easiest to have business users learn to build out automations for the business processes they are most familiar with than to try to communicate the business processes to a traditional developer in order to develop the automation.

• Automation Development...At Scale

  • A centralized team of developers can only take on so many use cases per quarter/year. This means that the "queue" for your use case to be automated may be way out. For organizations that want to move more quickly in their automation journey, federating out these development capabilities means that more bots can be built in less time*.

    • *Note that this doesn't mean your Control Room turns into the Wild West of automations - where anything goes. A CoE is responsible for the governance of automations and ensuring that frameworks, templates, code checks, and guardrails are in place for ensuring that all production automations are of acceptable quality.

  • This flies in the face of most "platform/program owners" at large organizations. Instead of the "If you want to use this, you have to come through me, I own it, my team does all the dev, etc." approach that most leaders take within an organization to "grow their footprint" - a federated development approach is the antithesis of a "grow the size of my team at all costs" program owner.

    • Federated Automation Programs set the standards that are expected for development, deployment, maintenance, and testing - and give various business units the space to solve their own problems. This isn't limited exclusively to Citizen Development - but can include some flavor of federated developers on other teams (think IT ops, QA, etc) mixed with business users who are creating their own automations.

Getting Started with a Citizen Development Program

First, it's important to mention that your Automation Program/CoE must be at a certain point of maturity before undertaking a Citizen Developer initiative.

Standards like how you do your testing, change requests, documentation, development templates/frameworks, support, etc all need to be in-place and mature before diving in with Citizen Devs.

Why? Because they will need structure and guidance in these areas - and if your end goal is sustainable, reliable automations that can be easily supported and maintained - you'll need these assets in place.

Start With a Pilot

With that preface out of the way, the best way to introduce Citizen Development is with a small pilot. Through your automation program evangelism efforts, you've likely identified some motivated individuals who are "change agents" for automation at your organization. Float the idea with some of these motivated individuals to see if they might be interested in taking part in a pilot to introduce Citizen Development.

Get Your License

Nope, this isn't me hucking Bot Creator licenses. Think of this similar to when you got your driver's license. You took some classes, you passed a written test, and you drove X number of hours with a licensed driver before finally taking a driving test with a testing authority.

Set up a similar program for your Citizen Developers. Get them started with the freely available training at Automation Anywhere University, set up a plan on how they can work with more experienced developers to get help/feedback, and establish a path for them to eventually be able to develop and submit bots for deployment on their own.

Pick the Right Use Cases

Citizen Development (just like your automation program as a whole) is best started with low risk, low complexity, and low (or higher) ROI use cases. The aim here is for you to test out if Citizen Development program is something that can scale automation in your organization, and the aim for the Citizen Developers themselves is to build some confidence, experience, and momentum. Steer them towards relatively easy use cases or small parts of a much larger process.

Build a Community Of Practice

Learning Something new can be intimidating...especially if its something you view as complex or overwhelming (how technology is viewed by many people). As a CoE leader, consider setting up regular office hours - where Citizen Developers can come and ask questions, listen in to the questions of others, or generally get help with the documentation/testing/release process. This may feel weird at first, but this is a soft skill you'll need to develop in order for Citizen Developers to be successful. This has to be approachable, fun, and a judgment-free zone. Nothing is worse than feeling embarrassed for asking a dumb question when more experienced people laugh or roll eyes. 

Conclusion

Citizen Development can be a great way to involve more people within your organization in your automation program and is a great way to scale your automation initiatives. As mentioned, business users with an intimate knowledge of business processes can be often empowered to build out automations on their own given the appropriate training/time.

As you pilot your Citizen Development program, make note of the things that work vs the things that seem to hinder progress, and continue to scale and rollout the program from there.