implementing agile iterative project delivery approach and achieving business responsiveness

148
Implementing Agile Iterative Project Delivery Approach and Achieving Business Responsiveness Alan McSweeney

Post on 17-Oct-2014

9.172 views

Category:

Technology


0 download

DESCRIPTION

Describe a generalised agile and iterative approach to information technology projects and the use of the agile approach within organisations

TRANSCRIPT

Page 1: Implementing agile iterative project delivery approach and achieving business responsiveness

Implementing Agile Iterative Project Delivery Approach and Achieving Business Responsiveness

Alan McSweeney

Page 2: Implementing agile iterative project delivery approach and achieving business responsiveness

August 16, 2010 2

Objectives

• To describe a generalised agile and iterative approach to information technology projects and the use of the agile approach within organisations

Page 3: Implementing agile iterative project delivery approach and achieving business responsiveness

August 16, 2010 3

Agenda

• Introduction

• Agile Iterative Approach to Projects

−Using Agile Effectively and Productively

− Control Components of Agile Process

−Agile Tools and Techniques

− Iterative Agile Framework and Phases

• Using Agile Iterative Approach for Specific Projects

• Introducing Agile Iterative Approach into an Organisation

Page 4: Implementing agile iterative project delivery approach and achieving business responsiveness

August 16, 2010 4

Introduction

Page 5: Implementing agile iterative project delivery approach and achieving business responsiveness

August 16, 2010 5

Projects

• Projects are about change− New or changes to existing processes, systems, applications, structures

• Organisations need to be good at two sets of skills− Running the Business (RTB) – business as usual operations− Change the Business (CTB) – changing existing operations to survive or compete

• Projects are the way of introducing change into organisations

• Projects tend to be multidisciplinary, involving some or all of:− Requirements gathering− Solution design− Hardware installation− Product selection− Software development or modification− Testing− Process change− Organisation change− Data conversion− Implementation− Parallel operation

• Organisations need to be good at projects in order to deliver change

Page 6: Implementing agile iterative project delivery approach and achieving business responsiveness

August 16, 2010 6

Dimensions of Being Good At Organisational Change

• To be good at change, three dimensions must come together within the organisation:− A clear vision for the

organisation and the set of projects needed to deliver on the vision

− A proven capability to deliver projects quickly and effectively

− Focus on the realisation of expected business benefits and business value associated with the implementation of information technology investments

• Agile approach to projects is one way of being good at change

Ability to Execute Projects

Completeness of Organisational

Vision

Effective and Proven Benefits Realisation

Approach

Page 7: Implementing agile iterative project delivery approach and achieving business responsiveness

August 16, 2010 7

Projects Fail

• Yes – projects fail – it’s no surprise

• Fail occurs largely because of people rather than technology issues

• Project success means the project delivered on time, on budget, to agreed specification and delivering the agreed business benefits

• Different types and scales of project failure− Delivered solution fails to meet the business requirements for which it was

implemented and its use is abandoned or expensive adjustments are made

− There are performance problems in the delivered solution which means it is insufficient to meet the needs of users and its use is abandoned or expensive adjustments are made

− After implementation errors and gaps appear in the delivered solution causing unexpected problem and its use is abandoned or expensive adjustments are made

− Users reject, bypass or circumvent the delivered solution because of lack of consultation, involvement, commitment, agreement or other reasons

− Delivered solution is used but over gradually become to expensive or complex to maintain and falls into disuse

− Project is late and/or over budget

− Project does not deliver the business benefits

Page 8: Implementing agile iterative project delivery approach and achieving business responsiveness

August 16, 2010 8

Spectrum of Project Failures

Complete Success

Complete Failure

Complete Project Success:

On-time, On-budget

Complete Project Failure: Cancelled, Unused, Rejected

Specified Business Benefits and Savings Not

DeliveredProject Late and/or Over

Budget

Significant Rework

Required

Solution Largely Unused

Functionality Delivered Does not Meet Business

Requirements

Performance and/or Operational

Problems

More Expensive to Operate Than

Planned

Page 9: Implementing agile iterative project delivery approach and achieving business responsiveness

August 16, 2010 9

Balancing Solution Functionality and Implementation Project Cost/Resources and Time

• Traditional view of projects is that they are a balance between meeting requirements (solution functionality), implementation project resources (and thus cost) and project time

• Functionality (requirements) is fixed and cost and time must vary

Page 10: Implementing agile iterative project delivery approach and achieving business responsiveness

August 16, 2010 10

Balancing Solution Functionality and Implementation Project Cost/Resources and

• Resources are constrained so project time must increase

• Time is constrained so resources must increase

Page 11: Implementing agile iterative project delivery approach and achieving business responsiveness

August 16, 2010 11

Project Risk/Quality Factor

• Reality is that all projects have a risk dimension – projects fail all too frequently

• Risk and quality are interrelated

• Risk increases with project duration, size of project team and complexity of solution being implemented

Page 12: Implementing agile iterative project delivery approach and achieving business responsiveness

August 16, 2010 12

Projects and Changes

• Organisations need to deliver projects to business in shorter timescales in response to internal and external

• Project processes need to be flexible, responsive and agile in order to deliver what the organisation needs when it needs it

• Traditionally projects are delivered in a series of sequential phases designed to create certainty around the solution being delivered− Gather requirements− Design solution− Technical and detailed design− Development/modification− Testing − Implementation− Operation

• Sequential approach has disadvantages− Not sufficiently flexible to accommodate changes in requirements− Resources are wasted building features that nobody needs− Opportunity to provide feedback limited until a large part of the solution is delivered− Solution stability and operability not certain until late in the project

Page 13: Implementing agile iterative project delivery approach and achieving business responsiveness

August 16, 2010 13

What Makes Projects Succeed

• User involvement and commitment

• Executive management sponsorship

• Defined and certain business objectives

• Defined and agreed requirements

• Defined scope

• Flexible and reactive delivery process

• Project management skill and experience

• Good control of project costs

• Skilled and experienced project team

• Project delivery methodology

• Proven technology

Page 14: Implementing agile iterative project delivery approach and achieving business responsiveness

August 16, 2010 14

What Makes Projects Fail

• Lack of or changing executive management commitment

• Unclear of scope, objectives and requirements

• Lack of user commitment and involvement

• Changing scope and objectives and poor change control

• Poor planning and estimation

• Poor project management

• Failure to manage end-user expectations

• Lack of agreement between stakeholders

• Lack of skills and experience in the project team

• Unclear definition of roles and responsibilities

• Artificial and unrealistic deadlines

• Specifications not agreed

• New or radically redesigned underlying business processes

• Use of new technology

• Poor project control against targets

• Large number of organisational units involved

• Lack of effective project methodologies

• High project staff turnover

Page 15: Implementing agile iterative project delivery approach and achieving business responsiveness

August 16, 2010 15

Flexible, Responsive, Agile Project Approach

• An agile approach to project delivery seeks to reduce risks associated with sequential solution delivery approach−Multiple iterations/releases

− Sets of smaller deliveries

− Prioritised requirements

−Greater user involvement

− Lower overall cost

• Agile approach tends to be good for projects with inherent uncertainty and volatility− Transformation and organisational change projects

− Support and maintenance

− Research and development

− Information technology

Page 16: Implementing agile iterative project delivery approach and achieving business responsiveness

August 16, 2010 16

Applying Agile Approach to Projects

• Agile approach tends to be associated with software development projects

• More general approach and can and should be applied more widely to other projects (that may have a development component)

Page 17: Implementing agile iterative project delivery approach and achieving business responsiveness

August 16, 2010 17

Classification of Projects

Project Technology

Pro

ject

Re

qu

ire

me

nts

Well Proven

Highly Uncertain

Well Defined/ Agreed

Highly Undefined

and Far from Agreement

Simple

Here be Dragons

Highly Complex

Complicated

Difficult

Page 18: Implementing agile iterative project delivery approach and achieving business responsiveness

August 16, 2010 18

Solution Functionality Used

• Most of the functionality of delivered solutions is never or seldom used

− Not surprising – think of all the features in applications such as Microsoft Office

− How much do you use?

• Represents a significant cost

• Tendency is always to deliver complex feature-rich solutions

• Simplicity is not seen as good

Page 19: Implementing agile iterative project delivery approach and achieving business responsiveness

August 16, 2010 19

Agile Iterative Approach to Projects

• Time is fixed for the life of a project and resources are fixed as far as possible

• Requirements that will be satisfied are allowed to change

• Flexibility of requirements to be satisfied has significant impact on the development processes and controls, and on acceptance of the system

• Iterative approach reduces risk by continuously reaffirming and validating the solution being implemented

Page 20: Implementing agile iterative project delivery approach and achieving business responsiveness

August 16, 2010 20

Agile Iterative Approach to Projects

Page 21: Implementing agile iterative project delivery approach and achieving business responsiveness

August 16, 2010 21

What is Meant by Agility

• Driven by user descriptions/scenarios of what is required of the solution

• Seeks constant user feedback

• Recognises that plans are short-lived

• Develops solution iteratively with a emphasis on development activities

• Delivers multiple working solution increments

• Adapts as changes occur

Page 22: Implementing agile iterative project delivery approach and achieving business responsiveness

August 16, 2010 22

What Are the Potential Issues With Agile Approach

• May not apply to large and complex projects

• May not be suitable to all organisations and people

• Delivered solutions may not be scalable to large volumes of users/transactions/workload/data

• Delivered solutions may not be adaptable to meet future business needs

Page 23: Implementing agile iterative project delivery approach and achieving business responsiveness

August 16, 2010 23

Agile and People

• People are at the core of an agile process

• The process adapts to the needs of the team needs rather than imposing a structure on the team as with conventional sequential processes

• An effective agile team should be:− Competent

−Working towards a common goal

− Collaborative

−Able to make decisions

−Good at solving problems

− Trust and respect one another

− Self-organising with respect to workload, schedule and project processes

Page 24: Implementing agile iterative project delivery approach and achieving business responsiveness

August 16, 2010 24

Iterative Agile Approach to Projects

• Fundamental assumption of agile approach to projects is that nothing is built perfectly first time

• 80% of the solution can be implemented in 20% of the time that it would take to produce the total solution

• All deliverables from previous project steps can potentially be revisited as part of the iterative approach

• Only enough of the current step need be completed to move to thenext step

• Designed to address the current and immediate needs of the business

• Deliver simpler solutions more quickly that are fit for purpose and easier to maintain and modify after their initial implementation

Page 25: Implementing agile iterative project delivery approach and achieving business responsiveness

August 16, 2010 25

Agile Approach to Ensuring Project Success

• Satisfies the real requirements of the organisation prioritised by importance

• Supports the way the organisation needs to work

• Aims to deliver quality solution on time and within budget

• Aims to deliver quickly and effectively

− Required functionality, performance, security, operability and maintainability

Page 26: Implementing agile iterative project delivery approach and achieving business responsiveness

August 16, 2010 26

Using Agile Iterative Approach

• All too frequently seen as a panacea to project problems

− It is not

−Agile is hard

• Agile has become fashionable without an understanding of the effort involved

• Agile requires commitment, involvement and can be intense and demanding

• If you have current project problems, agile is probably not the solution

− You need to fix the underlying organisational issues first

Page 27: Implementing agile iterative project delivery approach and achieving business responsiveness

August 16, 2010 27

Agile Approaches

• Lots of different agile approaches− Adaptive Software Development (ASD) − Agile Unified Process (AUP)− Crystal Clear − DSDM (Dynamic Systems Development Method)− Essential Unified Process (EssUP)− FDD (Feature Driven Development)− Incremental SDLC − Open Unified Process (OpenUP)− RAD (Rapid Application Development)− Scrum− Spiral SDLC − TDD (Test-driven development)− XP (Extreme programming)

• Common features− Teamwork, collaboration, and process flexibility adaptability throughout the project lifecycle− Divide tasks into smaller increments with accelerated planning− Multiple small iterations

• Many agile processes are focussed on software development projects

• Need a more generalised agile approach that can be applied to all information technology projects

Page 28: Implementing agile iterative project delivery approach and achieving business responsiveness

August 16, 2010 28

Benefits of Iterative Agile Approach to Solution Delivery

• Users are more likely to be committed to the solution

• Risk of building the wrong solution is substantially reduced

• Final system is more likely to meet the real needs of the organisation

• Implementation is more likely to be easier because of the involvement of all parties concerned throughout the project

Page 29: Implementing agile iterative project delivery approach and achieving business responsiveness

August 16, 2010 29

Agile Iterative Approach StructureGeneralised Approach to

Agile Iterative Projects

Project Selection and Validation

Control Components of Agile Process

Agile Tools and Techniques

Agile Approach Suitability Checklist

Solutions and Projects When to Use Agile

Agile Project Critical Success Factors

Key Principles of Iterative Agile Approach

Timeboxing

MoSCoW Prioritisation of Requirements

Estimation

Project Management and Project Planning

Risk Management

Quality Management

Measurement

Workshops

Models and Modelling

Prototypes

Testing

Configuration Management

Agile Phases

Pre-Project

Feasibility Analysis and Study

Business Analysis and Study

Functional Model Iteration

Design and Build Iteration

Implementation

Post-Project

Page 30: Implementing agile iterative project delivery approach and achieving business responsiveness

August 16, 2010 30

Using Agile Effectively and Productively

Agile Approach Suitability Checklist

Solutions and Projects When

to Use Agile

Agile Project Critical Success

Factors

Key Principles of Iterative

Agile Approach

Page 31: Implementing agile iterative project delivery approach and achieving business responsiveness

August 16, 2010 31

Checklist of Suitability of Projects for Agile Iterative Approach

• Do the sponsor and management understand and accept the agile philosophy as their buy-in is essential?

• Will the team members be empowered to make decisions?

• Is there senior user commitment to provide end user involvement?

• Can the organisation accommodate the frequent delivery of increments?

• Will it be possible for the project team to have access to the users throughout the project?

• Will the project team remain the same throughout the project as stability of the team including the user representatives is important?

• Will the project team have the appropriate skills including technical skills, knowledge of the business area?

• Will the individual project teams consist of six people or less?

• Will the project use technology suitable for prototyping?

• Is there a highly demonstrable user interface?

• Is there clear ownership?

• Will the solution development be computationally non-complex as the more complex the development the greater the risks involved?

• Can the solution be implemented in increments if required?

• Has the development a fixed timescale?

• Can the requirements be prioritised with a mix of Must Haves, Should Haves, Could Haves and Want to Have but Won't Have This Time?

• Are the requirements not too detailed and fixed so users can define requirements interactively?

Page 32: Implementing agile iterative project delivery approach and achieving business responsiveness

August 16, 2010 32

Solutions and Projects When to Use Agile

• Solution that is interactive, where the functionality is clearlydemonstrable at the user interface− Agile is based on incremental prototyping with close user involvement− User must be able to assess the functionality easily through viewing and

operating working prototypes

• Solution that has a clearly defined user group− If the user group is not clearly defined, there may be a danger of driving the

solution from a wrong viewpoint or ignoring some important aspect of the project entirely

• Solution that is computationally complex, the complexity can be decomposed or isolated− If the internals of the solution are hard to understand via the user interface

then there is a risk− Level of computational complexity is often quite difficult to determine in

advance − Interactions between different components that can be difficult to identify up

front

Page 33: Implementing agile iterative project delivery approach and achieving business responsiveness

August 16, 2010 33

Solutions and Projects When to Use Agile

• Solution that is large, possesses the capability of being split into smaller functional components− If the proposed solution is large it should be possible to break it down into small,

manageable chunks, each delivering some clear functionality− These can then be delivered sequentially or in parallel− Each sub-project must be constantly aware of the overall system architecture

• Solution that is time-constrained− There should be a fixed end date by which the project must be completed− If there is no real case for the end date to be fixed, it will be relatively easy to allow

schedules to slip and the fundamental benefits of agile approach will be lost

• Solution where requirements can be prioritised− Requirements should be able to be prioritised using the MoSCoW rules

• Solution where requirements are unclear or subject to frequent change− In periods of rapid change it may be difficult to specify the requirements in detail at the

outset of the project making traditional approaches unsuitable− Agile approach is designed specifically to deal with requirements that change and

evolve during a project− Applications that are difficult to specify in advance because the users do not know

exactly what is needed at the outset

Page 34: Implementing agile iterative project delivery approach and achieving business responsiveness

August 16, 2010 34

Solutions and Projects When Not to Use Agile

• Process control/real-time applications

• Requirements that have to be fully specified before any programs are written

• Safety-critical applications

• Solutions aimed at delivering re-usable components

Page 35: Implementing agile iterative project delivery approach and achieving business responsiveness

August 16, 2010 35

Agile Project Critical Success Factors

• Acceptance of the agile approach before starting work

• Delegation of decision-making to the business people and developers in the development team

• Commitment of senior business management to provide significant end-user involvement

• Incremental delivery

• Easy access by developers to end-users

• Stability of the team

• Project team should be highly skilled people in terms of both the business area as well as the technical environment

• Size of the project team should be small in order to minimise the overheads of management and communication

• Solution technology that allows iterative development, demonstrable work products and control of versions

Page 36: Implementing agile iterative project delivery approach and achieving business responsiveness

August 16, 2010 36

Key Principles of Iterative Agile Approach

• Iterative agile approach requires acceptance of key principles

1. Active user involvement is essential

2. Collaborative and co-operative approach between all stakeholders is essential

3. Agile project team must be allowed make decisions

4. Focus is on frequent delivery of products

5. Fitness for business purpose is the essential measure for acceptance of deliverables

6. Iterative and incremental development is necessary to converge on an accurate business solution

7. All changes during solution implementation are reversible

8. Requirements are baselined at a high level

9. Testing is integrated and performed throughout the lifecycle

Page 37: Implementing agile iterative project delivery approach and achieving business responsiveness

August 16, 2010 37

Principle 1 - Active User Involvement is Essential

• Agile is user-centered

• If users are not closely involved throughout the project lifecycle, delays will occur during decisions making

• Users may feel that the final solution is imposed by the project team and/or their own management

• Users are not outside the project team acting as suppliers of information and reviewers of results but are active participants in the project process

• User and thus business commitment is fundamental to success

Page 38: Implementing agile iterative project delivery approach and achieving business responsiveness

August 16, 2010 38

Principle 2 - Collaborative and Co-operative Approach Between All Stakeholders is Essential

• The nature of agile projects means that low-level detailed requirements are not necessarily fixed when the team is assembled to perform the work

• The short-term direction that a project takes must be quickly decided without the use of restrictive change control procedures

• The stakeholders include not only the business and development staff within the project, but also other staff such as service delivery and resource managers

• When development is procured from an external supplier, both thevendor and the purchaser organisations should aim for as efficient a process as possible while allowing for flexibility during both the pre-contract phase and when the contracted work is carried out

− Can be difficult and needs substantial mutual trust

Page 39: Implementing agile iterative project delivery approach and achieving business responsiveness

August 16, 2010 39

Principle 3 - Agile Project Team Must Be Allowed Make Decisions

• Project teams must be mixed and consist of both IT personnel and users

• Project teams must be able to make decisions as requirements are refined and possibly changed

• Project teams must be able to agree that defined levels of functionality, usability, etc. are acceptable without frequent need to refer to higher-level management

Page 40: Implementing agile iterative project delivery approach and achieving business responsiveness

August 16, 2010 40

Principle 4 - Focus is on Frequent Delivery of Products

• A product-based approach is more flexible than an activity-based one

− Products include interim development products, not just delivered solutions

• Work of a project team is concentrated on products that can be delivered in an agreed period of time

• Enables the team to select the best approach to achieving the products required in the time available

• By keeping each period of time short, the team can easily decide which activities are necessary and sufficient to achieve the right products

Page 41: Implementing agile iterative project delivery approach and achieving business responsiveness

August 16, 2010 41

Principle 5 - Fitness for Business Purpose is the Essential Measure for Acceptance of Deliverables

• Focus of agile is on delivering the necessary functionality at the required time

• Traditional project focus has been on satisfying the contents of a requirements document and conforming to previous deliverables, even though the requirements are often inaccurate, the previous deliverables may be flawed and the business needs may have changed since the start of the project

• Solution can be more rigorously engineered subsequently if such an approach is acceptable

Page 42: Implementing agile iterative project delivery approach and achieving business responsiveness

August 16, 2010 42

Principle 6 - Iterative and Incremental Development is Necessary to Converge on an Accurate Business Solution

• Agile iterative approach allows systems to grow incrementally

• Therefore the project team can make full use of feedback from the users

• Partial solutions can be delivered to satisfy immediate businessneeds

• Agile approach uses iteration to continuously improve the solution being implemented

• When rework is not explicitly recognised in a project lifecycle, the return to previously "completed" work is surrounded by controlling procedures that slow development down

• Rework is built into the agile iterative approach process, the solution can proceed more quickly during iteration

Page 43: Implementing agile iterative project delivery approach and achieving business responsiveness

August 16, 2010 43

Principle 7 - All Changes During Solution Implementation are Reversible

• To control the evolution of all products (documents, software, test products, etc.), everything must be in a known state at all times

− Configuration management must be all-pervasive

• Backtracking is a feature of agile iterative approach

− Sometimes it may be easier to reconstruct than to backtrack depending on the nature of the change and the environment in which it was made

Page 44: Implementing agile iterative project delivery approach and achieving business responsiveness

August 16, 2010 44

Principle 8 - Requirements are Baselined at a High Level

• Baselining high-level requirements involves "freezing" and agreeing the purpose and scope of the system at a level that allows for detailed investigation of what the requirements imply

• Further, more detailed baselines can be established later in the project

− The scope should not change significantly

• Changing the scope defined in the baselined high-level requirements generally requires escalation

Page 45: Implementing agile iterative project delivery approach and achieving business responsiveness

August 16, 2010 45

Principle 9 - Testing is Integrated and Performed Throughout the Lifecycle

• Testing is not treated as a separate activity

• As the solution is developed incrementally, it is also tested and reviewed by both the project team and users incrementally

− Ensures that the project is moving forward not only in the rightbusiness direction but is also technically sound

• Early in project lifecycle, the testing focus is on validation against the business needs and priorities

• Towards the end of the project, the focus is on verifying that the whole system operates effectively – system and integration testing

Page 46: Implementing agile iterative project delivery approach and achieving business responsiveness

August 16, 2010 46

Control Components of Agile Process

• Since agile iterative projects are flexible in their development activities all aspects of their management need to be flexible while maintaining a level of control that ensures successful delivery of the required business solution

• Key control techniques and components− Timeboxing

−MoSCoW prioritisation of requirements

− Estimation

− Project management and project planning

− Risk management

− Configuration management

−Measurement

Page 47: Implementing agile iterative project delivery approach and achieving business responsiveness

August 16, 2010 47

Timeboxing

• Very important aspect of agile iterative process and projects

• Process to reach defined objectives at a pre-determined and fixed date through continuous prioritisation and flexing of requirements using the MoSCoW control rule

• Timebox is a fixed interval of time - typically between two and six weeks in length but the shorter the better

• Without the control of timeboxing, project teams can lose their focus and run out of control

• Used at various stages of project− Project end-date is fixed and the overall business objectives to be achieved by that date

are defined − End date for each increment within the project is fixed and the prioritised set of

business and technical requirements to be satisfied by that date are defined − End date for phase level activities is fixed, e.g. for the Feasibility Study, and the

objectives for this project defined − End date for part of the prototyping activity is fixed and the prototype is created,

reviewed and tested according to the objectives defined in the timebox schedule contained in the Development Plan

− End time for a workshop, meeting or review is fixed and the participants work to the predefined and prioritised objectives

Page 48: Implementing agile iterative project delivery approach and achieving business responsiveness

August 16, 2010 48

Timeboxing

• A timebox must have an agreed scope and clear objectives based on a subset of the prioritised requirements list

• With timeboxing control is not activity-based

• Objective of a timebox is to make a product - produce something tangible in order for progress and quality to be assessed

• How that product is put together will be decided by the people doing the work, as long as the project's standards and procedures are followed

• Team working in the timebox must agree the objectives and must themselves estimate the time required

• At the deadline, the users must be able to approve the delivery of the products covered by the timebox

• If it appears that deadlines could be missed, the deliverable should be de-scoped dropping the lower priority items

• Detailed planning of a subsequent timebox containing dependent work cannot be started before the current timebox is complete

Page 49: Implementing agile iterative project delivery approach and achieving business responsiveness

August 16, 2010 49

Timebox Plan

• Plan for an individual timebox within Functional Model and Design and Build Iteration phase

• Purpose and objectives

• Define the products of an individual timebox

• Define key milestones, e.g. technical or user review dates, within a timebox

• Agree the prioritisation of products and activities within a timebox

Page 50: Implementing agile iterative project delivery approach and achieving business responsiveness

August 16, 2010 50

Timeboxing and Daily Meetings

• During each timebox, the team working on the timebox should meetdaily to review their progress and to raise issues

− Provides the team with evidence regarding their progress and the problems they face

− Highlight risks as they occur

− Each daily meeting should be limited at 30 minutes and ideally lasts no longer than 15 minutes

− All team members attend

• Agenda

− What work has been completed for this timebox since the last daily meeting?

− What (if anything) got in the way of completing the planned work?

− What work will be done between now and the next daily meeting?

Page 51: Implementing agile iterative project delivery approach and achieving business responsiveness

August 16, 2010 51

Timebox Plan Questions and Checklist

• Are the estimates of effort reasonable? Were they produced by the people doing the work?

• Have acceptance criteria been agreed for the products of the timebox? If they have not, is it clear when these will be available?

• Is there a high degree of certainty that the Must Haves will be created, developed and tested to the required standard?

• Are the review dates agreed with all key personnel?

• Have lessons learnt in previous timeboxes been applied?

• Can the team commit to delivering at least the Must Haves by theagreed end date?

Page 52: Implementing agile iterative project delivery approach and achieving business responsiveness

August 16, 2010 52

MoSCoW Prioritisation of Requirements

• MoSCoW−Must Have

• Requirements that are fundamental to the system

• Without them the system will be unworkable and useless

• Must Haves define the minimum usable subset

• Agile project guarantees to satisfy all the minimum usable subset

− Should Have • Important requirements for which there is a workaround in the short term

and which would normally be classed as mandatory in less time-constrained development, but the system will be useful and usable without them

− Could Have • Requirements that can more easily be left out of the increment under

development

−Want to Have but Won't Have This Time • Requirements that can wait till later development takes place - the Waiting

List

Page 53: Implementing agile iterative project delivery approach and achieving business responsiveness

August 16, 2010 53

MoSCoW Prioritisation of Requirements

• Delivering on a guaranteed date means that what was originally envisaged for an individual delivery may have to be left out

• Important that essential work is done and that only less critical work is omitted

• Means of ensuring that this is true is clear prioritisation of the requirements

• Provides a basis on which decisions are made about what the project team will do over the whole project, within an increment of the project and during a timebox within an increment

• As new requirements arise or as existing requirements are defined in more detail, the decision must be made as to how critical they are to the success of the current work using the MoSCoW approach− All priorities should be reviewed throughout the project to ensure that they are still

valid

• Essential that not everything to be achieved within a project or a timebox is a Must Have− Having lower level requirements that enable teams to deliver on time by dropping out

lower priority requirements when problems arise

Page 54: Implementing agile iterative project delivery approach and achieving business responsiveness

August 16, 2010 54

MoSCoW Prioritisation of Requirements

• Solution functionality is prioritised and delivered according to available time and resources but time and resources are fixed

Page 55: Implementing agile iterative project delivery approach and achieving business responsiveness

August 16, 2010 55

Estimation

• Estimation provides the information that is required for two main purposes:

−Assess project feasibility by evaluating costs and benefits

−Use in project planning, scheduling and control

• Estimation in agile iterative projects

− Estimates should be tight from the outset with frequent deliverables

• Not unacceptable for activity overrun and for long timescales for agreeing the quality of products

− Estimates that are based on outline business functions provide the closest match with the agile iterative process

• Starting point for estimating should be the expected functionality of the end products rather than the activities used to deliver those products

Page 56: Implementing agile iterative project delivery approach and achieving business responsiveness

August 16, 2010 56

Estimation

• Estimation is a conditional forecast based on the information available at the time − An extrapolation from past and current knowledge to the future

− Cannot be done with complete certainty because the future is unknown, therefore the actual effort or cost to deliver will almost always be different to the estimate

− Better the quality of the information available for estimating, the closer the estimate is likely to be to the actual figures

• Estimation must be based on a defined process so that it is rigorous and repeatable− Whatever process is used the primary information required to estimate is:

• Scope of what is to be delivered

• Delivery capability

• Contingency must be included in any estimate in order for it to be realistic− estimates are conditional forecasts that will be affected by future events both internal

and external to the project

− Events cannot be known with certainty and the estimate must make reasonable allowance for them

− Solution development itself is not an exact science

− The size of the contingency in an estimate must reflect the degree of uncertainty

Page 57: Implementing agile iterative project delivery approach and achieving business responsiveness

August 16, 2010 57

Estimation

Pre-project Phase Estimation

Feasibility Study Phase Estimation

Business Study Phase Estimation

Before the project begins properly an estimate must be prepared for the work to be done during Feasibility Study phase

Estimate could be a timebox - a fixed team for a fixed period - or could be based on a schedule of workshops and the associated effort to complete the products

First estimate for the whole project is prepared towards the end of Feasibility Study

Rough estimate, based on high level requirements - assist management to assess the value and practicality of continuing with the project

Second estimate is produced at the end of the Business Study - scope of the project is decided, the necessary business functionality to be delivered is defined and prioritised, and the system architecture is defined

Detailed estimate as it based on the likely major components of the delivered solution identified from the prioritised requirements

Estimate must reflect a level of risk and confidence that is acceptable to the relevant stakeholders

Purpose of this estimate is to plan and schedule the project and used to re-evaluate the Business Case to assess whether the project is still viable

Page 58: Implementing agile iterative project delivery approach and achieving business responsiveness

August 16, 2010 58

Estimation

Functional Model Iteration Phase and Design and Build Iteration

Phase Estimation

Implementation Phase Estimation

Detailed estimate from Business Study provides the basis for the whole project, and throughout the remainder of the project this estimate is frequently monitored and revised

Estimation is performed for each timebox to assess whether the timebox plan is achievable, and to evaluate the impact on the project if any revisions to the estimate are required

Before the start of each timebox an estimate for the expected work is carried out to ensure that it remains achievable in light of project experience to date

If there is significant deviation from the estimates, the original estimates should be carefully reviewed

Until the Implementation Plan is prepared during Functional Model Iteration, there are only very high level estimates available for this phase

Before the Implementation phase begins, the estimates must be reviewed to ensure they are still reasonable

Page 59: Implementing agile iterative project delivery approach and achieving business responsiveness

August 16, 2010 59

Estimation Techniques

• Top Down - estimating by comparison where the proposed project is compared to similar completed projects− Based on the business requirements (rather than system components)

− Give a figure for the project as a whole, which may be broken down into phases on a pro rata basis

− Fast to prepare

− Can be derived from very high level requirements

− Give a high level view of the project (its overall cost and timebox) which can be used in evaluating the feasibility of the project

• Bottom Up - counting components and other implementation-related information shown in a design and estimating the effort for each of those − Based on tangible system components

− Give detailed figures for low level components of the project which can be aggregated to give higher level views

− Take time to prepare

− Need sufficiently detailed information to allow identification of system components

− Provide a good basis for project planning, scheduling and management

Page 60: Implementing agile iterative project delivery approach and achieving business responsiveness

August 16, 2010 60

Collaborative Estimation

• Facilitated workshop can be an excellent approach to gaining both sound estimates and buy-in to these estimates from the team and the stakeholders

• Participants should, between them, have expertise in all the main technical and business areas covered by the project

• Project management and estimation participants

• Estimation workshops require considerable preparation in order to achieve their objectives

Page 61: Implementing agile iterative project delivery approach and achieving business responsiveness

August 16, 2010 61

Estimation Guidelines

• Use more than one technique to allow cross-checking, e.g. top-down and bottom-up

• Produce estimates by workshops involving all stakeholders, rather than by individuals

• Ensure the estimate includes sufficient effort for all timebox activities not just those directly resulting in business functionality, including− Project management, team leading, technical co-ordination − User involvement − Non-functional requirements and technical products − Specialist roles, such as business and technical consultants, quality and test managers, security

specialists, etc.− Specialist roles, such as business and technical consultants, quality and test managers, security

specialists, etc.− Workshop preparation, attendance and follow up, including facilitation and scribing − Completion of project documentation − Quality reviews, inspections, walkthroughs, timebox planning and estimating − Travel and meetings particularly if cross-site − Mentoring if project and/or organisation is new to agile iterative projects − Specialist testing such as stress and performance, or operational acceptance.

• Ensure all areas of development are included: avoid focus on pure coding effort

• Capture project metrics and feed back actuals vs. estimates into the estimating process

• Ensure that anyone who estimates is trained, particularly for specialist techniques such as function point analysis

Page 62: Implementing agile iterative project delivery approach and achieving business responsiveness

August 16, 2010 62

Project Management

• Aim of project management is to deliver the right solution on time and on budget using the available resources wisely

• Management of traditional projects is about control

− Preventing drift from the signed off specification, controlling resources, etc.

• Managing an agile project is about enabling constant change while continuously correcting the course of the project in order to maintain its aim at the target - a fixed delivery date for a usable system

• To be successful with agile iterative approach, the organisation may have to change organisational, social and technical elements at the same time

• All impact on the management of the project

Page 63: Implementing agile iterative project delivery approach and achieving business responsiveness

August 16, 2010 63

Project Management

• For tradition projects, the project manager has a detailed plan against which to monitor and control activities

• In an agile and iterative project, there are typically more activities going on in parallel

− Project Manager has a number of distinctive responsibilities to ensure that the project is under control in each phase

• Speed of progress can pose some difficulties for managers from atraditional background in IT project management

− If problems arise during a timebox then it is often tempting for the traditional manager to renegotiate the end date as that is what they would normally do

− In an agile project, the timebox deadline is fixed usually because it is set by the business need

− Consequently, the approved approach is to renegotiate the content of the timebox rather than its duration

Page 64: Implementing agile iterative project delivery approach and achieving business responsiveness

August 16, 2010 64

Project Management

• In the agile iterative collaborative approach, there is a great deal of interaction between users and implementers in task completion

• Important that communication is clear and concise if rapid development is to be achieved

• Agile projects should have an informal but planned communicationprocess

• As each timebox is completed, it is the responsibility of the Project Manager to ensure that there is a clear understanding about what is to be delivered in the following timeboxes and to ensure that the relevant requirements are established in detail

− Likely that the users will change their minds about priorities and requirements

− Project Manger must be open to making such changes whilst ensuring that any consequences are fully understood by the users

Page 65: Implementing agile iterative project delivery approach and achieving business responsiveness

August 16, 2010 65

Project Management

Pre-project Phase

Feasibility Study Phase

Business Study Phase

• Initial planning• Verify suitability of profile for agile approach• Agree project review and termination evaluation and decision factors• Confirm user involvement • Give training in agile approach for all people new to the method• Schedule workshop facilitators

• Set up the Feasibility Study team• Attend all workshops• Review/accept and get signoff for the Feasibility Report• Ensure that all key stakeholders have bought in to the Prioritised Requirements List and

the proposed timescales for (incremental) delivery for the project• Create a high-level Business Case for the project• Create the Outline Plan• Schedule Business Study workshop

• Manage production of the Business Study products• Attend all workshops• Review and update project risks• Create the Development Plan jointly with all relevant people• Refine the Business Case and get it agreed by the relevant people• Obtain agreement to proceed into development • Ensure that all project Team Leaders are aware of the contents of the Business Case so

that they can use it as the basis for negotiation about what is important within their timeboxes

Page 66: Implementing agile iterative project delivery approach and achieving business responsiveness

August 16, 2010 66

Project Management

Functional Model Iteration Phase

Design and Build Iteration Phase

Implementation Phase

• Agree individual Timebox Plans with the Team Leaders• Participate in timebox kick-off and closeout meetings• Accept all timebox deliverables to the project at each timebox closeout meeting• Monitor the team(s)• Create the Implementation Plan jointly with all relevant people• Publish the Implementation Plan and get it agreed by the relevant people before the end

of the last pass through the Functional Model Iteration

• Agree individual Timebox Plans with the relevant Team Leader• Participate in Timebox kick-off and closeout meetings• Accept all timebox deliverables to the project at each timebox closeout meeting• Monitor the team(s)

• Manage the migration of the system to the operational environment• Ensure all necessary training takes place in a timely way• Run the Increment Review workshop and produce the Increment Review Document• Obtain sign-off of the increment from all relevant parties• Plan the next increment if there is one• For the last increment, set the date for the Post-Implementation Review

Page 67: Implementing agile iterative project delivery approach and achieving business responsiveness

August 16, 2010 67

Project Management

Post-project Phase • Ensure all lessons learnt are made available to other projects• Participate in the Post-Implementation Review

Page 68: Implementing agile iterative project delivery approach and achieving business responsiveness

August 16, 2010 68

Project Planning

• The purpose of project planning is to ensure the success of the project

• For agile projects planning is not just an activity that takes place at the beginning of the project - it continues throughout the lifecycle

• Planning an agile project can be especially difficult for a project manager used to traditional methods

• Agile project plans evolve with more and more detail as the project progresses, as requirements are progressively refined and as lessons are learnt

• Plan should address all products generated by, and activities undertaken in, the project− Includes the deliverable products (prototypes, models, documentation, etc.)

• Project initiation

• Configuration management

• Change control

• Product breakdown structure

• Product descriptions

• Risk management

• Work instructions

Page 69: Implementing agile iterative project delivery approach and achieving business responsiveness

August 16, 2010 69

Project Planning

• Traditional project planning− Focus on agreeing a detailed "contract" with customers about the totality of

the system to be delivered along with the costs and timescales

− Concerned with understanding the requirements in complete detail so that the right level of resources can be secured and an estimate of the completion time can be made

− Plan is created in a great detail and is ideally executed with minimal change

• Agile project planning− Focus on setting up a collaborative relationship with the customers, bringing

them fully into the make-up of the team

− Concerned with agreeing with the users the process by which the business requirements will be met

− Initial plans are created in sufficient detail to establish the main parameters of the project and with the firm expectation that the customers will change the plan during the course of the project as they gain a deeper understanding of their needs

Page 70: Implementing agile iterative project delivery approach and achieving business responsiveness

August 16, 2010 70

Pre-project Phase Planning

• Objective of pre-project planning is to provide the basis for carrying out the project successfully

• Understand the requirements just sufficiently to assess the risks and suitability of the project for an agile approach

• Establish the right conditions for the project with the user management

• Ensure that the managers from the business have agreed to release their staff into the development team for significant periods of time (including full-time secondment when the project requires it)

• Agree a definition of "fitness for business purpose" for the system being developed with the business

Page 71: Implementing agile iterative project delivery approach and achieving business responsiveness

August 16, 2010 71

Agile Project Plans

Feasibility Study Phase

Business Study Phase

Outline Plan

Means to define and agree the terms and conditions for a successful project and contains as a detailed plan for the Business Study

Functional Model Iteration Phase and

Design and Build Iteration

Phase

Implementation Phase

Development Plan

How the project will be carried out and in particular which prototypes will be built and when

Timebox Plan at the start of each timebox

Refines the Development Plan where each Timebox Plan contains at least one complete cycle of the Functional Model Iteration or Design and Build Iteration for part of the system

Implementation Plan

Defines how the successful implementation of the solution will be achieved

Page 72: Implementing agile iterative project delivery approach and achieving business responsiveness

August 16, 2010 72

Agile Planning Success Factors

• The contents of timeboxes are crucial

• Plan for deliverables and not activities− Consider the key questions "who, when what, where, how" when planning

• Define quality criteria for each deliverable

• Plan for frequent delivery of products− Distinguish "delivery to the project" from "delivery to the end user population"

• Focus of planning and control in agile projects is on sustaining a high rate of progress, agreeing priorities, keeping relationships healthy, learning as the project progresses, and allowing plans to evolve based on experience gained

• Make project planning work by focusing on principles, products, and people rather than methods and techniques

• Manage expectations by planning appropriate briefings and training on agile approach, addressing roles and responsibilities, and defining and agreeing products and acceptance criteria

• Plan for the use of experienced mentors where there is insufficient experience in the team

• Plan to do the work during normal working hours

• Plan contingency only for prerequisites (software, hardware, setup, etc.) but not for time or resource on the project itself− Contingency in agile is managed through prioritisation of requirements

• Plan for regular daily team meetings

• Plan formal reviews at the end of each timebox and establish dates in diaries early

• Plan early for testing interfaces, theoretical performance analysis, and performance prototyping

Page 73: Implementing agile iterative project delivery approach and achieving business responsiveness

August 16, 2010 73

Agile Planning Problems

• Objectives and requirements that are either too vague or too detailed

• Failure to architect the approach

• Frequent changes to the schedule for user involvement

• Incomplete and conflicting information

• Introducing too much change at one time

Page 74: Implementing agile iterative project delivery approach and achieving business responsiveness

August 16, 2010 74

Risk Management

• Ongoing process throughout the life of a project

• Actively control all the risks facing a project or the implementation of the solution it is delivering− Identification of any and all risks that may threaten the project for

business, systems or technical reason

−Assessment of the impact of those risks on the success of the project should they arise and deciding on the likelihood of the risk occurring and if it does on the severity of its impact on the project

−Management of those risks through defining specific countermeasures that are aimed at either avoiding the identifiedrisks or accepting them and minimising their detrimental effect on the project

−Applying the appropriate countermeasures when a risk materialises

Page 75: Implementing agile iterative project delivery approach and achieving business responsiveness

August 16, 2010 75

Risk Management

• Risks must be identified and their impact assessed as early as possible

• Risks should be continuously reviewed throughout the life of theproject, particularly at critical go/no go decision points within the project such as the end of the Business Study and before initiating the development of a new increment

• All risks should be assessed in terms of their potential impact

• Risks must be actively managed through countermeasures to minimise their possible impact

• The emphasis of risk management activities should be on the risks with the highest levels

• Projects with risks determined as unacceptable by the Executive Sponsor should not be started

• Projects whose risks rise to an unacceptable level should be stopped

Page 76: Implementing agile iterative project delivery approach and achieving business responsiveness

August 16, 2010 76

Risk Log

• Opened at the start of the project to assist management in deciding the future of the project− Class of risk (business, systems or technical)− Description of the risk - should be in sufficient detail to be understood by all interested

parties but short enough to enable a checklist approach to risk monitoring throughout the project

− Likelihood of the risk occurring (high, medium or low)− Severity of impact on the project should the risk occur (high, medium or low) − One or more proposed countermeasures, which will mitigate the risk either by

preventing it occurring or by containing when it arises• Countermeasures should include the dates beyond which they are no longer applicable

− The status of the risk (open or closed), open risks are still possible, closed risks have either happened and have been dealt with or the time at which they were likely to happen has passed

− Owner of the risk (who is responsible for monitoring the risk and/or implementing any countermeasures)

• Checklist− Are all the factors potentially affecting the success of the project discussed? − Are risks sufficiently quantified for a decision to be made? − Does each risk have at least one countermeasure identified?

Page 77: Implementing agile iterative project delivery approach and achieving business responsiveness

August 16, 2010 77

Quality Management

• Quality of an information technology solution often defined in terms of the way in which that system provides the capability and support required by the user

• Agile approach designed to ensure the quality of the project's products− Facilitated workshops ensure that the system's requirements are properly

considered at the outset

− Continuous and focused user involvement helps to ensure that all parties understand each others - needs and viewpoints

− Reviews (whether of prototypes or of supporting documentation) serve to ensure (and record) that the system continues to meet the needs of the business - the quality criteria against which products should be reviewed are identified the Product Descriptions

− Thorough testing validates the delivered system against its requirements

− Configuration Management and Change Control serve to ensure that quality, once built in to the system, is preserved

Page 78: Implementing agile iterative project delivery approach and achieving business responsiveness

August 16, 2010 78

Quality Planning

• Quality planning should be an integral part of the project planning activity− Identification of which products are to be produced and which of those

warrant specific quality-related activities − How the quality of each type of product is to be checked - for example by

review and/or by testing − When quality checks are to be performed; and whether they are they optional

or mandatory, whether or not all examples of a particular type of product must be checked or only a sample, and whether items are checked during development or only on completion

− Who is responsible for reviewing and testing each product, who has authority to accept the product and what is to happen if such a review or test is unsuccessful

− Which criteria are to be used to assess each product's quality - typically by reference to the quality criteria defined in each of the Product Descriptions

− Which procedures are to be used to define quality-related processes − Which records are to be kept to document decisions and actions taken − Which standards are to be applied to products (for example, coding standards

and user interface style guides)

Page 79: Implementing agile iterative project delivery approach and achieving business responsiveness

August 16, 2010 79

Quality Audits

• Audit projects from time to time in order to determine their compliance with the organisation's procedures, practices and standards

• Very important in agile projects that such audits are not allowed to result in unnecessary rework or ineffective effort expenditure

• Greatest benefit obtained from audits is frequently in causing corporate procedures, practices and standards to be revised in the light of real experience

• Agile-specific audit questions− Is the user involvement there? − Are the users empowered? − Is the life-cycle being followed? − Are comments from prototype reviews being incorporated? − Is backtracking allowed when necessary? − Are priorities being adhered to? − Are timeboxes being respected?

Page 80: Implementing agile iterative project delivery approach and achieving business responsiveness

August 16, 2010 80

Measurement

• Measurement is necessary in order to:− Establish a baseline for predicting what will happen in the future

− Provide evidence that the process is successful and working

− Investigate the process itself in order to highlight and quantify problems

• Can provide the information to convince management that the introduction of agile iterative approach can provide tangible benefits to the organisation

• Projects should keep careful records of defects classified by severity and type

• Success of a project will be whether or not it achieved the stated objectives so these should be described in precise measurable terms− Agile approach is focused on satisfying all of the "must haves" within a fixed

elapsed time frame so any measurement of success needs to include all of these

Page 81: Implementing agile iterative project delivery approach and achieving business responsiveness

August 16, 2010 81

Agile Tools and Techniques

• Tools and techniques that are applied to agile projects

−Workshops

−Models and Modelling

− Prototypes

− Testing

− Configuration Management

Page 82: Implementing agile iterative project delivery approach and achieving business responsiveness

August 16, 2010 82

Workshops

• Workshop is a structured approach to ensure that a group of people can reach a predetermined objective in a compressed timeframe supported by an impartial facilitator

• Benefits− Rapid, quality decision-making

• Because all stakeholders are present at the same time, there is great confidence in the result• Group is focused on the objectives to be achieved in the session so that the information gathering and review cycle is

performed at a greater speed• Misunderstandings and disagreements can be worked out at the time• Concerns should therefore have been raised and resolved or noted by the end of the workshop

− Greater user buy-in• Workshops, run effectively, lead to participants feeling more involved in the project and decisions being made• Build and maintain enthusiasm

− Building team spirit• Controlled way of building rapport as well as delivering• Promotes understanding and co-operation between departments - important when a solution involves many groups

− Process redesign by the user community• If practices are reviewed as a result of a workshop, participants can gain a greater understanding of the inputs and implications

of their work• Leads to improved efficiencies that are led by the participants themselves, giving greater buy-in and commitment • Greater chance of successful implementation

− Clarification of requirements when they are unclear• Business users can be led through their objectives and processes to define what they may require• Participants can explore and model ideas• Successful through a combination of structured discussion and the presence of knowledgeable participants

Page 83: Implementing agile iterative project delivery approach and achieving business responsiveness

August 16, 2010 83

Applying Iterative Agile Principles to Workshops

• Active user involvement is essential− Workshops provide an ideal format for the business to be directly involved in planning, designing and implementing a solution

• A collaborative and co-operative approach between all stakeholders is essential− Create a climate of co-operation within the workshop and enforcing any ground rules for the group to behave effectively− Only possible with the co-operation and commitment of all stakeholders− Effective way of achieving either compromise or consensus

• Agile project team must be allowed make decisions− Workshop participants need to be empowered and have the right level of knowledge and authority within the scope of the workshop, so that decisions can be

made without delay

• Focus is on frequent delivery of products− Structure a workshop so that there are intermediate deliverables− Helps to order participants' thinking as they progress in logical steps− Enables them to work towards an ultimate goal and gives them a growing sense of achievement as the workshop progresses

• Fitness for business purpose is the essential measure for acceptance of deliverables− Fitness for purpose is achieved by keeping participants focused on delivery against an agreed set of objectives− Ensure all are involved in decision-making

• Iterative and incremental development is necessary to converge on an accurate business solution− Strength of workshops is the synergy achieved by the group− Ideas do not have to be born fully developed but can grow during discussion− Ideal setting to try out ideas with all stakeholders and it is up to the facilitator to provide a safe environment in which this can happen

• All changes during solution implementation are reversible − Information and decisions should be recorded as necessary by either one or both of the facilitator and scribe so that ideas can be backtracked where necessary− Often what happens in practice is that an idea or decision is redeveloped

• Requirements are baselined at a high level− Objectives must be set during the preparation for a workshop− As the workshop progresses, information is gathered, analysed and interpreted so that discussion can be effective and a decision reached as a result of an

increased understanding of the issues involved

• Testing is integrated and performed throughout the lifecycle− Because all stakeholders are present, workshop provides the quality control approach of testing ideas and deliverables as they are discussed− Participants can challenge or agree

Page 84: Implementing agile iterative project delivery approach and achieving business responsiveness

August 16, 2010 84

Models and Modelling

• Modelling helps the project team gain a good understanding of a business problem, issue or process

• Accurate models reflect the realities of the business world

• Understanding can be gained by analysing the problem from different viewpoints− Business View - uses a selection of techniques to understand and interpret the business

need and to model the business from a future perspective− Processing View - models the system as a set of business processes, or activities, which

transform input data items to output data items• Processes can be either combined to form higher level processes, which in turn can be

combined again to form yet higher level processes, or decomposed into their constituent sub-processes

• Corresponds to the traditional "Why, What and How" type of questioning used during requirements elicitation

− Data View - models the business information as a set of objects, or entities, and the relationships that exist between these objects

− Behavioural View - models the behavioural characteristics of the system in terms of a set of events and states, where events cause changes in the states of the system. Events may be generated within or external to the system

− User Interface View - models the interactions and interfaces between the system user and the system itself

Page 85: Implementing agile iterative project delivery approach and achieving business responsiveness

August 16, 2010 85

Prototypes

• Prototypes provide the mechanism through which users can ensure that the detail of the requirements is correct

• Demonstration of a prototype broadens the users' awareness of the possibilities for the new system and assists them in giving feedback to the project team

• Accelerates the development process and increases confidence that the right system is being built

• Types of prototype− Business - demonstrating the business processes being automated

− Usability - investigating aspects of the user interface that do not affect functionality

− Performance and Capacity - ensuring that the system will be able to handle full workloads successfully

− Capability/Technique – testing a particular design approach or proving a concept

Page 86: Implementing agile iterative project delivery approach and achieving business responsiveness

August 16, 2010 86

Testing

• In agile projects testing takes place throughout the project lifecycle

−Validation - check that a system is fit for business purpose

−Benefit-directed testing - testing the parts of the solution that deliver the key business benefits is the highest priority

− Error-centric testing - objective of designing and running a test is to find an error

− Testing throughout the lifecycle - performed on all products at all stages of the project

− Independent testing - a product should be tested by someone other than its creator

−Repeatable testing - tests must be repeatable

Page 87: Implementing agile iterative project delivery approach and achieving business responsiveness

August 16, 2010 87

Testing

• Testing activities must be prioritised based on the business goals

− Overall business process performance (i.e. business processing cycle times)

− Large processing volumes (i.e. very frequently occurring events)

− Labour-intensive or complex business tasks

− Human computer interface, particularly if the computer system will be visible to customers

• Efficient use of time available can be made through risk based testing

− Identify the risk areas

− Assess the impact of errors

− Plan for risk based testing

− Reduce the risk of errors

Page 88: Implementing agile iterative project delivery approach and achieving business responsiveness

August 16, 2010 88

Configuration Management

• Dynamic nature of ale projects means good configuration management is required

• Many activities are happening at once and products are being delivered at a very fast rate

• Configuration management strategy must be decided and documented in the Development/Implementation Plan before leaving the Business Study phase

Page 89: Implementing agile iterative project delivery approach and achieving business responsiveness

August 16, 2010 89

Iterative Agile Framework

• Solution delivery lifecycle is iterative and incremental

• Solution is not be delivered in one go, but in a series of increments, which increase what it does each time

• Urgent business needs are addressed early while less immediately important functionality is delivered

• Users see work under construction, review and comment on it and request changes during the development of an increment

• Agile approach provides a generic framework for iterative solution delivery

Page 90: Implementing agile iterative project delivery approach and achieving business responsiveness

August 16, 2010 90

Overall Agile Iterative Process - Phases

1. Pre-Project

2. Feasibility Analysis and Study

3. Business Analysis and Study

4. Functional Model Iteration

5. Design and Build Iteration

6. Implementation

7. Post-Project

Page 91: Implementing agile iterative project delivery approach and achieving business responsiveness

August 16, 2010 91

Overall Agile Iterative Process

Feasibility Analysis and

Study

Business Analysis and

Study

Post-ProjectFunctional

Model Iteration

Implementation

Design and Build

Iteration

Pre-Project

Sequential Phases

Iterated Phases

1

2

3

4

5

6

7

Page 92: Implementing agile iterative project delivery approach and achieving business responsiveness

August 16, 2010 92

Iterated Phases

Functional Model

IterationImplementation

Design and Build

Iteration

Identify What Is To Be

Produced

Agree How and When To

Do It

Create The

Product

Check That It Has Been Produced

Correctly

Identify What Is To Be

Produced

Agree How and When To

Do It

Create The

Product

Check That It Has Been Produced

Correctly

Identify What Is To Be

Produced

Agree How and When To

Do It

Create The

Product

Check That It Has Been Produced

Correctly

Page 93: Implementing agile iterative project delivery approach and achieving business responsiveness

August 16, 2010 93

Agile Iterative Sequential and Parallel Phases

Post-Project Phase

Functional Model Iteration Phase

Design and Build Iteration Phase

Implementation Phase

Increment 1 Increment 1 Increment 1

Increment 2 Increment 2 Increment 2

Increment P

Increment M

Increment N

Pre-ProjectPhase

Feasibility Analysis and Study Phase

Business Analysis and Study Phase

Final Increments Prior to Final

Implementation

Page 94: Implementing agile iterative project delivery approach and achieving business responsiveness

August 16, 2010 94

Phase 1 - Pre-Project Phase

• Ensures that only the right projects are selected and that they are set up correctly to ensure success

• Initial definition of the business problem to be addressed

• Decision to proceed with the project

• Project manager assigned to the project

• Initial project governance in place

Page 95: Implementing agile iterative project delivery approach and achieving business responsiveness

August 16, 2010 95

Phase 2 - Feasibility Analysis and Study Phase

• Assessment if iterative agile is the right approach for the project

• Feasibility Study should be short and should last no more than a few weeks

• Consider using workshop(s) to perform feasibility analysis

• Feasibility Study outputs

− Feasibility report

−Outline plan for implementation

− Feasibility prototype

− Solution risk log

Page 96: Implementing agile iterative project delivery approach and achieving business responsiveness

August 16, 2010 96

Feasibility Analysis and Study Report

• Enables the project steering committee to decide not only which option to choose for the way forward and whether or not the project should proceed beyond the Feasibility Study

• Objectives and purposes− Outline the problem to be addressed by the new system− Define the scope of the project or set of projects− Give a preliminary indication of any areas within the scope which may be desirable but not

essential− State, at least in outline, the Business Case for the project(s) - including where possible expected

costs, benefits, assumptions and risks (whether quantifiable or not)− Indicate what alternative solutions have been or could be considered− Define the major products to be delivered by the project− Report on the suitability of an agile approach for use on the project, which may vary for each

solution− Document the objectives of the project including process performance criteria− Document high-level technical and business constraints, e.g. timescale, hardware and software

platforms− Identify whether the system may be safety-related or if there may be any product liability issues− Describe at a high level the business processes and data that are expected to be automated− Identify at a high level the interfaces necessary to existing data and applications− Identify which business processes and/or systems (whether automated or not) might be impacted

by the new system and which might need to change in order to accommodate it− Define the expected life of the computer system and hence the requirements for maintainability

Page 97: Implementing agile iterative project delivery approach and achieving business responsiveness

August 16, 2010 97

Feasibility Analysis and Study Report Questions and Checklist

• Is the problem definition in line with the needs of senior business management?

• Is the scope of the project sufficiently clear for it to be refined within the Business Study?

• Are the business objectives to be met by the development clearly defined?

• Is the solution to the problem, as laid out in the major products to be delivered and in the objectives of the project, feasible in both technical and business terms?

• Is the case for the project approach sound and are the risks acceptable?

• Does management accept what has been included and excluded from the scope?

• Are all associated systems and their interfaces identified?

• Is any impact on those systems acceptable?

• Is the Business Case for the project to proceed valid?

Page 98: Implementing agile iterative project delivery approach and achieving business responsiveness

August 16, 2010 98

Feasibility Prototype

• Feasibility prototype may be produced as a proof of concept for the proposed solution

− To prove one or more of the possible technical solutions contained within the Feasibility Report

− To demonstrate to the business the possible content of the user interface and the look and feel

• Prototype should only be produced if it will really assist the decisions made in the Feasibility Report

Page 99: Implementing agile iterative project delivery approach and achieving business responsiveness

August 16, 2010 99

Outline Plan for Implementation

• First planning product within the project

• Sets deadlines and milestones for various major phases of work and key deliverables (particularly incremental delivery dates)

• Deadlines become the major control points around which the later, lower level plans will be developed

• Provides the detailed plan for how the Business Study phase will be run

Page 100: Implementing agile iterative project delivery approach and achieving business responsiveness

August 16, 2010 100

Outline Plan for Implementation

• Purpose and objectives

− Provide management with ballpark estimates of the financial and resource implications (both project team and user) of the proposed project

− Provide a basis for agreement of timescales for the proposed development activities

− Define the high-level acceptance criteria for the proposed deliverables such as that the system will conform to all agreed requirements

− Define and agree the approach to the Business Study phase

− Identify any particular facilities which the project team will require

− Define the expected path through the agile framework for the project

− Identify any currently known issues surrounding the implementation of the system and in particular aspects such as data take-on and user handover

Page 101: Implementing agile iterative project delivery approach and achieving business responsiveness

August 16, 2010 101

Outline Plan for Implementation Questions and Checklist

• Are the estimates for effort realistic in the light of the details within the Feasibility Report?

• Are the estimated timescales consistent with the business needs of the project?

• have the business needs been addressed in terms of what is delivered and when?

• Is business management able to commit to the level of business resources required for the Business Study and to ongoing user involvement for the proposed duration of the project?

• Is development management able to commit to the level of development resources required for the Business Study and to ongoing involvement for the proposed duration of the project?

• Will all necessary equipment and facilities be available as required?

• Is it clear what the criteria for acceptance are and are they rigorous enough to define the quality of deliverables while allowing the requirements to flex during development?

• Are all the currently identified standards and guidelines available and for those that are not yet available, are there sufficient resources to enable their development or procurement?

Page 102: Implementing agile iterative project delivery approach and achieving business responsiveness

August 16, 2010 102

Phase 3 - Business Study Phase

• Only initiated if Feasibility Study and Report recommends to proceed with solution development

• Forms the basis for all subsequent work

• Should be kept as short as possible (weeks rather than months) while achieving sufficient understanding of the business requirements and technical constraints to move forward with safety

• Focus is on the business processes affected by the solution and their information needs

• Phase has to be very strongly collaborative using workshops attended by knowledgeable staff who can quickly pool their knowledge and gain consensus as to the priorities of the development

• Key workshop output is the Business Area Definition which identifies the business processes and associated information and the groups/types of users who will be affected in any way by the introduction of the solution

• Users who will participate in the solution development will be identified and agreement reached with their management regarding their involvement

Page 103: Implementing agile iterative project delivery approach and achieving business responsiveness

August 16, 2010 103

Business Study Phase Outputs

• Business Area Definition

• Prioritised Requirements List

• Development/Implementation Plan

• System Architecture Definition

• Updated Solution Risk Log

Page 104: Implementing agile iterative project delivery approach and achieving business responsiveness

August 16, 2010 104

Business Area Definition

• Contains a high-level view of the business processes, people and information to be supported by the proposed solution

• Evolves into the Functional Model during Functional Model Iteration(s)

• Must be in enough detail to enable both the Development Plan and a realistic business case

Page 105: Implementing agile iterative project delivery approach and achieving business responsiveness

August 16, 2010 105

Business Area Definition

• Purpose and Objectives− Identify the business needs that should be supported by the

proposed solution

− Refine the Outline Business Case (documented in the Feasibility Report) to include benefits, risks, costs and impact analyses

−Outline the information requirements of the business processes that will be supported

− Identify the classes of users impacted by the development and introduction of the proposed system

− Identify the business processes and business scenarios that needto change

− Clarify all interfaces with other systems (human or automated)

−Verify that the proposed solution is still suitable for development using an agile iterative approach

Page 106: Implementing agile iterative project delivery approach and achieving business responsiveness

August 16, 2010 106

Business Area Definition Questions and Checklist

• Are the business context, business process and business objectives defined and agreed?

• Have all the currently identified requirements been prioritised (including non-functional requirements)?

• Have all the priorities been assigned in collaboration with the users?

• Have high-level acceptance criteria for the delivered solution been defined?

• Are the business areas clearly documented, including high-level information needs that are affected by the system?

• Is the envisaged boundary of the proposed new system realistic in the timescales?

• Are all classes of users affected by the new system identified?

• Are the information and processing requirements of the proposed system defined at least in outline?

• Is it still clear that the business needs are being addressed by the proposed new system?

• Is the person responsible for each business process identified? Can they commit the necessary resources and time?

• Are all major business events (e.g. financial year-end, order received, new supplier taken on) identified?

Page 107: Implementing agile iterative project delivery approach and achieving business responsiveness

August 16, 2010 107

Generating and Managing Requirements

• All of the requirements identified during the Feasibility and Business Studies have to be prioritised and recorded so that the most important features will be developed in preference to less essential parts that can be added later if required

• Prioritisation will mainly be led by business need but will also need to take into account the technical constraints that may drive some requirement to be satisfied first even though it may be less important in business terms

• Some non-functional (operational) requirements, such as security and performance, may also affect the prioritisation

• As parts of the solution will begin to be produced in the next phase (the Functional Model Iteration), it is not only important to understand the functionality to be developed but also the systemarchitecture that will be used

Page 108: Implementing agile iterative project delivery approach and achieving business responsiveness

August 16, 2010 108

Development/Implementation Plan

• Defines the plans and controls for the whole project or just for the next increment

• Purpose and objectives− Refine the Outline Plan to provide a more detailed plan for activities within the

Functional Model Iteration and Design and Build Iteration

− Provide the development team with a strategy for development

− Prioritise prototyping activities

− Define the categories of prototypes that will be developed and when

− Define the mechanisms for deciding when a particular prototyping activity should terminate

− Identify individuals who will take on the various roles and responsibilities on forthcoming phases of the project

− Identify which items are to be subject to configuration management and to outline how configuration control is to be applied

− Define the approach to be taken to testing: what types of tests are to be run, how they are to be specified and recorded

Page 109: Implementing agile iterative project delivery approach and achieving business responsiveness

August 16, 2010 109

Development/Implementation Plan

• First Development/Implementation Plan produced in a project should cover the overall development approach and the plan for the Functional Model and Design and Build Iterations for the first increment

• As new increments are started, the controls should be checked for their validity and possibly updated

• Plan for the next increment is added to the Development/Implementation Plan

• Should include the schedule of timeboxes but not their details

Page 110: Implementing agile iterative project delivery approach and achieving business responsiveness

August 16, 2010 110

Development/Implementation Plan Questions and Checklist

• Are the timescales consistent with the business objectives in the Feasibility Report and the Business Area Definition?

• Does the order of activities within the Development/Implementation Plan reflect the priorities, dependencies, etc. in the Prioritised Requirements List?

• Is the timebox schedule realistic in terms of currently estimated effort and the flow of products?

• Does the timebox schedule reflect the need to address areas of risk at appropriate times?

• Are all affected classes of users identified in the Development/Implementation Plan?

• Is the proposed user effort consistent with the needs of both the existing business processes and the development?

• Will the necessary effort (from all personnel) be available when required?

• Is the selection of the categories of prototypes feasible within the expected development environment?

• Is the method of configuration management appropriate to the environment?

• Are the proposed extent, depth and formality of testing appropriate?

Page 111: Implementing agile iterative project delivery approach and achieving business responsiveness

August 16, 2010 111

System Architecture Definition

• Includes both functional architecture and technical architecture

• Describes the coherence of hardware, software and available components

• Produced during the Business Study because it is needed as soon Functional Model Iteration begins

• Purpose and objectives

− Provide a common understanding of the technical architectures to be used during development and implementation

− Describe the target platform and (if different) the development platform

− Give an outline description of the software architecture (i.e. the major software objects or components - both process and data - and their interactions)

Page 112: Implementing agile iterative project delivery approach and achieving business responsiveness

August 16, 2010 112

System Architecture Definition Questions and Checklist

• Is the architecture appropriate for the requirements?

• Have the risks in the proposed architecture been properly considered - in particular, are all components of the proposed architecture available and mutually compatible?

• Will migration from the development platform to the target platform be able to occur easily? If not, are all foreseeable problems identified?

• Is the outline software architecture sufficiently well defined to give developers a high-level view of the proposed computer system?

• Is the architecture defined at an appropriate level, so that it will not be too vulnerable to change as the project progresses?

• Has advantage been taken of any opportunities for reuse of existing components?

• Can the architecture be expected to cope with performance, capacity and resilience requirements?

Page 113: Implementing agile iterative project delivery approach and achieving business responsiveness

August 16, 2010 113

Phase 4 - Functional Model Iteration Phase

• Consists of refining the business-based aspects of the computer system that is building on the high-level processing and information requirements identified during the Business Study phase

• Consist of cycles of four activities

− Identify what is to be produced

−Agree how and when to do it

− Create the product

− Check that it has been produced correctly (by reviewing documents, demonstrating a prototype or testing part of the overall solution)

Page 114: Implementing agile iterative project delivery approach and achieving business responsiveness

August 16, 2010 114

Phase 4 - Functional Model Iteration Phase

Functional Model

IterationImplementation

Design and Build

Iteration

Identify What Is To Be

Produced

Agree How and When To

Do It

Create The

Product

Check That It Has Been Produced

Correctly

Identify What Is To Be

Produced

Agree How and When To

Do It

Create The

Product

Check That It Has Been Produced

Correctly

Identify What Is To Be

Produced

Agree How and When To

Do It

Create The

Product

Check That It Has Been Produced

Correctly

Page 115: Implementing agile iterative project delivery approach and achieving business responsiveness

August 16, 2010 115

Phase 4 - Functional Model Iteration Phase

Post-Project Phase

Functional Model Iteration Phase

Design and Build Iteration Phase

Implementation Phase

Increment 1 Increment 1 Increment 1

Increment 2 Increment 2 Increment 2

Increment P

Increment M

Increment N

Pre-ProjectPhase

Feasibility Analysis and Study Phase

Business Analysis and Study Phase

Final Increments Prior to Final

Implementation

Page 116: Implementing agile iterative project delivery approach and achieving business responsiveness

August 16, 2010 116

Functional Model Iteration

• Purpose and objectives

• Demonstrate the required functionality using a functional model consisting of both working software prototypes and static models(e.g. class models and data models)

• Record the non-functional requirements which may not be demonstrated by the prototype

• Outputs

− Functional Model including functional prototypes

− Non-functional requirements list

− Functional Model review details

− Implementation plan

− Timebox plans

− Updated risk log

Page 117: Implementing agile iterative project delivery approach and achieving business responsiveness

August 16, 2010 117

Functional Model

• Defines what the solution will do without going into the detail of how non-functional/operational aspects

• Develops from and refines the Business Area Definition created during the Business Study phase

• Evolves over the life of the project expanding in scope and deepening in content with each pass through Functional Model Iteration phase within an increment and with each increment

• Consists of both documents and tangible deliverables

• Purpose and objectives

− Provide a cohesive demonstration of the functionality and data requirements to be met including all currently known constraints

− Demonstrate the feasibility of achieving the non-functional/operational requirements

Page 118: Implementing agile iterative project delivery approach and achieving business responsiveness

August 16, 2010 118

Functional Model Questions and Checklist

• Does the Functional Model match the users' needs as elicited during discussions and prototyping sessions?

• Is it within the scope of the development as defined in the Business Area Definition?

• Are all parts of the Functional Model mutually consistent?

• Does the model contain the minimum usable subset?

• Are all essential aspects of integrity and security contained within the Functional Model?

• Are the requirements for system administration visible?

• Are all static models (e.g. data models) consistent with the Functional Prototype(s), and vice versa?

• Does the model give confidence that the right levels of performance, capacity and maintainability will be achievable?

• Is any necessary supporting documentation available and to an adequate standard?

Page 119: Implementing agile iterative project delivery approach and achieving business responsiveness

August 16, 2010 119

Phase 5 - Design and Build Iteration Phase

• Solution is developed to a sufficiently high standard to be safely placed in the hands of the users

• Prototypes are refined to meet operational/service requirements

• Consist of cycles of four activities− Identify what is to be produced

−Agree how and when to do it

− Create the product

− Check that it has been produced correctly (by reviewing documents, demonstrating a prototype or testing part of the overall solution)

• Generates the Tested Solution

Page 120: Implementing agile iterative project delivery approach and achieving business responsiveness

August 16, 2010 120

Phase 5 - Design and Build Iteration Phase

Functional Model

IterationImplementation

Design and Build

Iteration

Identify What Is To Be

Produced

Agree How and When To

Do It

Create The

Product

Check That It Has Been Produced

Correctly

Identify What Is To Be

Produced

Agree How and When To

Do It

Create The

Product

Check That It Has Been Produced

Correctly

Identify What Is To Be

Produced

Agree How and When To

Do It

Create The

Product

Check That It Has Been Produced

Correctly

Page 121: Implementing agile iterative project delivery approach and achieving business responsiveness

August 16, 2010 121

Agile Iterative Sequential and Parallel Phases

Post-Project Phase

Functional Model Iteration Phase

Design and Build Iteration Phase

Implementation Phase

Increment 1 Increment 1 Increment 1

Increment 2 Increment 2 Increment 2

Increment P

Increment M

Increment N

Pre-ProjectPhase

Feasibility Analysis and Study Phase

Business Analysis and Study Phase

Final Increments Prior to Final

Implementation

Page 122: Implementing agile iterative project delivery approach and achieving business responsiveness

August 16, 2010 122

Operational/Service Requirements

• Often called non-functional requirements because they do not relate to specific solution functions and features

• Define how well the system should operate rather than what it should do− Performance Requirements - Specify numerical values for the measurable variables within the

system, such as response rates, capacity volumes and communication rates− Interface Requirements - Specify the hardware or software elements with which the system, or

system component, must interact or communicate− Operational Requirements - Specify how the system will run and communicate with the system

users including all user interface requirements− Resource Requirements - Specify the limits on physical resources, such as memory capacity, disk

capacity, processor power− Security Requirements - Specify the requirements for the system for securing against threats to

confidentiality, integrity and availability− Portability Requirements - Specify the need to install the software components on other hardware

platforms and/or operating systems− Reliability Requirements - Specify the acceptable mean time between failures of the system,

averaged over a significant period− Maintainability Requirements - Specify how easy it is to repair faults and adapt the software to

new requirements− Safety Requirements - Specify the requirements to reduce the possibility of causing damage as a

direct result of system failure− Recovery Requirements - Specify what needs to be done before and after system failure, e.g.

backup requirements to enable recovery when needed, business continuity requirements (the minimal service) and full recovery requirements

Page 123: Implementing agile iterative project delivery approach and achieving business responsiveness

August 16, 2010 123

Operational/Service Requirements

• Operational/service requirements can have significant impact on the degree to which quality controls are applied to software products

• Need to be carefully examined to see the impact on the flow of development and the rigour that will be applied in static and dynamic testing

• Requirements relating to performance, reliability, security and maintainability are of particular importance in projects that are trying to deliver a system quickly

• Decisions have to be made by the business as early as possible in the project about what has to be done now and what can be left until later

Page 124: Implementing agile iterative project delivery approach and achieving business responsiveness

August 16, 2010 124

Operational/Service Requirements Questions and Checklist

• Are all the non-functional requirements sufficiently quantified?

• Where non-functional requirements have already been addressed by a Functional Prototype, are these noted as such in the list of non-functional requirements?

• Have all areas identified in the high-level constraints in the Feasibility Report been considered?

• Is the set of non-functional requirements complete and consistent both within itself and with the Functional Model?

• Do all the non-functional requirements add value to the business processes?

• Are the non-functional requirements realistic and achievable?

Page 125: Implementing agile iterative project delivery approach and achieving business responsiveness

August 16, 2010 125

Phase 6 - Implementation Phase

• An operational system includes not only the computer system but also the people who interact with it and the business processes they use− All of these must be successfully migrated for the solution to be considered to be

delivered

− Users of the system who may require training include not only the business end-users but also people working in support functions

• Purpose and objectives− Place the tested solution in the users' working environment

− Train the users of the new system

− Determine the future development requirements

− Train operators and support staff

• Review of the implementation increment must be run as soon as possible after delivery of the solution so that the next phase of development can be planned and kicked off with as little delay as possible

• If the current increment was not originally planned to be the final increment, the project must not assume that the next increment will happen− End of implementation is a go/no go point for the project

Page 126: Implementing agile iterative project delivery approach and achieving business responsiveness

August 16, 2010 126

Phase 6 - Implementation Phase

Functional Model

IterationImplementation

Design and Build

Iteration

Identify What Is To Be

Produced

Agree How and When To

Do It

Create The

Product

Check That It Has Been Produced

Correctly

Identify What Is To Be

Produced

Agree How and When To

Do It

Create The

Product

Check That It Has Been Produced

Correctly

Identify What Is To Be

Produced

Agree How and When To

Do It

Create The

Product

Check That It Has Been Produced

Correctly

Page 127: Implementing agile iterative project delivery approach and achieving business responsiveness

August 16, 2010 127

Agile Iterative Sequential and Parallel Phases

Post-Project Phase

Functional Model Iteration Phase

Design and Build Iteration Phase

Implementation Phase

Increment 1 Increment 1 Increment 1

Increment 2 Increment 2 Increment 2

Increment P

Increment M

Increment N

Pre-ProjectPhase

Feasibility Analysis and Study Phase

Business Analysis and Study Phase

Final Increments Prior to Final

Implementation

Page 128: Implementing agile iterative project delivery approach and achieving business responsiveness

August 16, 2010 128

Implementation Plan

• Implementation Plan is produced no later than during the last pass through Functional Model Iteration Phase

• All Implementation phase stakeholders (e.g. networks support andhelp desk) must be involved in the creation of the Implementation Plan and agree that it is realistic and achievable

• Defines the activities needed to move the current system increment from the development environment to full operational use

• Includes not only the migration of the system itself but also the Training Strategy to ensure that the operational system is used effectively

• Purpose and Objectives− Define the detail of how the increment being currently developed will become

operational

− Define the costs and effort in more detail, enabling management to reassess the costs and benefits of the development

Page 129: Implementing agile iterative project delivery approach and achieving business responsiveness

August 16, 2010 129

Implementation Plan Questions and Checklist

• Are the plans agreed with the people who will support the increment in operation?

• Does the timetable still fit in with business needs?

• Do the cost and effort estimates (both developer and user) look realistic for achieving delivery of the solution?

• Are the necessary resources (both developer and user) available to meet this plan?

• If relevant, are the procedures for handover to maintenance and support staff clear?

• If relevant, have the requirements for data take-on and/or system cutover been adequately considered?

• Is the Training Strategy appropriate?

• Have all changes to the physical environment been adequately considered?

• Have issues relating to third parties been considered?

• Has communication (e.g. within the organisation and customers) been considered?

Page 130: Implementing agile iterative project delivery approach and achieving business responsiveness

August 16, 2010 130

Implementation Plan Activities

• Identify the various classes of users

• Define the skills and/or training they may need in order to use the system and any new business processes

• Identify the gap between the skills required and those currently held by the different classes of users

• Plan the training method, e.g. classroom, computer-based training, one-to-one sessions, guided tutorials

• Produce the training material needed

• Produce training schedule if appropriate to the training method

• Deliver the training

Page 131: Implementing agile iterative project delivery approach and achieving business responsiveness

August 16, 2010 131

Phase 7 - Post-Project Phase

• Occurs once the project is delivered

• Includes support and maintenance activities and (optionally) a post-implementation review to assess the system in use

• Purpose and objectives

− To keep the solution operational

− To assess whether or not the proposed benefits of the project asstated during its initial phases have been achieved

− To enable development processes to improve

− To review the solution in use

Page 132: Implementing agile iterative project delivery approach and achieving business responsiveness

August 16, 2010 132

Post-Implementation Review

• Captures lessons learnt about the system in use and an assessment of the benefits achieved

• Purpose and objectives− Determine whether or not the product has caused any problems in use

− Decide if there are any enhancement opportunities that have been revealed by use of the product

− Demonstrate how well the expected benefits from the project were actually achieved

• Questions and checklist− Does the report include comments from representatives of all those affected

by the end product?

− Does the report make recommendations in cases where a problem has been identified?

− Have all proposed benefits from the business case been considered?

− Where benefits have not been realised is there a clear approach to addressing the issue?

Page 133: Implementing agile iterative project delivery approach and achieving business responsiveness

August 16, 2010 133

Tested Solution

• Solution ready to be migrated into operational use consisting of the solution increment to be delivered

• Purpose and objectives

− Provide a system that performs all agreed functionality and which meets all the agreed non-functional requirements

− Provide a working system which can be placed safely in the users' environment

− Provide support and maintenance staff with sufficient information to perform enhancements, support the users, perform system management tasks, etc.

Page 134: Implementing agile iterative project delivery approach and achieving business responsiveness

August 16, 2010 134

Tested Solution Deliverables

• User documentation

• Handover documents

• Support guide

• Operating procedures

• Backup and recovery procedures

• Disaster recovery procedures

• Build procedures

• Install procedures

• Help desk scripts

• Design documentation (taken from system architecture definition)

• Selected models and textual parts of the functional model

• Business procedures

• Service level agreements

• Training documentation

Page 135: Implementing agile iterative project delivery approach and achieving business responsiveness

August 16, 2010 135

Tested Solution Questions and Checklist

• Does the solution satisfy all the user-defined acceptance criteria?

• Is the project team satisfied that the solution is sufficiently robust to be put into full operation?

• Has the solution been tested at an appropriate level, considering its intended use?

• Is there evidence that all the essential requirements (functional and non-functional) have been tested and, where necessary, demonstrated to the users?

• Have any and all safety-related and product liability aspects of the system been properly validated?

• Has all functionality that is provided to support implementation been adequately tested (in particular, has account been taken of any need for data conversion/uploading tools)?

• Are all components of the Tested Solution traceable to the Functional Model?

• Are all components rejected in the design review documents omitted from the Tested Solution?

• Is the solution documentation consistent with the solution?

Page 136: Implementing agile iterative project delivery approach and achieving business responsiveness

August 16, 2010 136

Maintenance

• Maintenance is a fact of life since the business needs change, so although maintenance is necessarily in the Post-Project phase, it has to be considered from the very beginning of the project

• Poor maintainability is a real risk to the business− A new solution could rapidly become a problematic, unmaintainable legacy solution so

triggering user requests to replace it

• Agile iterative places fitness for business purpose as the essential factor for acceptance of deliverables

• Components with poor maintainability can slow the development of future increments

• Maintainability and the ability to deliver quickly therefore go hand in hand

• Poor maintainability means solutions− Take more resources in maintenance

− Take longer to change

− Are more likely to introduce further errors with change and be unreliable

− Will cost more to maintain

Page 137: Implementing agile iterative project delivery approach and achieving business responsiveness

August 16, 2010 137

Using Agile Iterative Approach for Specific Projects

Page 138: Implementing agile iterative project delivery approach and achieving business responsiveness

August 16, 2010 138

Using Agile Iterative Approach for Specific Projects

• Agile approach can be used for many project types

− Software development

− System integration

− Process change/process introduction

− Business intelligence

• Focus of these projects is the frequent delivery of products, active user involvement and iterative approach

Page 139: Implementing agile iterative project delivery approach and achieving business responsiveness

August 16, 2010 139

Introducing Agile Iterative Approach into an Organisation

Page 140: Implementing agile iterative project delivery approach and achieving business responsiveness

August 16, 2010 140

Introducing Agile Iterative Approach into an Organisation

• Introduction of agile iterative project approach into any organisation must be a carefully planned and managed programme to achieve a successful outcome

• Introduction is effectively a Business Process Re-engineering of project delivery activities

• Recommend an incremental approach

• Pilot projects should be selected to prototype and review the use of agile iterative approach

• Key risks need to be identified and managed by iteration and refinement, i.e. the agile iterative approach itself should be used to introduce agile into the organisation

Page 141: Implementing agile iterative project delivery approach and achieving business responsiveness

August 16, 2010 141

Agile Iterative Approach Introduction Steps

Pre-Project

Feasibility Study

Business Study

Identify Suitable Project(s)

Deliver Agile Project(s)

Post-Project

Page 142: Implementing agile iterative project delivery approach and achieving business responsiveness

August 16, 2010 142

Pre-Project

• Identify and quality the opportunity to introduce agile iterative project approach into the organisation

• What are the business problems to be addressed?

Page 143: Implementing agile iterative project delivery approach and achieving business responsiveness

August 16, 2010 143

Feasibility Study

• Is the organisation prepared to change to an agile iterative mind set?

• Identify initial risks to the successful introduction of agile

• Does the culture within the organisation encourage risk taking?

− Is the organisation prepared to change?

− The success of agile iterative approach depends on acceptance of the underlying principles

− Is the organisation prepared to accept them?

• Identify the key business needs

• Produce strategy for way forward

• Produce the project plan

Page 144: Implementing agile iterative project delivery approach and achieving business responsiveness

August 16, 2010 144

Business Study

• Identify key stakeholders within the organisation

• Promote agile iterative approach so all the stakeholders within the organisation are aware of the key benefits

• Determine business benefits and perform a cost/benefit analysis

• Produce programme of candidate agile iterative projects

• Gain commitment to proceed

Page 145: Implementing agile iterative project delivery approach and achieving business responsiveness

August 16, 2010 145

Identify Suitable Project(s)

• Select suitable pilot project(s) using agile evaluation and critical success factors

• Determine main project risks

• Identify required project environment including tools and infrastructure

• Review and update quality procedures

• Determine key project metrics

Page 146: Implementing agile iterative project delivery approach and achieving business responsiveness

August 16, 2010 146

Deliver Agile Project(s)

• Procure necessary tools and support environments to enable agile iterative project delivery

• Select the project team

• Train the project team

• Run the agile project and produce the business application

• Manage and monitor the project

• Review the project

Page 147: Implementing agile iterative project delivery approach and achieving business responsiveness

August 16, 2010 147

Post-Project

• Measure business benefits

• Promote project success

• Amend standards and procedures

• Develop agile skilled mentors

• Identify/run the next project or set of projects

Page 148: Implementing agile iterative project delivery approach and achieving business responsiveness

August 16, 2010 148

More Information

Alan McSweeney

[email protected]