Professional Documents
Culture Documents
Alan McSweeney
Objectives
• 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
Complete Complete
Success Failure
Performance and/or
Operational Solution
Problems Largely Unused
Complicated
Difficult
Well
Defined/ Simple
Agreed
Project Technology
Well Highly
Proven Uncertain
August 16, 2010 17
Solution Functionality Used
Agile Approach
Timeboxing Workshops Pre-Project
Suitability Checklist
Measurement Post-Project
• 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
• 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
• 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
• During each timebox, the team working on the timebox should meet
daily 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?
• 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
August 16, 2010 52
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
• Solution
functionality is
prioritised and
delivered according
to available time
and resources but
time and resources
are fixed
Before the project begins properly an estimate must be prepared for the work to be done
Pre-project Phase during Feasibility Study phase
Estimation 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
Feasibility Study
Phase Estimation 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
Business Study identified from the prioritised requirements
Phase Estimation
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
August 16, 2010 Business Case to assess whether the project is still viable 57
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
Functional Model Estimation is performed for each timebox to assess whether the timebox plan is achievable,
Iteration Phase and to evaluate the impact on the project if any revisions to the estimate are required
and Design and
Build Iteration Before the start of each timebox an estimate for the expected work is carried out to ensure
Phase Estimation 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
Implementation very high level estimates available for this phase
Phase Estimation Before the Implementation phase begins, the estimates must be reviewed to ensure they are
still reasonable
• 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
Outline Plan
Feasibility Study
Phase Means to define and agree the terms and conditions for a successful project and
contains as a detailed plan for the Business Study
Development Plan
Business Study
Phase How the project will be carried out and in particular which prototypes will be built
and when
• 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?
• 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
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
2 Implementation
4
Feasibility 7
1 Analysis and
Study
Functional
Model Post-Project
Pre-Project Iteration
Business
Analysis and
Study Design and
Build
Iteration
3
5
Sequential Iterated Phases
Phases
August 16, 2010 91
Iterated Phases
Agree How Agree How
and When To and When To
Do It Do It
Feasibility Business
Pre-Project Post-Project
Analysis and Analysis and Design and Build Iteration Phase
Phase Phase
Study Phase Study Phase
Implementation 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
• 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
• 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
• 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?
• 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
Feasibility Business
Pre-Project Post-Project
Analysis and Analysis and Design and Build Iteration Phase
Phase Phase
Study Phase Study Phase
Implementation Phase
• 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
• 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?
Feasibility Business
Pre-Project Post-Project
Analysis and Analysis and Design and Build Iteration Phase
Phase Phase
Study Phase Study Phase
Implementation Phase
• 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
• 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
Feasibility Business
Pre-Project Post-Project
Analysis and Analysis and Design and Build Iteration Phase
Phase Phase
Study Phase Study Phase
Implementation Phase
• 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?
• 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
Feasibility Study
Business Study
Identify Suitable
Project(s)
Deliver Agile
Project(s)
Post-Project
Alan McSweeney
alan@alanmcsweeney.com