By far the biggest factor for return on investment and success of a robotic process automation implementation will be the delivery life cycle. The delivery life cycle lays out the series of steps that take a business process from automation ideation to production. Successful delivery practices select the right process, balancing the effort to build the process with appropriate governance and ensure that the approach adheres to budgetary guardrails. For the long-term sustainability of process automation across an organization, continuous improvement activities of analysing performance, identifying trends, evolving processes and reducing time to value the delivery life cycle will contribute to business agility.
RPA Teams are successful by continuously evolving their delivery life cycle this might be through understanding and balancing the changing needs of their team, the wider business and IT, focusing on agility, adopting lean thinking or continuously learning and experimenting. Robotic process automation establishes the foundation for intelligent automation and connected, complementary technologies that will provide a critical lever for business transformation and change as organisations take an infinite mindset to market challenges.
A typical RPA Delivery life cycle will have the following 5 stages supported by a strong governance model and effective change management:
One of the simplest ways to appraise the performance of the RPA delivery life cycle is to analyse the RPA development time and there have been many initiatives that have contributed to the reduction in cutting this time:
The agile development mindset has made the case for short cycle times and fast feedback, the Extreme Programming practise of Continuous Integration encourages all members of a development team to integrate their work daily, instead of developing features in isolation for days or weeks. The DevOps movement encourages software developers, operations, and everyone involved in delivery to work together – avoiding hand-offs that add delays. Infrastructure-As-Code takes advantage of the cloud ability to rapidly deploy and provision new servers. Aligning all these initiatives together is the practice of continuous delivery: which looks to keep the product in a releasable state, allowing the fast release of features and rapid response to failures.
The objective of the RPA delivery life cycle is, however, not only about how quickly RPA can be delivered (by ensuring high code quality, or providing strong management control, or maximize team productivity) but why develop the particular automated process or feature – what value will this deliver to the business. The RPA delivery life cycle, therefore, is a “Value Stream” with the chosen development methodology forming a critical part of this. Analysing this value stream will help identify bottlenecks and appraise the value in the delivery life cycle.
Organizations are analysing how value flows across their technology delivery processes and seeking a holistic way to connect and measure all end-to-end activities completed for a specific product or service in order to provide great internal and external customer experiences.
A value stream is a series of steps encompassing all the activities undertaken in the delivery cycle from process discovery to automated process operation in order to provide business value. Management of the value stream helps determine the value of the Blue Prism development and delivery efforts and resources. It also helps to improve the flow of value to the organization, while managing and monitoring the automated delivery cycle from end to end.
Value needs to be defined within your organization first. Is it investment ROI? Shareholder profits? Customer experience? Once this value has been defined, can an organization provide visibility into how business value is created and how they can optimize this flow across the business – including their technology delivery teams? Value stream integration is critical for flowing business value from ideation to production, and a core component for scaling Agile and DevOps.
Agile development has been very successful in optimising the Design, Develop and Deploy stages, while DevOps provides a link into the Operations and Maintenance stage. These methodologies have done this by creating velocity, high-quality deliverables, increasing customer gratification, limiting risks, increasing transparency and enabling the agility to respond quickly to feedback. Enterprises have therefore seen dramatic benefits moving from weeks or months to release code to deploying changes on demand.
The steps performed in each of these stages in the value stream will be dedicated to by the selected development methodology. Value stream mapping (VSM) provides us with a structured visualization of the key steps and corresponding data needed to understand and intelligently make improvements that optimize the entire process, not just one section at the expense of another. It will highlight where the value is added, where it’s not, and more importantly, how to improve the delivery life cycle.
The selection criteria and ongoing appraisal of your development methodology for your delivery life cycle shouldn’t only focus on how fast it enables delivery, but how much value can be delivered at speed.
A development methodology is a framework to structure, plan, and control the process of developing. The methodology will divide the development work into phases to build and project management. Most modern development processes are from the Agile family, but there are other methodologies, including waterfall (the original/traditional method), unified process (UP) family, lean development and others.
Typically, Waterfall software development methodology is a sequential model in which each phase is completed in full and followed in a fixed order: whilst Agile software development comprises various approaches to development under which requirements and solutions evolve through the collaborative effort of self-organizing and cross-functional teams and “customers”.
When selecting a development methodology, the decision on which once to adopt is likely to depend on:
- Integration: The software development approach taken by the wider organisation
- Expertise: The Blue Prism partner or internal Centre of Excellence (COE) RPA development knowledge
- Capability: The maturity of the Blue Prism development team
- Advice: The recommendation from Blue Prism on methodologies or practices via a Robotic Operating Model (ROM) assessment or consultation
We will examine popular Blue Prism delivery methodologies, but it is important to understand that there is not a one size fits all. The right delivery methodology for your automation programme is likely a blend of practices that provide a fit with your automation practice, your automation maturity and the wider organization.
This is the traditional method of software development and follows a linear, sequential approach. Each phase represents a distinct activity which will usually need to finish before the next activity begins. There is usually a gate/milestone between each phase, and it is typically:
- Structured as a large project that flows sequentially
- Suitable for projects that clearly define their requirements upfront
- Suited for projects where change is uncommon
Progress in a Waterfall approach is sequential moving through the phases as each preceding phase is completed/verified. This model was a direct result of adapting hardware-oriented development methods (as found in manufacturing and construction industries) in a time when there was no formal model for software development.
Waterfall delivery is not typically used in modern software development, however there are elements that work well with Blue Prism delivery and therefore it is helpful to understand these:
- There is an emphasis on the upfront collection of requirements and design
- The delivery is well planned with timescales and costs agreed upfront
- Not suited to iterative design, but static requirements
The main disadvantage with Waterfall for automation delivery is that it is difficult to adjust the feature-set in the middle of development. This can arise if problems are identified during the process build, for example new functionality requirements or changes to application environments.
Although there are some alignments between Waterfall and automation development, it is not well suited to programmes of work in enterprise implementations. However, for a first time Blue Prism process, pilot or proof of concepts/values then a Waterfall methodology is an excellent choice. Blue Prism basic training promotes iterating build and test cycle phases, with close SME engagement and a validation phase to compensate for changing or new requirements. It also provides guidance on build and exception coverage with an 80/20 rule suggested, and so there is no expectation of 100% delivery of product – So there will be out of scope business exceptions/scenarios.
Therefore, for the first time process builds upfront Waterfall style requirements gathering with Blue Prisms basic training is a recommended starting point for a new RPA COE.
Agile methods are meant to adapt to changing requirements, minimise development costs and provide a quality product. This methodology emphasizes iterative, incremental, and evolutionary development. The Agile development process breaks the product into smaller pieces and integrates them for final testing. It can be implemented in many ways, including Scrum, Kanban, Scrumban, XP, etc. Agile is also derived from Lean thinking that applies “Lean” concepts in the information technology environment.
Agile is a mindset with a set of values and principles. Agile is:
- A way of thinking and acting
- About people, collaboration and interaction
- All about short cycles, iterative and incremental delivery, failing fast, getting feedback, delivering business value to customers early
- About transparency, inspection and adaptation. Agile, however, doesn’t consist of any roles, events or artefacts.
The term “Agile” was coined in 2001 in the Agile Manifesto. The manifesto set out to establish principles to guide a better approach to development. The Agile Manifesto consists of 4 important values and the way to read this is not that the items on the right side have no value anymore, but the Agile movement values the items on the left more.
Complementing the Agile Manifesto, the Agile Alliance defined a set of 12 underlying principles:
Agile is a proven project management methodology that encourages the following key concepts:
- Frequent inspection and adaptation
- A leadership philosophy that encourages teamwork, self-organization, and accountability
- A set of engineering best practices that allow for rapid delivery of high-quality projects
- A business approach that aligns development with customer needs and company goals
These concepts can then be applied to Blue Prism development which will typically include the following stages – Planning, Build & Test, Release & Deploy, Monitor & Operate, but where they differ from the Waterfall approach is that they form a cycle rather than a line.
Agile focuses on keeping the process lean and creating minimum viable products (MVPs) that go through several iterations. Solutions evolve through collaboration between self-organising, cross-functional teams, feedback is gathered and implemented continually, and it is a dynamic process where the team is working towards one goal. Agile development is an umbrella term for a set of methods and practices:
The Waterfall Method’s greatest strengths are its fixed costs and predictability, whilst its most significant weakness is its inflexibility. The Agile Method is extremely flexible and could evolve into a significantly different product than was originally envisioned:
Scrum is a popular process framework used to manage product development and other knowledge work. Scrum is empirical in that it provides a means for teams to establish a hypothesis of how they think something works, try it out, reflect on the experience, and make the appropriate adjustments. Scrum is structured in a way that allows teams to incorporate practices from other frameworks where they make sense for the team’s context.
Teams following scrum are expected to learn and explore the following values:
- Commitment – Team members personally commit to achieving team goals
- Courage – Team members do the right thing and work on tough problems
- Focus – Concentrate on the work identified for the sprint and the goals of the team
- Openness – The team are open about all the work and the challenges the team encounters
- Respect – Team members respect each other to be capable and independent
- The Product Owner manages the product backlog in order to achieve the desired outcome that the team seeks to accomplish and provides clear direction on what to build
- The Scrum Master coaches the development team ensuring that they live agile values and principles whilst following the processes and practices agreed by all. The Scrum Master often leads from a position of influence, often taking a servant-leadership stance.
- The Development Team consists of the people who deliver the product increment inside a Sprint. The main responsibility of the development team is to deliver the increment that delivers value every Sprint.
Sprint – The Sprint is a timebox of one month or less during which the team produces a potentially shippable product increment. A new Sprint of work immediately follows the conclusion of the previous Sprint and the start date and end date of Sprint are fixed.
Sprint Planning – A team starts a Sprint with a discussion to determine which items from the product backlog they will work on during that Sprint. The result of Sprint Planning is the Sprint Backlog. Sprint Planning typically occurs in two parts. In the first part, the product owner and the rest of the team agree on which product backlog items will be included in the Sprint. In the Second Part, the team determines how they will successfully deliver the identified product backlog items as part of the potentially shippable product increment and these items identified make up the Sprint Backlog. Once the team and product owner establish the scope of the Sprint no more items can be added to the Sprint Backlog. This protects the team from scope changes within that Sprint.
Daily Scrum – Is a short (usually limited to 15 minutes) discussion where the team coordinates their activities for the following day. The Daily Scrum is not intended to be a status reporting meeting or a problem-solving discussion.
Sprint Review – At the end of the Sprint, the entire team (including product owner) reviews the results of the sprint with stakeholders of the product. The purpose of this discussion is to discuss, demonstrate, and potentially give the stakeholders a chance to use, the increment in order to get feedback. The Sprint Review is not intended to provide a status report. Feedback from the sprint review gets placed into the Product Backlog for future consideration.
Sprint Retrospective – At the end of the Sprint following the sprint review the team (including product owner) should reflect upon how things went during the previous sprint and identify adjustments they could make going forward. The result of this retrospective is at least one action item included on the following Sprint’s Sprint Backlog.
Product Backlog – Is an ordered list of all the possible changes that could be made to the product. Items on the product backlog are options, not commitments in that just because they exist on the Product Backlog does not guarantee they will be delivered.
Product Owner – Provides ongoing maintenance of the product backlog including its content, availability, and ordering.
Sprint Backlog – A collection of product backlog items selected for delivery in the Sprint, which move the development team towards achieving the Sprint Goal.
Increment – The increment is the collection of the Product Backlog Items that meet the team’s Definition of Done by the end of the Sprint. The Product Owner may decide to release the increment or build upon it in future Sprints.
Definition of Done – The definition of done is a team’s shared agreement on the criteria that a Product Backlog Item must meet before it is considered done.
Scrum is a framework that establishes discipline and rigor to inexperienced or newly formed teams, with the events establishing a regular drumbeat and encouraging team collaboration. It allows development teams flexibility to respond to change, whilst providing enough control points to ensure the team does not stray from the desired outcome. Issues can be identified, swarmed/resolved and process adjustments made while the effort is still underway.
In addition to establishing scrum values, it also introduces important concepts such as delivering value fast, breaking work into chunks, prioritisation, development capacity and feedback loops. Given the understanding and adoption of Scrum amongst developers and organizations, it is a popular choice for Blue Prism development teams for Agile development.
Kanban is a workflow management method designed to help you visualize your work, maximize efficiency and be agile. From Japanese, Kanban is literally translated as billboard or signboard. It arose from a scheduling system for lean manufacturing, originating from the Toyota Production System and Toyota’s “just in time” manufacturing. This approach is a pull system based on customer demand, rather than the standard push practice.
Principles and practices of Kanban
The Kanban method can be broken down into four basic principles and six practices:
Principle 1: Start with What You Do Now
Kanban’s flexibility allows it to be overlaid on existing workflows, systems and processes without disrupting what is already successfully being done; it will, naturally, highlight issues that need to be addressed and help to assess and plan changes, so their implementation is as non-disruptive as possible. Kanban’s versatility allows it to be introduced incrementally, and sympathetically, to all types of an organization without fear of over-commitment or ‘culture shock’.
Principle 2: Agree to Pursue Incremental, Evolutionary Change
The Kanban methodology is designed to meet minimal resistance and thus encourages continuous small incremental and evolutionary changes to the current process, this supports migration from other development methodologies and continuous improvement activities to drive operational experience.
Principle 3: Respect the Current Process, Roles & Responsibilities
Kanban recognizes value in existing processes, roles and responsibilities. The Kanban method is designed to promote and encourage incremental, logical, changes without triggering a fear of change itself.
Principle 4: Encourage Acts of Leadership at All Levels
The best leadership comes from everyday acts of people on the front line of their teams and it is important that everyone fosters a mindset of continuous improvement (Kaizen) in order to reach optimal performance.
Practice 1: Visualize the Workflow
Understand what it currently takes to get an item from request to a deliverable product. This then means you can adjust and improve the delivery life cycle
Practice 2: Limit Work in Progress
Multi-tasking will generate waste and inefficiency, with Kanban a manageable number of items are in progress at any one time by setting work-in-progress limits. By limiting work in progress, a pull system is implemented and setting maximum items per stage ensures that a card is only “pulled” into the next step when there is available capacity. These constraints will highlight problem areas in development so you can resolve them.
Practice 3: Manage Flow
Implementing Kanban creates a smooth healthy flow of Blue Prism development items through the delivery life cycle and focuses on managing the work not the people. So instead of micro-managing developers and trying to keep them busy all the time, it focuses on managing the work processes and understanding how to get that work through the system faster. Ideally, we want fast and smooth flow as this means that the system is creating value quickly. This way we can minimize the average development time and avoid the cost of delay in a predictable fashion.
Practice 4: Make Process Policies Explicit
A process can’t be improved if its not understood. The process needs to be clearly defined, published and socialized. When the team are familiar with the common goal, they can work and make decisions regarding changes that will move delivery in a positive direction
Practice 5: Feedback Loops
For the positive change to happen, be successful and continue to happen establishing regular feedback loops across the team’s activities is critical. The Lean philosophy supports the assumption that regular meetings are necessary for knowledge transfer. A daily stand up meeting in front of the Kanban board for team synchronization is an example of this, with every team member explaining to the others what he or she did the previous day and what will be doing today.
Practice 6: Improve Collaboratively
The way to achieve continuous improvement and sustainable change within an organization is through shared vision and collective understanding of the issues that need to be addressed. Teams that have a shared understanding of the workflow, process, and risk are more likely to build a shared comprehension of the problems and suggest steps towards improvement.
With an increased focus on efficiency, many RPA COEs use the Kanban method in order to be more agile, bring order to chaotic work processes and get more work done. Transitioning from other Agile methodologies can seem logical and even inevitable after reading the principles and practices of Kanban. Visualizing workflow, creating transparency, be more responsive to changes in customer priorities, highlight bottlenecks, setting WIP limits, managing flow, establishing feedback loops and introducing collaborative improvement should mean a step-change in your Blue Prism delivery life cycle encouraging infectious incremental, evolutionary change to improve team operations continuously.
Before the Agile Manifesto was published there were existing development methods being experimented and practiced to find a solution to the failing traditional methods. These methods included Dynamic Systems Development Method (DSDM) and Extreme Programming (XP), as well as Feature Driven Development (FDD) and Crystal.
Since the Agile Manifesto was published in 2001 Scrum and Kanban are the most popular methodologies, however there are important principles and practices in these alternative agile methodologies that can be utilised in a hybrid delivery methodology:
Dynamic Systems Development Method (DSDM)
DSDM is a framework that is made up of eight principles, a life cycle and products, roles and responsibilities and several best practice techniques. These underpin and support a philosophy of delivering strategically aligned business benefits as early as possible to give an organization the best possible return on investment (ROI). There are eight principles underpinning DSDM and direct the team in the attitude and mindset they must take to deliver consistently:
|1. Focus on the business need||5. Build incrementally from firm foundations|
|2. Deliver on time||6. Develop iteratively|
|3. Collaborate||7. Communicate continuously and clearly|
|4. Never compromise quality||8. Demonstrate control|
DSDM is a methodology that prioritizes schedule and quality over functionality, which fixes cost, quality and time at the start and uses the MoSCoW method of prioritization, which breaks a project down into four different types of requirements:
|Must Have (M)||Should Have (S)||Could Have (C)||Won’t Have (W)|
Extreme Programming (XP)
The methodology takes its name from the idea that the beneficial elements of traditional software engineering practices are taken to “extreme” levels. As an example, code reviews are considered a beneficial practice. Taken to the extreme, Blue Prism development can be reviewed continuously through the practice of pair programming. For Blue Prism development it is suitable for small projects and/or projects will extreme time pressures.
Extreme Programming has emerged as one of the most popular and controversial Agile methodologies. XP is a disciplined approach to delivering high-quality automations quickly and continuously. It is intended to improve quality and responsiveness in the face of changing customer requirements. It promotes high customer involvement, rapid feedback loops, continuous testing and planning, and close teamwork to deliver working automations at very frequent intervals, typically every 1-3 weeks. It also has twelve supporting practices:
|1. Planning Game||7. Refactoring|
|2. Small Releases||8. Continuous Integration|
|3. Customer Acceptance Tests||9. Collective Code Ownership|
|4. Simple Design||10. Coding Standards|
|5. Pair Programming||11. Metaphor|
|6. Test-Driven Development||12. Sustainable Pace|
DevOps is a culture that promotes collaboration between Development and Operations Team and aims to shorten the development life cycle and provide continuous, high-quality delivery. Adopting a DevOps approach with Blue Prism should be started by understanding the 3 principles that underpin DevOps, developed by Gene Kim.
The First Way emphasizes the performance of the entire system, as opposed to the performance of a specific silo. The focus is on the business value stream, so it begins when requirements are identified, developed, then transitioned into operations, where the value is delivered to the customer. The outcomes of putting the First Way into practise include never passing a known defect to downstream, never allowing local optimization to create global degradation, always seeking to increase flow, and always seeking to achieve a profound understanding of the system.
The Second Way is about creating the right to left feedback loops. By shortening and amplifying feedback loops, necessary corrections can be continually made. The outcomes of the Second Way include understanding and responding to all customers, internal and external, shortening and amplifying all feedback loops, and embedding knowledge where needed.
The Third Way is about creating a culture that fosters two things: continual experimentation, taking risks and learning from failure; and understanding that repetition and practice is the prerequisite to mastery. The outcomes of the Third Way include allocating time for the improvement of daily work, creating rituals that reward the team for taking risks, and introducing faults into the system to increase resilience.
DevOps – Summary
DevOps is not a framework or a workflow, it’s a culture that ensures collaboration and communication between developers and operations. Blue Prism recognises that teams who have successfully adopted DevOps embrace these core principles that higher-level principles will be based.
Lean originated with the Toyota Production System, or TPS, which revolutionised the manufacture of physical goods in the 1950s, ‘60s, and beyond. Lean maintains its hold in manufacturing but has also found new applications in knowledge work, helping organizations in all industries eliminate waste, improve processes, and boost innovation. Blue Prism development is a natural application of Lean methodology because, much like manufacturing, it generally follows a defined process, has some defined conditions of acceptance, and results in the delivery of tangible value.
A lean organisation understands customer value and focuses its key processes to continuously increase it. The goal is to provide perfect value to the customer through a perfect value creation process that has zero waste. Lean The key focus of the Lean approach is to:
The combination of Lean Thinking and the Agile Manifesto concepts creates the Lean-Agile Mindset. This mindset is critical for supporting Lean-Agile development at scale across an enterprise and it has two primary aspects:
- Thinking Lean. The goal of which is to deliver value, and this supported by 4 pillars; (respect for people and culture, flow, innovation, and relentless improvement) and lean leadership provides the foundation.
- Embracing agility. There is no single Agile approach, but the Agile Manifesto introduced a value system into mainstream software development which have proved successful and provide an alternative approach for Blue Prism Teams and Leaders.
Together, they created the Lean-Agile Mindset, which is a large part of a new management approach and an accelerator to cultural improvement and cornerstone of Business Agility. It provides the thinking tools and belief system that leadership needs to guide a successful enterprise and team transformation. In turn, this helps both individuals and businesses achieve their goals.
Lean, Agile and DevOps overlap and diverge. Agile promotes small batch/iterative development improving the quality of the work and combining this with Lean thinking we can expand this approach across the entire value stream. DevOps uses Lean to improve collaboration and improve workflows and Lean concepts of continuous improvement, visual management, limiting work in progress and focus on customer value.
With the increasing demand for RPA Centre of Excellences (COE) to find a sustainable way to quickly and safely scale, many organizations have adopted Agile or DevOps methodologies which share a common (Lean) goal: To improve the speed and quality of value delivery.
Agile aims to optimize development specifically by addressing the gap between the customer and the developer:
it doesn’t address the other parts of the value chain though. DevOps recognises that this will push the constraint downstream to Ops and so works to break down wall’s between developers and operations:
in addition to some of its principles being adopted by Agile and DevOps, Lean broadens the focus to the entire value stream. In Blue Prisms experience, customers that draw upon elements of Lean thinking for their RPA Centre of Excellence, (whether that’s operationalised in Agile, DevOps or Lean) are more successful, because they accelerate the value-creating processes by breaking down silos of work, optimizing activities, providing visibility and improving team collaboration.