Cortex CoE Agile Execution Best Practices · Cortex Implementation Best Practices v2.0 Technical &...

Cortex CoE Agile Execution Best

Practices

Cortex Ltd © All Rights Reserved

Cortex Limited

Bridge House Waterfront East Level Street Brierley Hill DY5 1XR United Kingdom

T +44 23 8254 8990 E [email protected]

Status: PUBLISHED Release Date: 20/08/2018 Author: Eddie Watson Document Version: 2.2

All rights reserved. Passing on and copying of this document, use and communication of its contents are not permitted without written authorisation from Cortex Limited.


Contents

Centre of Excellence Agile Execution Best Practice ..................................... 1 Contents ........................................................................................ 3 Preface ......................................................................................... 4

Audience .............................................................................................. 4 Related Material ..................................................................................... 4 Revisions to this Document ......................................................................... 5

1. Programme Approach .................................................................. 6 1.1 Introduction .................................................................................. 6 1.2 Terminology .................................................................................. 6 1.3 Why Agile? .................................................................................... 7 1.4 What is Agile? ................................................................................ 9 1.5 LEAN Software Development Principles ................................................ 10 1.6 The Scrum Framework .................................................................... 10 1.6.1 Roles and responsibilities ............................................................. 11 1.6.2 Scrum Heartbeat ....................................................................... 11

2 Programme Initialisation .............................................................15 3 Project Stream Life Cycle ............................................................17

3.1 Key Stage 1: Feasibility ................................................................... 18 3.2 Key Stage 2: Scope ........................................................................ 18 3.3 Key Stage 3: Design ....................................................................... 19 3.4 Key Stage 4: Delivery ..................................................................... 19 3.5 Key Stage 5: Business as Usual........................................................... 19

4 Governance ............................................................................20 4.1 Governance Principles .................................................................... 20 4.2 Programme principles ..................................................................... 20

5 Operation of Centre of Excellence .................................................21 6 Documentation Framework ..........................................................22 7 References .............................................................................24 Appendix I: LEAN Software Development Principles ....................................25

Principle 1: Eliminate Waste .................................................................... 25 Principle 2: Build Quality In ..................................................................... 25 Principle 3: Create Knowledge ................................................................. 25 Principle 4: Defer Commitment ................................................................ 25 Principle 5: Deliver Fast ......................................................................... 26 Principle 6: Respect People ..................................................................... 26 Principle 7: Optimize the Whole ............................................................... 26


Preface

Audience This document is intended as a framework description for Agile Execution Best Practice for automation projects and programs. The primary foundation for establishing an Automation Centre of Excellence (CoE) is covered in the foundation Organisation and Roles document.

Related Material # Document Name Description

1 Cortex COE Organisation and Roles Best Practice v3.0

A framework document for establishing an Automation Centre of Excellence (CoE).

2 Cortex Implementation Best Practices v2.0 Technical & Design Best Practice

3 Cortex Continuous Integration Best Practices v1.0

Recommended architecture and processes to implement continuous automation integration efficiently.

4 Cortex Architecture Best Practices v1.1

High-level overview of Cortex platform architecture and implementation best practise and considerations.

5 Cortex Training Framework Training courses and resource profiles


Revisions to this Document The following revisions have been made to this document

Date Author Revision Notes

23/02/2018 EW 0.1 Creation of the document

11/06/2018 AO/RB 1.0 Review of content

18/06/18 EW 1.1 Consolidated comments and amends

14/06/2018 JH 2.1 Content update

20/08/18 KE 2.2 Editorial Amends and Updates


1. Programme Approach

1.1 Introduction The foundation structure of an Automation Centre of Excellence (CoE) can be applied to the choice of execution methodology preferred by the business and delivery team. This suite of Centre of Excellence guidelines has been structured with different methodologies in mind. The CoE Execution guidance is standalone and separate from Organisational, Roles, Design and Implementation guidance and best practice.

In this section we discuss the motivations supporting the selection of Agile as the execution Best Practice process.

1.2 Terminology • Functional Automation – A function in automation is the response to a set of inputs

with a set of outputs. It is typically a commodity type service that is unchanging between business requirements. As such it is typically and best implemented directly into authoritative business applications such as the finance, HR, or logistics systems business logic. This can be done through augmentation of “sub-tasks” in the automation layer where a function is lacking in the application layer or where local modification to the commodity function is required.

• Task driven automation – Tasks are those unchanging actions taken by a person

operating in a workflow. Simple, single domain task automation such as Scripts, or Robotic Process Automation (RPA) could include updating client profiles, processing forms, entering and transferring data from one system to another.

• Workflow driven automation – A workflow is the sequence of work flowed between manual operators / agents. This replaces the manual routing of cases which are typically more people centric; the flow of work between one person or team and another. Workflow is a very high abstraction of many processes, organised for the convenience of manual operations. Business Process examples include application processing, call handling, or service desk automation.

• Process driven automation – Enabling the automation of business transactions through end-to-end processes with or without human involvement. Only requiring User input whenever the process asks for it and typically form a Subject Matter Expert (SME) not an agent. Examples include document processing such as claims management and adjudication, or the onboarding of employees or leavers processing.

• Decision driven automation – Logical business rules applied to trigger tasks and advance a workflow. For example; assessing the value of a purchase order to establish what level of approval it requires. Such as; Underwriting, Incident response.

• Process Orchestration – Processes are the specific set of permutations to handle an

initial set of inputs to achieve a specific set of success criteria. Process orchestration is the evaluation and analysis of situations to sequence decisions, tasks and processes to achieve a prescribed end-state and output. This is a classic approach for Joiners, Movers and Leavers automation a complicated but predictable process.

• Service Orchestration – Services are either a consistent on demand facility that will provide a prescribed output, or a service that provides a prescribed output


independent of environmental changes. Service Orchestration is the evaluation and analysis of situations and external factors (context) to sequence decisions, tasks and processes to optimally seek, or maintain, a goal. A good example is; Service Provisioning and Lifecycle management for IT infrastructure is always complex and requires constant consideration of the changing environment. The full lifecycle may run for months, or years and should be maintained to achieve certain service levels while considering changes in performance, availability, configuration, etc.

1.3 Why Agile? Automation of any process, task or workflow reduces to the capture of knowledge and then the implementation of that knowledge in software and/or devices to achieve the identified objectives and outcomes. This may sound obvious, however, understanding and acknowledging this is the first step in ensuring the selection and adoption of appropriate principles, processes and frameworks which minimise risks of failure.

The knowledge that any organisation, or person, has about a process, task or workflow is usually incomplete, and at any one point reflects only what we know and have experience of to date. The definition of an activity is typically by observation of an emergent process, task, or workflow. Tasks being the simplest of processes are the easiest and most complete to capture. Simple processes (tasks) are usually in a single domain; which means one person can define them completely, and have very little decision making, or dependency on the environment. They also tend to be short run; minutes to hours.

Processes, and by extension services are more complicated and less easy to capture. In fact, most organisations make the mistake of trying to define processes through a mechanism of hiring “experts” to define and optimise processes in an authoritative manner. These usually fail and are incomplete; looking more like workflows where the key situations and decisions are left to the Subject Matter Experts involved in the flow, rather than being specific.

Tasks are usually the best known because they are simple, single domain and have few decisions, so many organisations structure themselves around Workflow and Tasks for that reason.

Unfortunately, a simple approach will not achieve the organisations goals; in fact research shows 72% of the time it fails. Process automation is a paradigm shift which will drive a wave of change in how things are done and enable new opportunities to do things better.

The appropriate approach must consider:

• All knowledge will not be known at the outset.

• Knowledge will be revealed that was a blind assumption, or presumption, previously.


• Predefining processes in an authoritative manner risks loss of actual knowledge.

• Existing operations are imperfect and must have the opportunity to improve.

• As the wave of knowledge and automation grows operations, decisions, information, situations, markets, customers, technology and businesses will change.

• The organisation must rapidly adapt to these changes.

Task and functional automation is commonly implemented using scripts and structured code in software. Typically, and unsurprisingly for a wide range of technical applications and tools. A key challenge associated with all these methods are that the functionality is created by software developers and resources trained in specific tools. This has been possible because very simple, unchanging, short run tasks and commodity type functions are easy to capture the detailed requirements. These are then translated by the developers into code. When translating this to persistent business processes, or even more complicated tasks a number of risks arise:

1. Misunderstandings and incorrect interpretation between the coder and the Subject Matter Expert (SME).

2. Missing information and resulting assumptions to complete the automation.

3. The SME cannot understand, and therefore validate, the resulting code

The Cortex platform is designed to enable non-developers to configure and implement automation and orchestration in a graphical no-code environment with integral exception management. This not only enables the SME’s to directly configure the automation but also presents the result in an ultra-clean graphical flow chart format ensuring full transparency for change.

Producing software and configuring automation still share the underlying principle that they are knowledge capturing processes. Experience has demonstrated that automation projects taking a pure Agile approach, as opposed to a waterfall or prescriptive approach, deliver outcomes at significantly higher success rates and ensure the paradigm shift to an automated state is permanent.

An agile approach ensures that not only the process of delivering each initiative is agile, but the team has the agility to evolve that process, ensuring no divergence between business operations and the automated processes. This is an initial and an on-going process during the lifetime of the deployment. It will often extend the life of the deployment to decades rather than the more traditional 3-5 year renewal cycle. Small iterative projects, aligned and supported through a CoE enables the best outcomes.


1.4 What is Agile? This is one of those questions where you are likely to get as many different answers as the people you ask! For this reason, we define here what we mean in in terms of our suggested Best Practice guidance. This is not intended to be a detailed description of the recommended methodologies and frameworks, references to some of those we have found comprehensive and practical are included in this document1.

The history of Agile in the form it is being referred to here was the result of a gathering of 17 software development leaders in Utah in 2001. The focus was to identify ways to address the high failure rates of traditional approaches. The result was a paradigm shift in thinking and was published as “The Manifesto for Agile Software Development”3.

The following key characteristics typify an Agile delivery:

• “Line of Sight” Planning and Execution:

o Objective driven: Long term objectives are defined but not the detailed plan to achieve them. This acknowledges and works with the well understood truism that up-front design cannot fully anticipate the complexity encountered during implementation

o Near term specific goals: Detailed planning horizons are short to ensure maximum certainty and knowledge on the capability to be delivered

• Collaborative:

o All stakeholders are actively involved and have a direct impact on delivery

o Early identification and rectification of priorities, challenges and assumptions

o Continually addresses organisational change management challenges

• Empowered and Self Organising:

o The teams are empowered to self-manage delivery including capacity and pace at a continuously sustainable pace

o Respect and trust in people involved in the team harnesses the maximum capability and innovation of all involved

• Iterative and incremental processes:

o Targeting near term delivery goals and engaging back with stakeholders on completion of each ensures:

Incremental delivery of capability

Maximum transparency

Earliest possible benefits from capabilities already delivered

Minimising risk by early review and adjustment

• Measure & Adjust continuously:

o Delivery teams estimate and set short term objectives

o Completion of each cycle measures outputs against estimates

o Review and adjustments embed principles of continuous improvements

1 Suggested references for further reading:

• Manifesto for Agile Software Development （Beck et al: Beck K.） • Scrum, A Pocket Guide （Verheyen，2013） • The Scrum GuideTM （Schwaberet al.）


o Managing change becomes an integral part of the process rather than an exception

A few key principles should be noted when adopting an Agile approach:

Gradual or partial adoption of an Agile approach when moving from a pre-planned predictive approach results in unresolvable contradictions due to the differences between the foundation principles of the approaches. This will generally ensure

failure.

Delivery to a specified end result within a fixed time frame contradicts an Agile approach. Target Objectives can be set or a targeted time period for the initiative to run can be agreed but not both (and keep an open mind about adjusting targets!)

1.5 LEAN Software Development Principles LEAN development principles have been included in this document because the principles, although once again focussed on software development, are not only relevant to automation but in our experience, encapsulate best practice. Including them as guidance upfront when setting up the delivery of an Agile project embeds the lessons learned over decades and will assist with minimising risks and maximising efficiency and speed of delivery.

The principles are based on the traditional manufacturing LEAN principles and were developed by Mary and Tom Poppendieck and published in the book Lean Software Development2. A copy of the 7 Principles has been included in Addendum I of this document for easy reference. In summary the seven headline principles (stated slightly differently to those in the Addendum) are as follows:

1. Eliminate waste 2. Amplify learning 3. Decide as late as possible 4. Deliver as fast as possible 5. Empower the team 6. Build integrity in 7. See the whole

As you can see there are a number of over lapping principles with Agile, however the detailed principles and explanations under these headlines are of real value.

Verheyen3 includes a more detailed motivation for including and blending the Agile and LEAN philosophies in his book Scrum a Pocket Guide and suggests the use of LEAN as a set of tools to guide thinking and entrench a culture of continuous improvement and optimisation.

1.6 The Scrum Framework While Agile and LEAN are a set of guiding principles, SCRUM provides a framework for developing and delivering complex solutions based on those principles. A concise and updated version of the Framework by the original creators: Ken Schwaber and Jeff Sutherland is available on-line4. This section quotes extensively from this document.

The foundation of the Scrum framework is based on empirical process control theory (empiricism). This has a desired objective or target, a measurement of what is actually achieved, and an algorithm or process designed over time to adjust the environment. This adaption is to eliminate the differences between target and actual as quickly as possible in

2 Lean Software Development （Poppendiecket al.，2003） 3 Scrum, A Pocket Guide （Verheyen，2013） 4 The Scrum GuideTM （Schwaberet al.）

https://en.wikipedia.org/wiki/Lean_software_development#Eliminate_waste

https://en.wikipedia.org/wiki/Lean_software_development#Amplify_learning

https://en.wikipedia.org/wiki/Lean_software_development#Decide_as_late_as_possible

https://en.wikipedia.org/wiki/Lean_software_development#Deliver_as_fast_as_possible

https://en.wikipedia.org/wiki/Lean_software_development#Empower_the_team

https://en.wikipedia.org/wiki/Lean_software_development#Build_integrity_in

https://en.wikipedia.org/wiki/Lean_software_development#See_the_whole


a stable fashion i.e. avoiding overshooting or undershooting. They summarise this as “Scrum employs an iterative, incremental approach to optimize predictability and control risk”.

They also include the following definition: Scrum (n): A framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value.

Scrum is:

• Lightweight

• Simple to understand

• Difficult to master

Scrum is a process framework that has been used to manage work on complex products since the early 1990s. Scrum is not a process, technique, or definitive method. Rather, it is a framework within which you can employ various processes and techniques. Scrum makes clear the relative efficacy of your product management and work techniques so that you can continuously improve the product, the team, and the working environment.

1.6.1 Roles and responsibilities A Scrum team comprises a Product Owner, Development Team and Scrum Master. They are self-organising and cross-functional i.e. in theory they should have all the skills required to deliver the work without reliance of resources external to the team, however with the CoE this may not always be the case.

• Product Owner:

o This is one person not a committee

o Has sole responsibility for managing all aspects of the Product Backlog: Ordering, making sure items are clearly expressed & understood etc.

o May delegate specific work items related to backlog management but is always accountable.

• Development Team:

o Cross-skilled group of resources capable of delivering all aspects of the work

o Size: Recommended to be minimum 3 and maximum 9. Too small reduces diversity and interaction and too large requires too much co-ordination and reduced agility.

o Structured and empowered to organise and manage their own work

• Scrum Master:

o Is the “servant-leader” of for the Scrum Team

o Responsible for supporting Scrum theory, principles and practice within the team as well as ensuring communication and understanding with those out-side the team

1.6.2 Scrum Heartbeat The heart of Scrum is a Sprint which is a fixed period during which the agreed deliverables are developed and presented at the end. There are a number of events before, during and after a sprint as well as a set of artefacts. These events and artefacts are designed to optimise transparency and opportunities for inspection. Incomplete adoption of these reduces transparency and results in lost opportunities to inspect and adapt.


Figure 1: Overview of the Scrum Process

1.6.2.1 Sprint Planning

A time boxed meeting where the Scrum team collaboratively create and agree the work to be performed in the Sprint, specifically:

• What can be delivered: The prioritised Backlog and current Product Increment together with the projected capacity of the team are the primary inputs. The required functionality and associated set of Backlog Items are selected. A specific Sprint Goal is crafted; this being an objective which will be met if the agreed product increment is achieved.

• How will this be achieved: The team design the system and the work required to deliver the agreed product increment. The efforts required to deliver Backlog items are estimated. Mismatches between effort and capacity are resolved by renegotiation with the Product Owner and adjustments to Product Increment and Sprint Goal agreed.

1.6.2.2 Sprint & Daily Scrum

This is a time boxed iteration during which the work is delivered. These need to be of a fixed and consistent duration with the recommendation being between one and four weeks. Too short a sprint limits what can be usefully be completed and delivered while too long reduces the transparency, inspection and adaption opportunities and significantly increases risks of wasted effort. It is also important to keep Sprints at a fixed duration in order to get consistent measurement of capacity and trends. An overview of the Scrum process can be found in Figure 1. A Sprint duration of two weeks has been used for illustrative purposes.

A critical component of the Sprint is the daily Scrum Meeting. These are 15-minute time boxed meetings used to inspect progress and trends towards achieving the Scrum goal. The format may be discussion or question based with the following an example of what should be covered:

• What did I do yesterday that helped the Development Team meet the Sprint Goal?


• What will I do today to help the Development Team meet the Sprint Goal?

• Do I see any impediment that prevents me or the Development Team from meeting the Sprint Goal?

1.6.2.3 Sprint Review

This is held at the end of the Sprint to inspect the Product Increment and adapt the Product Backlog if necessary. The Scrum Team and Stakeholders are involved and together review what was achieved and collaborate on the next things to be done to optimise value. As with all other events this needs to be time boxed with the time being appropriate for the duration of the Sprint, for example 1 ½ to 2 hours for a 2-week Sprint and at most 4hours for a 4-week Sprint.

• Review what Backlog items were done and which not.

• Development team demonstrates what work was done, answers questions and elicits feedback.

• Discuss what went well and any problems encountered and how they were dealt with.

• Product Backlog is reviewed and all attendees collaborate on what to do next.

• Review capacity, timelines, any changes in functional requirements and market needs.

1.6.2.4 Sprint Retrospective

This is held after the Sprint review and is an opportunity for the Scrum Team to inspect its own performance. The suggested time box would be 1 hour for a 2-week Sprint and no more than 3 hours for a 4-week Sprint cycle.

Objectives to be achieved should cover:

• Inspect how the last Sprint went with regards to people, relationships, process, and tools;

• Identify and order the major items that went well and potential improvements; and,

• Create a plan for implementing improvements to the way the Scrum Team does its work.

1.6.2.5 Scrum Artefacts

The following are key Scrum artefacts:

Product Backlog:

• Priority ordered list of all known features, functions, requirements, enhancements, and fixes required for the product in future releases.

• It is dynamic and never complete.

• Hierarchical with higher level Backlog items having more narrative and description. These being broken down into a smaller more specific focus with less narrative.

• Product Backlog items that will occupy the Development Team for the upcoming Sprint are refined so that any one item can reasonably be “Done” within the Sprint time-box.

• The Development Team is responsible for all estimates against items.

Sprint Backlog:

• Set of Backlog items selected for the Sprint.

• Plan for delivering the product Increment and achieving the Sprint Goal.


• A plan in sufficient detail to execute against and understand progress and changes in the Daily Scrum

• Can be adjusted and modified as the Development Team work through the plan and knowledge develops.

Monitoring Progress:

• An estimate of the total work remaining is maintained.

• Capacity achieved on Sprints is tracked and historised. This is used for planning capacity on subsequent Sprints.

• Presentation and visualisation of progress and trends are achieved through various tools including burn-up and burn-down charts.

Definition of Done: A list of expectations that the Sprint software increment must satisfy in order to be released into production.


2 Programme Initialisation

No Automation Programme can suddenly materialise and successfully deliver Automation into a business. It is essential that the way is prepared thoroughly, which requires the following essential pre-cursors:

Figure 2: Setting up an Automation Programme

1. An Automation champion and sponsor exist within the organisation. They should have profiles such as:

a. An executive sponsor at a senior level who is committed to the successful implementation of Automation to achieve key strategic objectives.

b. An Automation champion: Key influencer within the organisation, commonly with a technical background, who has a belief in the benefits of automation and a passion for achieving the automation objectives.

2. Ensure key people involved are familiar with and understand:

a. What is the organisation’s purpose, what is the organization delivering and what are their differentiators.

b. What can be achieved by various types of proven automation and automation technologies available.

c. The organisations operations and strategic objectives. In particular, how and where Automation will contribute to contributing to achieving key strategic objectives.

3. The Automation initiative is clearly communicated across the organisation with the key objectives of:

a. Preparing the way for change and putting in place appropriate measures to manage change within the organisation.

b. Aligning objectives across all stakeholders.


c. Ensuring that all stakeholders have an opportunity to get involved in an appropriate way.

4. Define Objectives and set Initial Targets for the programme to address:

a. The recommended approach is to agree the principles, documents and key stage approvals required to provide this foundation.

b. Once these objectives and initial targets are agreed a judgement can be made on the profile, make-up and size of the Centre of Excellence required to deliver this. Emphasis must be placed on the word “judgement”; This is not an exact science and needs to be approached as such. It is strongly recommended that the make-up and resourcing of the COE is kept under regular review and adjusted as pro-actively as possible.

Figure 3: Define Key Objectives


3 Project Stream Life Cycle

An automation initiative may consist of a single stream ringfenced project, or multiple parallel streams under the management and guidance of and Executive and Programme Management team. A single project stream should be stand-alone with specific business objectives and the minimum interdependencies with other projects or streams within the business.

Each interdependency will introduce risk to schedules and efficiencies and multiple interdependencies typically increase risks non-linearly (E.g. 2 interdependencies may increase risks 3 to 4-fold).

The identification and selection of Project streams should be part of the strategic focus of the CoE team. A framework and structure for the key stages can be found illustrated in Figure 4 and a description of key aspects associated with each key stage in the sections that follow.

Pre-cursors to the formal adoption of a stream are key for ensuring that selected streams are properly prioritised in terms of realisable benefits and lowest associated risks.

A key recommendation is that a stream should be scoped for the initial set of objectives to be achieved within 3 months and no more than 6 months. Subsequent capabilities and functionality should be delivered in subsequent separate streams.

Limiting the duration of a stream affords the opportunity of:

• A near term target for the delivery of benefits and capped investment before review of feasibility and benefits of subsequent planned functionality.

• Frequent reviewing and re-prioritising all contenders.

The decisions about the number of concurrent parallel streams and their target durations must be carefully evaluated by the CoE. Key considerations are the number of resources available, demand on Affiliated and Attached resources as well as the pace of change the business can deal with.

The heart of a delivery stream is the agile delivery and incremental implementation of capabilities and functionality. The Scrum framework brings unique and powerful advantages to this process. A few of these key advantages include:

1. Validation of requirements and objectives directly with stakeholders and users on completion of each sprint.

2. Automation should be incrementally put into production as soon as is feasible enabling early realisation of the benefits.

3. Exercising functionality and capabilities in a real-life context, enabling identification of bugs and oversights, as well as early experience and knowledge on all aspects of the solution (Operationally, business processes and technical).

4. The earliest possible opportunity for the team to adjust to clarified or adjusted requirements afforded by increased knowledge and experience.

The final key stage relates to the completion of a stream and the transition to Business as Usual operation and support of the implemented solution. This is a critical factor for ensuring maximum benefits are realised, not only in the early life adoption, but also that the solution adapts as the business changes and continues to deliver benefits. The objective should be to target ever increasing benefits as Automation becomes better understood and business processes designed with this in mind from inception.


Figure 4: Overview of a Project Life Cycle

3.1 Key Stage 1: Feasibility a) Question: Does the business case indicate a feasible project stream? b) Summary:

i) Perform initial feasibility: Identify objective, Anticipated benefits, stakeholders ii) Very Rough Order of Magnitude (VROM): Estimates of Costs, timelines and

benefits iii) Resources: Identify required resources and confirm availability, including

attached consultants iv) Enablers: Confirm that any required enabler is in place and will not stop the

initiative. This include: Infrastructure, processes and people v) Dependencies: What other systems, processes, data repositories or

projects/streams does the stream depend on? vi) Infrastructure: Define infrastructure requirements and confirm their feasibility

c) Deliverables: i) Automation Outline ii) Business case sufficient to motivate investing effort in progressing to next Key

stage iii) VROM and high-level time line iv) Risks, Assumptions and Dependencies: ensures early identification of these

aspects. Review and update at each Key Stage.

3.2 Key Stage 2: Scope a) Question: Are the business outcomes clearly defined and automatable? b) Summary:

i) Identifies specifications and discrete business outcomes ii) High level automated process view use cases including:

(1) Inputs (2) Enrichment: Dependent third-party systems and data repositories (3) Outputs

c) Deliverables: A high level design document which is dynamic and updated throughout the implementation covering the following: i) Specifications and required business outcomes


ii) Domain Mapping iii) Existing Processes iv) Communication Interfaces and data repositories v) Stakeholders vi) Process Automation Scoring

vii) Review risks, assumptions and challenges

3.3 Key Stage 3: Design a) Question: Are all the defined business outcomes achievable technically and

operationally? b) Summary:

i) Completion of initial detailed design to level sufficient to commence agile delivery

ii) Key principle to note: “Do NOT expect the design to be final or deterministic. The Scrum framework is specifically focussed on optimal iterative steps” (1) Validation of architecture comes as the Automations are configured (2) An early design cannot fully anticipate the complexity encountered during

implementation (3) Expect the design to evolve

c) Deliverables: i) For Phase 1 of targeted production functionality:

(1) Low Level Design Document (2) Updated and refined Scope key stage deliverables (3) Communication Interfaces: Detailed design and access methodology for

integration to dependent -3rd party systems and data repositories (4) Features and Product Backlog Items (PBIs) to achieve the end goal

ii) Roadmap: (1) Definition of future phase Objectives (2) Update of overall Programme Roadmap

3.4 Key Stage 4: Delivery a) Question: Agree and confirm underpinning Agile programme approach and adoption

of Scrum framework b) Summary:

i) Agree completion target objective; for example, either: (1) Phase 1 target functionality OR (2) Agreed Phase 1 completion date

ii) Refer to the Scrum Best Practice c) Deliverables:

i) Agile deliverables per sprint

3.5 Key Stage 5: Business as Usual a) Question: Do we have resources accessible by business as usual users to support

production use of automation b) Summary:

i) Support resources need to be: (1) Trained on Cortex (2) Familiar with the deployed infrastructure and environment (3) Knowledge transfer from or continuity with the Core COE team

c) Deliverables: (1) Business as usual support of production platforms by Service:

(a) First line Helpdesk (Phone or Internet) (b) Second line technical support (c) Third and fourth line specialised technical and subject matter experts


4 Governance

4.1 Governance Principles Achieving success against the stated high-level objectives using an Agile Development approach will require agreement and adherence to a clear set of governance guidelines. The concept of these guidelines should embody:

1. Agreement and buy in by Senior executives, Sponsors, Internal Stakeholders, execution and implementation participants.

2. Ensuring vendors and external participants understand and agree to their responsibilities, remits and commitments and that contractual commitments support an agile delivery model in all aspects (Technical, resourcing and commercial).

3. Acceptance that these guidelines themselves will adapt and change in an agile manner.

4. All changes must be clearly and promptly communicated and comply with Governance concept 1 above.

The suggestion is to reduce these to the smallest possible list of headline guidelines considered critical to achieving the objectives. These can be grouped under two broad categories of best practice:

1. Technical/Design Guidelines: These should cover the technical design, architecture and implementation aspects.

2. Management Guidelines: These should cover communication, reporting, decision making and escalation aspects.

4.2 Programme principles The following high-level principles are suggested to achieve the objectives stated in the introduction. These guidelines should be refined in every iteration:

1. Programme Heartbeat: The sprint durations must be defined and key meetings, communications, reports, and events expected for each sprint agreed and adhered to.

2. Decision Making: Clear guidance must be agreed, published, and implemented to ensure that decision making is quick and effective and all issues which require escalation or higher-level decisions are resolved within agreed time lines. For example:

a. Delegated decisions: Not agreed within X day of being tabled are flagged and escalated

b. Escalated decisions: Not resolved within Y days are flagged and escalated c. Key decisions required are tracked and included in RAG reports until

resolved 3. Reporting & Transparency:

a. Management: Reporting lines must be as short as possible to ensure quick transparent communication and turn-around of questions and decisions

b. Transparency: Scrum relies on transparency to ensure decision making is based on the best possible information. Incomplete artefacts and lack of transparency increase the risk of flawed and incorrect decisions.

4. Project Reporting: Light weight, effective reporting for the programme down to stream level must be agreed and implemented objectives and guidelines: These should ultimately be owned by the Programme Director (CPD). The process of reviewing, refining, agreeing and publishing updates must be agreed to ensure these remain relevant and front of mind.


5 Operation of Centre of Excellence

An efficiently running Centre of Excellence will not demand the participation of all members for every meeting. The nature of the association with the COE - Core, Attached, Affiliated, Aware - will determine the level and frequency of participation. It will be necessary to allow a structure that is flexible enough to respond to business changes with a minimum of disruption to the overall progress of automation transformation.

Meeting Organisation:

What Frequency Who Why Expected Outcome

Strategy and Review Meeting

Monthly Exec, CPD, EA, AA

Understand Business objectives, prioritise these objectives, review progress of streams under development and those in production

Roadmap input, understanding of status of automation under development and in production

Roadmap Meeting

Monthly CPD, AA, CSA, PM

Use Strategy and Review Meeting inputs to create roadmap

Prioritised Roadmap

Sprint Reviews Fortnightly Stakeholders, AA, CSA, PM, CFA

Demo new features, receive feedback

Deliver product increment

Sprint Planning Fortnightly AA, CSA, PM, CFA

Agree the work to be performed for next Sprint

Sprint backlog

Sprint Retrospective

Fortnightly AA, CSA, PM, CFA

Inspect performance, look for improvements

Plan for implementing improvements if appropriate

Daily Scrum Daily CSA, PM, CFA Progress, impediments, next steps

Daily understanding of activities

Service Review After stream delivery

CPD, CSA, SO, SDM

Gather customer feedback and satisfaction

Feedback for stream enhancements and fixes

Town Hall Quarterly CPD, anyone Announcements and demos regarding new operational streams

What has been delivered, why it has been delivered, what are the results, what is next


6 Documentation Framework

Most large organisations have some formal framework in place for projects. Our experience is that Automation Programmes have some very specific requirements and that these should be addressed from the very beginning to minimise risks to specific streams within the programme or indeed the programme as a whole.

The proposed framework is a set of documents that guide through the transformation automation programme, from the programme initialization to streams implementation and continuous improvement. This set of documents should never be an impediment or delay, keep them light, direct and focused.

The following suggested set of documents has been formulated to address these.

Ref Document Name Area Description

CCOE01 Automation Portfolio Foundation - Analysis Documentation of the current services that are or can be automated. What products/services are provided and their competitive advantages and areas of improvement.

Feasiblity studies are used as inputs for this document.

CCOE02 Feasibility Study Foundation - Analysis Feasibility study for an automation process containing: Technical, Operational, Resources and Financial feasibility.

CCOE03 Automation Objectives Foundation – Select automation targets

List of objectives ordered by priority and grouped by services and process.

Per objective it will include the description of the objective, KPI for measuring improvement before and after the automation and potential risks.

CCOE04 Streams Foundation – Select automation targets

List of streams related to automation objectives ordered by priority.

It includes per each stream: the automation objective, a high level description of the stream goal, required infrastructure, business systems involved, and required resources.


CCOE05 Automation Roadmap Foundation – Select automation targets

Roadmap detailing objectives, streams and their proposed milestones.

This is just an illustrative example; more maintainable Gantt chart tools are available in the market.

CCOE06 High Level design Project Stream - Scope

Per each stream a document, the architecture diagram including components and communication interfaces

CCOE07 Stream management Project Stream - Scope

Per each stream, detailing organisation and resources, stakeholders, decision making and reporting.

CCOE08 Technical Guidelines Foundation – Governance and Programme principles

Details of the technical design, architecture, and implementation aspects.


7 References

Beck et al: Beck K.BeedleM., van Bennekum A., Cockburn A., Cunningham W., Fowler M, Grenning J., Highsmith J., Hunt A., Jeffries R., Kern J., Marick B., Martin R.C., Mellor S., Schwaber K., Sutherland J., Thomas D.Manifesto for Agile Software Development．[Online]http://agilemanifesto.org/．

PoppendieckM, PoppendieckTom Lean Software Development: An Agile Toolkit．s.l.，Addison-Wesley Professional，2003．

Schwaber, SutherlandScrum Guide (2017) - Scrum Guides．[Online]https://www.scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-US.pdf．

Standish Group Chaos Manifesto (The Laws of Chaos and the Chaos 100 Best PM Practices)．2011．

SutherlandKenSchwaber and Jeff Software in 30 Days．s.l.，John Wiley & Sons Inc.，2012．

VerheyenGunther Scrum, A Pocket Guide．s.l.，Van Haren Publishing，2013．


Appendix I: LEAN Software Development Principles5

Principle 1: Eliminate Waste

• Waste is anything that interferes with giving customers what they really value at the time and place where it will provide the most value.

• Inventory is waste – In software that is partially done work • Churn – Requirement Churn, Repeating test/fix cycles • Many times caused by large inventories of partially done work • When requirements are specified long before coding • When testing occurs long after coding • Delayed integration • Overproduction – Extra Features • Only about 20 percent of features in custom software are regularly used (66% are

rarely used)

Principle 2: Build Quality In

• You don’t focus on putting defects into a tracking system; you avoid creating defects in the first place.

• Defect tracking systems are queues of partially done work • TDD and Continuous Integration • Write Less Code – Keep the Code Base Simple • Expect to change existing code • Refactor often

Principle 3: Create Knowledge

• Software is a knowledge creating process • Validation of architecture comes as the code is being written • An early design cannot fully anticipate the complexity encountered during

implementation • Expect the design to evolve • Early release of minimum feature set to customers for evaluation and feedback • Daily builds and rapid feedback from integration tests • A modular architecture that supports the ability to easily add new features • Encourage systematic learning throughout the development cycle • Stop acting as if our predictions of the future are fact rather than forecast. Instead,

we need to reduce our response time so we can respond correctly to events as they unfold

Principle 4: Defer Commitment

• Schedule irreversible decisions for the last responsible moment • We should try to make most decisions reversible • We should avoid making decisions that will lock in a critical design decision that

will be difficult to change • “In preparing for battles I have always found that plans are useless, but planning is

indispensable” Dwight Eisenhower

5 （Poppendiecket al.，2003）


Principle 5: Deliver Fast

• We need to figure out how to deliver software so fast that our customers don’t have time to change their minds

• Companies that compete on the basis of time often have a significant cost advantage

• Eliminated a huge amount of waste • Low defect rates • Repeatable and reliable speed is impossible without superb quality • In fast-moving organizations, the work is structured so that the people doing the

work know what to do without being told and are expected to solve problems and adapt to changes without permission

Principle 6: Respect People

• Entrepreneurial Leader • A company that respects its people develops good leaders and makes sure that

teams have the kind of leadership that fosters engaged, thinking people focused on creating a great product

• Expert Technical Workforce • Appropriate technical expertise is nurtured • Teams are staffed with needed expertise to accomplish their goals • Responsibility-Based Planning and Control • Teams are given general plans and reasonable goals and are trusted to self-organize

to meet the goals

Principle 7: Optimize the Whole

• A lean organization optimizes the whole value stream • Vicious Circle #1 • A customer wants some new features, “yesterday.” • Developers hear: Get it done fast, at all costs! • Result: Sloppy changes are made to the code base. • Result: Complexity of the code base increase • Result: Number of defects in the code base increases • Result: There is an exponential increase in time to add features • Vicious Circle #2 • Testing is overloaded with work • Result: Testing occurs long after coding • Result: Developers don’t get immediate feedback • Result: Developers create more defects • Result: Testing has more work. Systems have more defects • Result: Feedback to developers is delayed further. Repeat cycle.

Cortex CoE Agile Execution Best Practices · Cortex Implementation Best Practices v2.0 Technical &...

Documents

Transcript of Cortex CoE Agile Execution Best Practices · Cortex Implementation Best Practices v2.0 Technical &...