A presentation discussing some of the issues relating to the application of Agile approaches to Solution Design while maintaining Risk Mitigation

1. A Hybrid SDLC
Solution Design &
Procurement Approach

2. Contents
Section
#
Section Purpose Starts
slide:
1. “Standard” Solution Life Cycle (Waterfall) – The Context
2. Solution Development Life Cycle – Waterfall versus Agile?
3. How do we Accommodate (more-) Agile Approaches?
4. Solution Design Approach – When & Who?
5. Solution Design Approach – How & What?
6. Solution Design & Procurement Approach (Managed Sandpits – Why?)
7. Solution Design & Procurement Approach (Managed Sandpits Scenario – What?)
8. Solution Design & Procurement Approach (Managed Sandpits Scenario – How?)
9. Solution Design & Procurement Approach (Managed Sandpits Scenario – Who?)
10. Solution Design & Procurement Approach (Managed Sandpits Scenario – Where?)
2Solution Design & Procurement Approach01/04/2014

3. SECTION 1
“Standard” Solution Life Cycle (Waterfall) – The Context
3Solution Design & Procurement Approach01/04/2014

4. OperateShapeConcept
Problem Definition &
Impact Assessment
Feasibility
Assessment
High
Level
Design
Deliver
Detailed
Design Build Test
Implement Production Feedback
• UK Government and its suppliers has, in the past, built a whole industry around this Life Cycle,
typified by Prince II Project Management Methodology.
• It is a lifecycle that is very commonly implemented – its attraction is that this delineation of phasing
permits “checkpoints” at which a meaningful review and re-alignment (re-scoping or even
cancellation) can take place, thereby de-risking the process, something which is greatly-prized by
many stakeholders in solution life cycle process
The “Standard” Waterfall
Solution Lifecycle
4Solution Design & Procurement Approach01/04/2014
However:
• The “Checkpoint” approach creates a cottage industry of assurance – by people without the technical
skills to actually validate the solution, and thereby have to rely on documentation (creating its own
cottage industry) – ADDED COST
• Errors or incorrectly specified requirements found during the test or implement stages are extremely
costly to go back & correct – ADDED COST
• The process is invariably long-winded from beginning-to-end, which usually means that
requirements change during the life of the project,. Invoking expensive and time-consuming
Change Control. Worse, lengthy projects always experience personnel changes, with resultant
changes in thinking & approach – ADDED COST, RISK

5. SECTION 2
Solution Development Life Cycle – Motivation for (more-)Agile
Approaches
5Solution Design & Procurement Approach01/04/2014

6. Agile versus Waterfall
Agile Waterfall
Individuals & Interactions Processes & Tools
Working Software Comprehensive Documentation
Customer Collaboration Contract Negotiation
Responding to Change Following a Plan
6Solution Design & Procurement Approach01/04/2014
Quality
Features
CostTime
Quality
Features
CostTime
Principles
• Focus on the Business Need
• Deliver on Time
• Collaborate
• Never Compromise on Quality
• Build iteratively from firm foundations
• Deliver Iteratively
• Communicate continuously and
clearly
• Demonstrate control
Variable
Fixed
WaterfallAgile

7. Motivation for Agile Approach
Agile approaches are very suited to implementation of packaged software or
outsourced services. They are also used to a greater or lesser degree by
mature organisations in the development of software application components,
where it is felt that they can accept the Pareto Rule:
In an age where COTS software has become
highly-sophisticated through deployment and
experience in millions of Use Cases, the
hypothesis is that:
• 80% of the requirement can be satisfied with
20% of the total effort, and that
• common sense tells us we should quit there
while we are ahead.
The lingering doubt:
• Will the 80% work for us?
• Is the level of Risk acceptable?

8. SECTION 3
How do we Accommodate (more) Agile Approaches?
8Solution Design & Procurement Approach01/04/2014

9. OperateShapeConcept
Problem Definition &
Impact Assessment
Feasibility
Assessment
High
Level
Design
Deliver
Detailed
Design Build Test
Implement Production Feedback
• How do we accommodate “more-Agile” approaches to the Solution Development Life Cycle while
retaining Project Governance?
• However, there is a fundamental question which is not necessarily dependent upon the type of
“agile” that is adopted:
Does Agile “kick-in” at the start of requirements elaboration, or at the point where design
is stable?
• The next few slides elaborate some thoughts on this question
The Solution Lifecycle
9Solution Design & Procurement Approach01/04/2014

10. Iterative Build before Detailed
Design
0
OperateShapeConcept
Problem Definition &
Impact Assessment
Feasibility
Assessment
High
Level
Design
Deliver
Detailed
Design Build Test
Implement Production Feedback
1 2 4 5 6
Quality Gates
• In this case, iteration and parallel development by
teams working on different “sprints” takes place after
the HLD has been reviewed and agreed. Revisions to
design are accommodated during the sprint. This is
more clearly aligned with pure agile.
Update
Project
Plan
Tech
Design,
Specs
Create
Detailed
Test Cases
Develop &
Test
Demo &
Retrospec
tives
Refine
Reqs
10Solution Design & Procurement Approach01/04/2014
Full Business Case
Authorised or T&M
• If a Fixed Cost Business Case is agreed at this point,
the customer is exposed to the risk of incomplete
delivery or escalating change control. Depending
upon the rigour of the original specification, the
supplier may also be faced with an unacceptable
level of risk
• On the other hand most customers are reluctant to
agree to a T&M approach

11. Agile – Iterative Build after
Detailed Design
0
OperateShapeConcept
Problem Definition &
Impact Assessment
Feasibility
Assessment
High
Level
Design
Deliver
Detailed
Design Build Test
Implement Production Feedback
1 2 3 4 5 6
Quality Gates
Full Business Case
Authorised
Update
Project
Plan
Tech
Design,
Specs
Create
Detailed
Test Cases
Develop &
Test
Demo &
Retrospec
tives
Refine
Reqs
• In this case, iteration and parallel development by
teams working on different “sprints” takes place after
the LLD has been reviewed and agreed. Revisions to
design will only take place where detailed development
work reveals an error or a gap in the design
• This is not pure agile but rather a hybrid of waterfall
and agile.
• Clearly this allows the project to proceed with more
certainty but mitigates against one of the benefits of
agile – namely the feedback loop into design (and the
end product of the sprint) from detailed development
11Solution Design & Procurement Approach01/04/2014

12. There is a way….

13. SECTION 4
Solution Design Approach – When & Who
13Solution Design & Procurement Approach01/04/2014

14. When - Phases
Collaborative Requirements Engineering
Convergence (including Sandpits)
Iterative Build
14Solution Design & Procurement Approach01/04/2014

15. Who – Multi-Disciplinary Team
Project Level Roles
Business Sponsor - owns and ensures ongoing viability of the
Business Case, & ready to pull the plug if necessary.
Responsible for obtain funding & other resources, oversees
decision making & escalation, responds rapidly to escalated
issues & delivers Business Benefits
Business Visionary - owns wider implications of business
change; define communicate and promote business vision;
contribute to key decisions, designs and review sessions,
monitor progress, approve changes to high-level requirements,
ensure collaboration & availability of internal SME resources,
act as final arbiter on business requirements
Project Manager - communicating with senior stakeholders
and responsible for project governance; high-level project
planning & scheduling; monitoring progress; managing risk;;
motivating the project teams; resourcing specialist roles;
managing problems & issues and escalating as required
Architect - to agree and control the Technical Architecture; to
identify and own technical risks, escalating to the PM as
appropriate; to advise on and coordinate technical activity; to
ensure non-functional requirements are achievable and
achieved; to ensure adherence to appropriate standards of
technical best practice; to control the technical configuration of
the solution; to manage technical aspects of the transition to
live use of the solution; to resolve technical differences
between team members
15Solution Design & Procurement Approach01/04/2014

16. Who – Multi-Disciplinary Team
Solution Level roles
Members of the team are empowered to make solution
decisions within an agreed terms of reference
Team leader - a leadership rather than management role. Can be
different team leader for different stages of project. Elected by
peers. Responsibilities - to work within the team to plan &
coordinate all aspects of product delivery, at a detailed level; to
ensure that the team operates as an entity and fulfils its
obligations; to report to the PM
Business Analyst - provides clear direction for the business
users; ensures business needs are analysed and reflected in
guidance for the project team; works alongside the business but
does not make decisions on its behalf, ensures no scope creep
and only low level details are added during the solution
development; manages requirements priority list
Business Specialist - role filled by someone with specific
knowledge relevant to some or all of the project - examples,
legal or finance or security expert
Technical Specialist - technical equivalent of Business Advisor -
examples, DB developer or Technical author
Solution Developer - technical skills (analyst / programmer) to
the fore, but good communicator and team player; must be
dedicated to the project because of the time-boxing approach
Business SME - very knowledgeable about business area and its
processes; links solution development team and the business;
the role provides business-related information from end-user's
perspective
16Solution Design & Procurement Approach01/04/2014

17. SECTION 5
Solution Design Approach – How & What
17Solution Design & Procurement Approach01/04/2014

18. How - Workshop Approach
The workshops are structured to align with the new Target
Operating Model Business Capabilities that are in scope.
• Capabilities are de-composed into their constituent
processes – these represent the scope of individual
workshops
The workshops will address both To-be and As-is jointly in
workshops.
• We can identify anything that exists in the As-is that can
be reused for the To-be
• This is more efficient in terms of the use of BA & SME
resource
• It is also crucial to condense the e2e Requirements
Gathering into as short an elapsed period of time as
possible:
• Business context and therefore requirements change
quickly, so a lengthy process can become like painting
the San Francisco Bridge
• Continuity of personnel is also vital, so shortened
timescales mitigate the impact of personnel sickness,
holidays and turnover
18Solution Design & Procurement Approach01/04/2014

19. What - Design Approach
The workshops adopt a standard approach to analysis:
1. Quickly confirm the As-is process flows (with no
supporting Information Flows etc)
2. Identify the Outcomes mandated for a successful
implementation of the To-Be process
3. Map As-Is on to the To-Be model and identify any
gaps
4. Extract information from the documentation of
the individual workshops, such as Roles, Business
Rules, Candidate Services, User numbers etc and
lodge them in repositories so that they can be
“normalised.”
5. Perform a MoSCoW analysis to determine priority
19Solution Design & Procurement Approach01/04/2014

20. SECTION 6
Solution Design & Procurement Approach (Managed Sandpits) – Why?
20Solution Design & Procurement Approach01/04/2014

21. Why - Motivation for a
Managed Sandpit?
COTS Approach
• Speed to Market
• Lower cost
• Reduce Risk
– Will it work? Of course it will – COTS software has been deployed and exercised in millions of Use
Cases
– Will it work for us? The Key Question
Transformation Agenda
• Drive stakeholder thinking about “will it work for us?”
• Thereby inform RFP Requirements – “Outcomes focussed”
Capturing the outputs in the form of potential future questions and ultimately RFP Requirements
Experiencing a working relationship with bidders.

22. What is a Managed Sandpit?
Three Sandpit phases:
1. Convergence
2. Close-down
3. RFP Evaluation
A sandpit is an intensive, interactive and extended workshop where Examiner participants are encouraged
to delve deeply to explore the capabilities of bidder “vanilla” solutions.
Vanilla solution (configured to enable Examiner stakeholders to explore the scenario) which can be easily
created, “trashed” then easily resurrected.
Addresses the question “Will it work for us?” and starts Examiner thinking about:
• “Can we adapt our ways of working to adopt the vanilla solution and…”
• “What will we have to do to adopt the vanilla solution
22Solution Design & Procurement Approach01/04/2014

23. How - Process for a Managed
Sandpit?
The process can be broken down into:
• Define the scope of the issue (Scenario)
• Agree a common language and terminology amongst people from a diverse range of backgrounds and
disciplines.
• Share understanding of the problem domain
• Mix of “hands-on” elaboration of the Scenario and break-out sessions focused on the problem
domain, encouraging creative and innovative thinking within the framework of the initial scenario, and
each bidder’s “vanilla” solution
• Initial support for walkthrough of scenario (“Happy Path”) journey through the vanilla solution
• Ad hoc support for user queries:
– “How do I…?
– “How would you achieve this (outcome-focussed) requirement?
• Document outputs & further questions (we will maintain confidentiality of bidder IPR)

24. Who - Participants?
• It will typically involves 20-30 participants over time
– The Transformation Director (whose role is to define the topic and facilitate discussions at
sandpit events),
– Lead BA
– Solution Architect
– Subject Matter Experts (Bid team)
– Solution Experts (Bidder team)
• An essential element of a sandpit is a highly multidisciplinary mix of participants taking part, some
being programme stakeholders and some being users of programme outcomes, to drive lateral
thinking and radical approaches to addressing particular programme challenges.
24Solution Design & Procurement Approach01/04/2014

25. SECTION 7
Solution Design & Procurement Approach (Managed Sandpits Scenario)
25Solution Design & Procurement Approach01/04/2014

26. Sandpit Scenario – Students
entering the Exam
• 6 students enter for the F5 exam in the December exam session; Emma, Carol-Anne and
Andy are all from the UK and wish to sit at a Glasgow venue.
• Joyce and Nick live in the Caribbean and wish to sit at a Caribbean venue.
• Jasmine lives in Hong Kong and wishes to sit at a HK venue.
• All have decided to sit a computer-based exam, except for Carol-Anne who wishes to take a
paper-based exam.
• Each student logs into myAccount and navigates to exam entry. Once they have selected
their exam and the exam they wish to take and their eligibility is confirmed, they each select
the venue which is most convenient for them and choose an exam session from the available
dates and timeslots shown.
• As each of the students select an exam session and successfully completes payment, the
available capacity at their chosen venue is reduced accordingly. Upon successful acceptance
of their exam entries, students receive confirmation and full details of what to do next (e.g.
venue directions and any authentication details which they will need on the day of the exam).
26Solution Design & Procurement Approach01/04/2014

27. Sandpit Scenario – Students
sitting the Exam
• After having entered for the exam Andy moves to Hong Kong and needs to change his exam
booking from a Glasgow venue to Hong Kong. Again, this automatically updates the available
capacity at both Glasgow and Hong Kong.
• On the exam day, Emma arrives at her chosen venue and time slot (9am). The exam centre
authenticates her identity, checks her in and then shows her to her workstation.
• When instructed by the invigilator Emma enters her security credentials into the assessment
system and is presented with the correct exam version (as per her time zone) and begins her exam.
• The exam that she sits is the same version as that sat by Andy at 2pm local time in Hong Kong.
During the exam a fire alarm is activated and the exam centre is evacuated. Emma is allowed to
return to her workstation 20mins later and her exam is restarted where she left it with all previous
responses retained.
• When the exam is concluded all Emma’s responses and marks (where automatic marking has been
possible) are automatically stored and sent to the Examiner along with associated data for manual
marking (where auto marking has not been possible).
• The Examiner uses the information received to conduct statistical and process analysis on
automarked responses and sends written responses for expert marking. The Examiner processes
the final marks and sends results to its students.
27Solution Design & Procurement Approach01/04/2014

28. Sandpit Scenario – Exam Centre
set-up
• In advance of each exam session the exam centres enter their available capacity into the online
capacity management capability.
• For the December session the Glasgow venue has 4 seats available, Caribbean has 3 and Hong
Kong has 1.
• Throughout the exam entry period the Examiner monitors the consumption of the available
capacity via capacity management dashboards. It is noticed that the single Hong Kong seat is
booked and therefore an additional seat is sourced and made available.
28Solution Design & Procurement Approach01/04/2014

29. Sandpit Scenario – Exam
Production
• The December session will be the first time F5 is available in a CBE format. The Examiner monitors
the F5 item bank (showing “low stock”) and commissions approved Item Authors to write specific
items
• Sharon, an author who lives in India, accesses the secure authoring system from her home windows
PC, creating 2 different longer style questions using the template provided, includes the initial set of
question attributes (topic etc.) and submits to the Examiner.
• Sharon’s 2 questions are automatically routed to Catherine, who is the specialist reviewer for all
questions from this syllabus area. Like Sharon she is external to the Examiner and accesses the
reviewing system remotely from her home Apple Mac. The communication between Sharon and
Catherine’s devices and the authoring system is highly secure: their access to the system is subject to
robust authentication and their access is controlled and audited.
• Catherine reviews Sharon’s questions, edits them as necessary and adds comments; she marks it as
reviewed and the production system automatically adds it to the list of items to be reviewed at the
next relevant exam panel where it is reviewed, amended & accepted.
• A member of the Examiner exam production team changes the status of the questions to ready for
pre-test and they are banked ready for inclusion within a pre-test exam.
• A pre-test exam is generated and sat by a small number of students at an exam centre. During the
pre-test all responses and associated data are collected and submitted to Examiner (potentially along
with qualitative feedback).
• Examiner analyses the pre-test data and calibrates the questions.
• Throughout the author, review, acceptance and pre-test process, the system prevents any leakage of
content to the Internet or access by unauthorised persons.
29Solution Design & Procurement Approach01/04/2014

30. Sandpit Scenario – Exam
Production
• Following pre-testing a member of The Examiner exam production team changes the status of the
accepted questions and they are banked ready for inclusion within a live exam.
• In advance of the December exam session the F5 QTA (Qualifications Technical Advisor) requests
several auto generated F5 exam versions: one to be offered as the paper-based exam and the others
to be offered as computer-based exams. The system generates the draft exams using the F5
balancing rules. The F5 QTA and Examiner review the first exam version and decide that one of the
longer style questions should be changed. They search the question bank and select a different
question and edit the exam version. Once both the QTA and examiner are happy with the exam
version its status is changed to published. Throughout this process, access to the system by The
Examiner exam production team, QTA and Examiner is secured, authenticated, authorised and
audited.
• This exam versions is published both in a format suitable for offering as a Computer Based Exam as
well as in a format that can be sent to Examiner’s security printers for printing.
• Examiner’s Exam Production team regularly review the operational status of content production and
chase Authors which are behind with their commission, thereby ensuring that the overall exam
production schedule is followed.
30Solution Design & Procurement Approach01/04/2014

31. Sandpit Scenario – Exam
Centre/Invigilator
• In advance of the December exam session the Glasgow venue downloads all necessary software and
exam content. On the morning of the exam they perform a diagnostic test to ensure everything is
working as required to successfully complete the exams.
• During the exam the invigilator monitors each workstation within the room from their own
workstation. A fire alarm is activated, at which point the invigilator stops the exam and evacuates the
centre. After 20 minutes all candidates return to their desks and the invigilator restarts the exam.
• After the exam, the invigilator or centre administrator uploads student responses and any exam day
reports and ensures that student attendance information is correctly recorded. Exam day reports
include both details of the fire alarm incident as well as details of an incident where they noticed a
student attempting to cheat by copying responses from the student sat next to them.
• The centre administrator then validates that Examiner has received all the necessary response and
data files, before removing all exam content from the exam centre’s computers.
31Solution Design & Procurement Approach01/04/2014